Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Give advice on how UAs should infer consent to take a wakelock #140

Closed
jyasskin opened this Issue Dec 13, 2018 · 7 comments

Comments

Projects
None yet
5 participants
@jyasskin
Copy link
Member

jyasskin commented Dec 13, 2018

The spec currently says

A user agent MAY check user settings or request user permission in order to decide whether it will deny wake lock of a particular type for a particular Document.

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.

Some options:

  • Pop up a permission dialog each time any kind of wake lock is requested. (Ick)
  • Show a notification while any wake lock is active, and have the notification offer a way to release the wake lock. (I.e. "ask for forgiveness", like fullscreen)
  • Only do the above for "system" wake locks, since "screen" locks are easier to notice and manually disable.
  • Show a permission dialog if the "system" wake lock is used from a site with other permissions, like geolocation, that users might not want used in the background.
  • Just let sites do whatever.

I'm sure folks will think of other good options in the replies.

@Ajedi32

This comment has been minimized.

Copy link

Ajedi32 commented Dec 19, 2018

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.

@tomayac

This comment has been minimized.

Copy link
Collaborator

tomayac commented Dec 19, 2018

I'd prefer totally independent permissions prompts for "geolocation in the background" vs "geolocation in the foreground".

+1, this is also how we have separated our use cases in Geolocation Sensor.

CC: @anssiko

@feross

This comment has been minimized.

Copy link

feross commented Dec 23, 2018

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.

@jyasskin

This comment has been minimized.

Copy link
Member Author

jyasskin commented Dec 27, 2018

@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).

kenchris added a commit to kenchris/wake-lock that referenced this issue Mar 11, 2019

kenchris added a commit to kenchris/wake-lock that referenced this issue Mar 12, 2019

kenchris added a commit to kenchris/wake-lock that referenced this issue Mar 12, 2019

@Ajedi32

This comment has been minimized.

Copy link

Ajedi32 commented Mar 12, 2019

I don't see anything in #158 regarding background permissions for other sensitive operations like geolocation or mic access. Is that something that you're still planning to address, or do you plan to leave that up to other standards or UA implementations to resolve?

@jyasskin

This comment has been minimized.

Copy link
Member Author

jyasskin commented Mar 18, 2019

@kenchris #158 is a bit of a mess and IMO doesn't fully fix this issue.

@kenchris

This comment has been minimized.

Copy link
Collaborator

kenchris commented Apr 1, 2019

This should have been fixed by now, feel free to open if now, or file new, more specific issues

@kenchris kenchris closed this Apr 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.