Hi WICG,

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.

Problem

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.

Proposal

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.

Thanks,

Glen Robertson (Google Chrome OS team)

Interesting proposal… I wonder if it’s really necessary to do the data containment step? With most devices having either fingerprint or face recognition, the OS could just require simple unlocking while not requiring the data isolation.

Alternatively, the app could signal directly in the manifest if it needs storage access (or the reverse). When it doesn’t, it could be treated like a third-party iframe (no cookies, no storage, super restricted feature policy). Otherwise, it requires normal authentication.

Just my 2c…

Thanks for considering the proposal.

the OS could just require simple unlocking while not requiring the data isolation

If we require unlocking before using the app, this whole proposal isn’t needed - the user can just unlock the device and use the app normally. So the proposal assumes we want to remove the extra step of unlocking the device first. Empirically, even with a quick fingerprint unlock on my phone, being able to take a photo without unlocking first is a nice feature that I use all the time. Also, although they’re becoming more common, many devices don’t have such quick unlock features, especially laptops and desktops.

the app could signal directly in the manifest if it needs storage access (or the reverse)

Yes, definitely. I didn’t want to go into too much detail in this initial proposal but we could definitely restrict the lock screen app and make it declare if it needs access to the proposed data API.

Otherwise, it requires normal authentication.

Do you mean the user would login to the web app from the lock screen? I’m trying to avoid that if at all possible because it would make it much easier for the app to accidentally expose user data on the lock screen. The data API would force the app to explicitly send the needed data.

Seems somewhat similar to my initial thoughts on Projections for Web Apps. In this case, the lock screen would be another projection surface. Other examples include the home screen, “glance” views, dashboards, the touchbar, etc.

Ah, that’s an interesting idea, almost a generalisation of this one in terms of surfaces. On the other hand this is proposing something more heavyweight - the lock screen app could be a full web app with JS, so not necessarily suitable to display as widgets/tiles that are always loaded.

We should definitely keep an eye on each other’s progress and see if anything makes sense to combine.

I think limited JS in these scenarios is fine, but it needs to be lightweight for memory-usage purposes. It probably makes the most sense to rely on some form of worker (ideally an existing one, but if not maybe a widget worker?) to handle async communication with a background thread where any heavily lifting actually happens.

I hope to get around to spec-ing this out in the next month or two. I’ll ping this thread when it happens.