I’d like to propose an API for enabling web apps on the lock screen of a device. For example, a user may want to check a calendar, use a calculator, take a photo, or take a note, all without going through the extra step to unlock their device first. Such an API would be applicable to both desktop and mobile platforms, though it will generally require some operating system support to implement it.
How might we enable web apps to declare to the user agent that they are able to operate on the lock screen? How should this be different from their normal operation?
How might we enable web apps to run on the lock screen and usefully interact with user data while preserving security boundaries with that data? For example, a camera app may let the user take photos from the lock screen but not display existing photos. A calendar app may expose meeting times but hide their titles on the lock screen.
Add a lock screen start URL entry to the web app manifest, allowing a web app to declare an additional URL (similar to start_url, and within its scope) to be used to launch the app on the lock screen. Declaring such a URL indicates that the app is able to function on the lock screen. As a security boundary, the app launched on the lock screen would likely need to be isolated from regular user data.
Add a data API so that an isolated instance of an app running on the lock screen may send data to a corresponding instance of the app that runs when the device is unlocked, and vice versa. Consider limiting this communication to one-way. The goal is to avoid accidentally exposing user data to the lock screen by forcing the app to explicitly send any data needed via this API.
Advise web app authors against authenticating users in apps running on the lock screen - prefer to send only the needed data from the authenticated instance of the app that runs when the device is unlocked.
Glen Robertson (Google Chrome OS team)