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

Screen Wake Lock API #210

Open
marcoscaceres opened this issue Oct 18, 2019 · 26 comments
Open

Screen Wake Lock API #210

marcoscaceres opened this issue Oct 18, 2019 · 26 comments
Labels
w3c

Comments

@marcoscaceres
Copy link
Collaborator

@marcoscaceres marcoscaceres commented Oct 18, 2019

Request for Mozilla Position on an Emerging Web Specification

Other information

The WakeLock API allows web applications to request a wake lock. A wake lock prevents some aspect of the device from entering a power-saving state (e.g., preventing the system from turning off the screen).

Non-video use cases are outlined here:
https://www.w3.org/TR/wake-lock-use-cases/

@marcoscaceres marcoscaceres added the w3c label Oct 18, 2019
@annevk

This comment has been minimized.

Copy link
Collaborator

@annevk annevk commented Oct 18, 2019

Being able to determine battery state seems quite concerning given past abuse with the battery API (since removed).

It's also not really clear to me how to do UI for system lock. (And some of the use cases might also be addressed with Background Sync/Fetch, though we haven't quite figured out UI for those either.)

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator Author

@marcoscaceres marcoscaceres commented Oct 20, 2019

Being able to determine battery state seems quite concerning given past abuse with the battery API (since removed).

Do you mean by it dropping out of wake lock state or rejecting a lock request? Or something else?

It's also not really clear to me how to do UI for system lock. (And some of the use cases might also be addressed with Background Sync/Fetch, though we haven't quite figured out UI for those either.)

Agree and I’ve argued the same thing: system lock should be removed from the spec IMO for the reasons/API above.

@annevk

This comment has been minimized.

Copy link
Collaborator

@annevk annevk commented Oct 22, 2019

Do you mean by it dropping out of wake lock state or rejecting a lock request?

Yes, the concerns mentioned at https://w3c.github.io/wake-lock/#security-and-privacy-considerations basically.

@reillyeon

This comment has been minimized.

Copy link

@reillyeon reillyeon commented Oct 23, 2019

The explicit leakage of the wake lock state seems unnecessary and I've filed w3c/wake-lock#247 to consider changing the specification text.

Even with that resolved there is still the question of whether this indicates the gross state of the user's battery. As an example, on Android the "battery saver" feature can be set to automatically engage when the battery is low. In testing on my Android device it does not appear that this feature changes the behavior of screen wake locks or the screen timeout and so requesting a screen wake lock cannot be used to determine that the device is in a low power state. The behavior on other platforms may of course vary.

@bholley

This comment has been minimized.

Copy link

@bholley bholley commented Jan 17, 2020

What is the incentive structure around individual websites requesting wake lock? I certainly see some cases where it could be useful, but I am concerned about a tragedy-of-the-commons situation where some study shows marginally-increased engagement with wake lock and every website starts to request it.

@tomayac

This comment has been minimized.

Copy link

@tomayac tomayac commented Jan 17, 2020

What is the incentive structure around individual websites requesting wake lock?

Recipe sites have started to use this: https://twitter.com/ChromiumDev/status/1215343114166185985.

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

@bzbarsky bzbarsky commented Jan 17, 2020

I think @bholley's question is what is the incentive for sites to NOT unnecessarily request wake lock?

@tomayac

This comment has been minimized.

Copy link

@tomayac tomayac commented Jan 17, 2020

I think @bholley's question is what is the incentive for sites to NOT unnecessarily request wake lock?

They already could today… https://github.com/richtr/NoSleep.js/blob/master/src/index.js. Wake Lock is the proper way to do this, as expressed in this Issue.

@bzbarsky

This comment has been minimized.

Copy link
Collaborator

@bzbarsky bzbarsky commented Jan 18, 2020

One difference is that if sites are abusing videos to simulate wake lock browsers could try to not wake lock for those videos. What happens if (when?) sites abuse the actual wake lock API? Do browsers then stop having it reliably wake lock?

Again, maybe the simple answer is "sites won't abuse it that way"; if there's data to that effect it would be really useful here. We're just trying to get as much information as we can on the possible drawbacks to weigh against the benefits.

@tomayac

This comment has been minimized.

Copy link

@tomayac tomayac commented Jan 20, 2020

Again, maybe the simple answer is "sites won't abuse it that way"; if there's data to that effect it would be really useful here.

I've looked into HTTP Archive data. The archive currently has data on 5,660,569 page URLs, so qualifies as somewhat representative. I took the Base64-encoded video URL of NoSleep as an indicator and queried the archive with the following query.

SELECT
  DISTINCT page,
  url
FROM (
  SELECT
    page,
    url,
    body
  FROM
    `httparchive.response_bodies.2019_12_01_mobile`
  UNION DISTINCT
  SELECT
    page,
    url,
    body
  FROM
    `httparchive.response_bodies.2019_12_01_desktop`)
WHERE
  body LIKE "%data:video/webm;base64,GkXfo0AgQoaBAUL3gQFC8oEEQvOBCEKCQAR3ZWJtQoeBAkKFgQIYU4BnQI0VSalmQCgq17FAAw9CQE2AQAZ3aGFtbXlXQUAGd2hhbW15RIlACECPQAAAAAAAFlSua0AxrkAu14EBY8WBAZyBACK1nEADdW5khkAFVl9WUDglhohAA1ZQOIOBAeBABrCBCLqBCB9DtnVAIueBAKNAHIEAAIAwAQCdASoIAAgAAUAmJaQAA3AA/vz0AAA=%"

This revealed 3,345 script URLs, spread across 2,210 page URLs (0.0390420115%).

Looking at the examples, I can spot a number of valid use cases: photo light-boxes, chat widgets, games,… The results of my query are available in this spreadsheet in case anyone wants to look deeper.

@bholley

This comment has been minimized.

Copy link

@bholley bholley commented Jan 21, 2020

Thanks for putting that together Thomas.

If we take the set of wake-lock-seeking content as fixed, I think it is a win for user agency to use an explicit browser API over NoSleep.js. If these requests come in the front door, it is much easier for us to build affordances for users to understand and control the behavior, rather than playing a cat-and-mouse game trying to detect the hacks.

However, I'm pretty sure the set of wake-lock-seeking content is not actually fixed. That is to say, if we offer a front door, we might see a substantial uptick in requests. At present, I hypothesize that NoSleep.js is sufficiently bespoke that developers only seek it out in response to needs they directly experience ("our live chats are getting cut off, can we fix that?"). But if browsers instead say "please tell us if you're a high-engagement experience and we'll keep the lights on for you," I can imagine many more sites self-identifying as such, because everyone thinks they're important.

It's possible this uptick could be managed with engagement gates and user controls, but would require some care.

@martinthomson

This comment has been minimized.

Copy link
Member

@martinthomson martinthomson commented Jan 22, 2020

The primary thing to concern ourselves with here is accountability rather than gates. As with fullscreen, I don't see value in explicit permissions along the lines of "allow wake lock [y/n]?" as that is meaningless to most people.

What we need to work out is how people will understand that wake lock has been engaged and how they remediate that if they don't like it. And then what information sites get about any remediation action taken, like blocking. I can very easily see how a screen lock might be coupled to fullscreen usage, but it is a little trickier when this is only a background window.

I don't have a good reference frame for system locks, and I suspect that our users won't either. Given the more limited capabilities, it might be that this doesn't need the same level of access, but it seems like we would miss the necessary accountability here. A site might be responsible for battery drain that won't obviously be attributed to that site.

@tomayac

This comment has been minimized.

Copy link

@tomayac tomayac commented Jan 22, 2020

I don't see value in explicit permissions along the lines of "allow wake lock [y/n]?" as that is meaningless to most people.

This is a matter of how the UA phrases it. "Keep the screen awake while in foreground [y/n]?" as an alternative. Our current thinking in Chrome, though, is to not gate this behind a permission dialog, but other UAs can of course handle this differently.

I can very easily see how a screen lock might be coupled to fullscreen usage, but it is a little trickier when this is only a background window.

Note that once the wake lock tab loses visibility (like when you switch to a different tab or app), or the tab is covered completely by a different window, the wake lock will be auto-released. You can play with our demo in Chrome.

@ekr

This comment has been minimized.

Copy link
Contributor

@ekr ekr commented Jan 22, 2020

@tomayac

This comment has been minimized.

Copy link

@tomayac tomayac commented Jan 22, 2020

Do you have research that users understand what "foreground" means[?]

I defer this question to @engedy.

@bholley

This comment has been minimized.

Copy link

@bholley bholley commented Jan 22, 2020

I think @martinthomson 's point about accountability over permissions is a good one. In that context, I'm not sure it's really necessary to express the concept of foreground at all. We'd just limit the functionality entirely to foreground content, and notify the user (with options for remediation) when it takes effect (e.g. "foo.com is preventing your screen from sleeping, which may drain your battery").

Along those lines, I agree with @annevk that there's no clear way to achieve accountability with the system lock case, since the display is the only obvious indicator that the device is abnormally active.

@fabricedesre

This comment has been minimized.

Copy link

@fabricedesre fabricedesre commented Jan 22, 2020

If you limit the concept to foreground content, that prevents valid use cases like holding a wake lock to ensure a webmail can finish downloading an attachment in the background for instance.

Wake locks are really double edge swords. There are cases where it would make sense to not offer direct access to a wake lock, but instead to add an optional "hold a lock while running that task" features to eg. fetch().

@tomayac

This comment has been minimized.

Copy link

@tomayac tomayac commented Jan 22, 2020

For fetching data in the background, there’s the Background Fetch proposal.

@fabricedesre

This comment has been minimized.

Copy link

@fabricedesre fabricedesre commented Jan 22, 2020

@tomayac thanks, I had forgotten about that one.

@reillyeon

This comment has been minimized.

Copy link

@reillyeon reillyeon commented Jan 22, 2020

From my perspective as co-chair of the DAS WG I don't feel that the system wake-lock portion of the specification is well-considered enough to discuss shipping. As a Chromium contributor I will note that it is not included in the current Blink Intent to Experiment for the Wake Lock API and will not be included in the following Intent to Ship.

I have some ideas for how to expose system wake locks to users, such as requiring a notification indicating a task in progress with a cancelation button that would revoke the lock. I invite Mozilla to continue to engage with this specification through the WG to discuss use cases for and mitigations against abuse of system wake locks.

Despite both being "wake locks" I think the considerations around each type are sufficiently different that it may make sense to split this issue in two. From my perspective getting Mozilla's position on screen wake locks is more valuable as the specification work is more mature and there is another engine considering shipping.

@bholley

This comment has been minimized.

Copy link

@bholley bholley commented Jan 22, 2020

Thanks Reilly, that's helpful context.

Given the above, I'm going to modify the title of this issue to scope the discussion to screen wake locks. If someone would like Mozilla's opinion about system wake locks, we can discuss those in a separate issue.

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator Author

@marcoscaceres marcoscaceres commented Jan 22, 2020

I'd also like to see the "system lock" portion of the API dropped from the spec entirely (w3c/wake-lock#232). I think the screen wake lock use cases for the API are valid and would encourage us to work together with the DAS WG to make sure the API can have a sane activation and user control model.

@marcoscaceres marcoscaceres changed the title Wake Lock API Screen Wake Lock API Jan 22, 2020
@marcoscaceres

This comment has been minimized.

Copy link
Collaborator Author

@marcoscaceres marcoscaceres commented Jan 23, 2020

I've updated the issue's title.

Let's refrain opening a new issue for System Wake Lock. I'll follow up with the WG about removing system wake locks from the current spec. If the WG doesn't agree, we can signal that we consider such wake locks harmful and prefer those use cases be addressed via other APIs (e.g., whatever the appropriate background sync solution ends up being).

I'm unsure any of our positions fit neatly here: it's definitely not "defer", because we see the spec as potentially harmful... but, at the same time, by working on the spec (rather than prototyping it), I'm optimistic it could be made non-harmful and eventually "worth prototyping" in the future.

Do others agree? Does that seem like a good path forward?

@martinthomson

This comment has been minimized.

Copy link
Member

@martinthomson martinthomson commented Jan 23, 2020

This ambiguity is generally true of many specifications that we've reviewed. I think that I'd be comfortable with being supportive of this (or to mark it "harmless"), as long as we are clear in the explanation that this is contingent on some important issues being addressed.

FWIW, I know that we hold our independence with respect to policy decisions close, such that we might see some browsers use explicit prompting for this where others don't. I think that if we were unable to find norms that were at least approximately consistent between browsers then I would be more inclined to say that this is harmful. But I don't see that coming out of this based on this comment which is reassuring.

@bholley

This comment has been minimized.

Copy link

@bholley bholley commented Jan 23, 2020

Yeah, this feels within striking distance of worth prototyping. Rather than articulating an interim position, I'm inclined to just see if we can get the spec on a course we're comfortable with and then mark it as such.

@marcoscaceres

This comment has been minimized.

Copy link
Collaborator Author

@marcoscaceres marcoscaceres commented Jan 23, 2020

I'll work with @reillyeon and the DASWG on it and report back once the spec is looking a little better 🤞.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.