Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Give advice on how UAs should infer consent to take a wakelock #140
The spec currently says
I think that's the appropriate normative language, but it'd help align expectations between UAs and authors if the document gave some non-normative advice about how the UA will make sure the user isn't surprised and unhappy about how their device behaves.
I'm sure folks will think of other good options in the replies.
My suggestion would be to "ask for forgiveness" for screen locks, so that it's apparent to the user why the screen isn't turning off in a reasonable amount of time and so they have an easy way to disable that behavior if they find it undesirable.
System wake locks are a bit trickier, because once the screen turns off there's no longer any opportunity for the user to notice that the site is still running. Perhaps in that case an active prompt would be best.
For permissions like geolocation or mic access that could pose additional privacy concerns if allowed to run in the background, personally I'd prefer totally independent permissions prompts for "geolocation in the background" vs "geolocation in the foreground". If I'm using a maps app with voice recognition based controls, for example, it should be possible to grant that app the ability to track my location in the background and the ability to listen to voice commands when I have it open without also giving it the ability to listen to my conversations in the background.
Why do "geolocation in the background" vs "geolocation in the foreground" need to be distinguished?
I believe that a site with geolocation permission that is open in a tab already has the ability to continuously poll for geolocation.
Adding a System Wake Lock just allows the site to ensure that it isn't unloaded by the browser, but there are other ways to accomplish this already, including keeping a WebRTC data channel open, playing a silent audio file, etc.
In other words, I don't think this API actually enables anything that wasn't already possible, just makes it a bit easier to accomplish and provides a better guarantee that the CPU will stay active.
On the other hand, if this API was allowing a site to wake itself up and get geolocation after the tab has already been closed by the user (say by using a service worker), then I believe a separate permission would be warranted. But this API isn't doing that.
@feross On mobile devices, sites loaded in tabs other than the frontmost one generally get killed pretty quickly due to memory pressure, so even though they could in theory track a user who isn't looking at them, they don't usually get to in practice. The "system" wake lock makes it much more likely that the site will succeed in tracking the user. On desktop, I agree this is less of a problem.
The other mechanisms for preventing the browser from suspending a site are indeed problems, but we should improve users' awareness of them instead of holding the "system" wake lock to the lowest existing bar. Chrome on Android already exposes sites playing audio using a persistent notification, so users get to see that. I think other mobile browsers should do the same, if they're not already, and that we should put similar notices in place for the other mechanisms (or require a "system" wake lock where that's web-compatible).