Chrome 67 Brings Support For PWAs, Passwordless Login

Google launched Chrome version 67, bringing support for Progressive Web Apps, the generic sensor API, and the WebXR Device API, as well as new security features and changes.

Progressive Web Apps

Progressive Web Apps are the latest attempt by browser vendors to make web apps work like native applications on the desktop or mobile devices. Google had previously tried this with its “Chrome Apps,” which were Chrome-only and not standardized. Eventually, the company had to deprecate them, presumably so it could focus on its support for the more standardized PWA format.

The main benefit of PWAs, aside from the fact that all browser vendors will support it, is that it will allow web apps to work without any internet connection. The PWAs will use web standards such as Service Workers and Web App Manifests, the latter of which allow users to interact with PWAs as if they were native apps.

PWAs can also make use of features to which native applications typically have access, such as cameras, data storage, GPS and motion sensors, face detection, and more. Although not required to build a PWA, this type of application will likely benefit from the browser vendors’ embracing of the WebAssembly language, a higher-performance programming language that brings almost native-like performance to web apps.

Web Authentication API Support

Chrome 67 brings support for the Web Authentication API, which will allow users to log in to websites without needing a password through a private-public key cryptography system. For instance, users could have a FIDO 2-enabled Yubico Security Key and use it to log in to their favorite websites.

Alternatively, the private key could also be stored on other devices, which should be protected by a PIN, password, or biometric scan. The upside is that you won’t need a password for every website, as long as the websites you visit support the Web Authentication API.

Google Deprecates HPKP, Recommends Expect-CT Header

Google also announced that it will deprecate the HTTP-Based Public Key Pinning (HPKP) mechanism, which was used by some websites to pin public keys in a certificate to prevent impersonation. However, the company said that the feature had very low adoption, despite the fact that it was effective against certificate mis-issuance. It also created the risk of denial of service and hostile pinning. The feature will be completely removed in Chrome 69.

As an alternative security feature that will help defend against certificate mis-issuance, Google recommends web developers to use the Expect-CT header, where CT here stands for Certificate Transparency, a transparency and audit system for certificate authorities (CAs). Google said that Expect-CT is actually safer than HPKP because it better protects developers from configuration errors, and many CAs already support it.

Generic Sensor API

Chrome 67 also gets support for the new Generic Sensors API, which will allow web apps and PWAs to gain access to sensor data from accelerometer, gyroscope, orientation sensor, and motion sensor.

It’s not clear whether or not web apps will be able to automatically collect this type of data by default, as they do with device battery life data, for instance, or if they’ll ask users for permission first.

WebXR Device API

The WebXR Device API enables developers to create virtual and augmented reality experiences within web apps. The company noted that this feature is supposed to unify the mixed reality experiences across mobile-focused and desktop-focused VR and AR headsets. The WebXR Device API supports experiences such as: games, 2D and 3D videos, 360 videos, data visualization, home shopping, and art.

The API is currently an “original trial” API, which means it’s experimental, developers have to sign-up to use it, and there is no guarantee that it will ever be adopted by default in the browser.

Lucian Armasu
Lucian Armasu is a Contributing Writer for Tom's Hardware US. He covers software news and the issues surrounding privacy and security.
  • alextheblue
    I can't see the Chrome icon without thinking it's a weird new-generation Pokéball.

    Anyway all the work on PWAs and WebAssembly are great. Google, MS, and Apple are all natively supporting PWAs too, which is kind of shocking. Especially Apple.
    Reply
  • derekullo
    21014249 said:
    I can't see the Chrome icon without thinking it's a weird new-generation Pokéball.

    Anyway all the work on PWAs and WebAssembly are great. Google, MS, and Apple are all natively supporting PWAs too, which is kind of shocking. Especially Apple.

    Don't be Evil
    Google Chrome, gotta spy on them all!!!
    An advertising model so true
    Our market value will pull us through
    Click our links and we'll profit off you
    Google Chrome ...







    Reply
  • alextheblue
    21024450 said:
    21014249 said:
    I can't see the Chrome icon without thinking it's a weird new-generation Pokéball.

    Anyway all the work on PWAs and WebAssembly are great. Google, MS, and Apple are all natively supporting PWAs too, which is kind of shocking. Especially Apple.

    Don't be Evil
    Google Chrome, gotta spy on them all!!!
    An advertising model so true
    Our market value will pull us through
    Click our links and we'll profit off you
    Google Chrome ...
    Hah that does fit the song fairly well.

    I don't use Google services when possible but I *am* glad all the big dogs are onboard PWAs/WebASM and deprecating a lot of the proprietary stuff. It will be good to have the same code run everywhere, as an open standard that could be implemented on any OS/browser. It won't completely replace the need for true native software, where max performance is needed... but it's good enough for the majority of software/apps.
    Reply