Screen Wake Lock API

[marcoscaceres]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Wake Lock API
• Specification or proposal URL: https://w3c.github.io/wake-lock/
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1589554
• Mozillians who can provide input (optional):

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/

[annevk]

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]

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]

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]

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]

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]

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]

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

[tomayac]

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]

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]

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]

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]

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]

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]

On Wed, Jan 22, 2020 at 6:04 AM Thomas Steiner ***@***.***> wrote: 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.

Do you have research that users understand what "foreground" means. Given the description you provide of Chrome's behavior, this seems like a somewhat complicated concept.

[tomayac]

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

I defer this question to @engedy.

[bholley]

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]

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]

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

[fabricedesre]

@tomayac thanks, I had forgotten about that one.

[reillyeon]

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]

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]

I'd also like to see the "system lock" portion of the API dropped from the spec entirely (https://github.com/w3c/wake-lock/issues/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]

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 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]

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]

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

[bholley]

Given the Intent to Ship, it seems worth inquiring on the status of the spec. @marcoscaceres , can you provide an update?

[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/uDn6a9fquCM

[dbaron]

How confident are you about worth prototyping as compared to non-harmful? (In particular, do you think the feature is valuable enough to qualify for the former, including consideration of both the feature benefits and the battery life risks?)

[marcoscaceres]

Because of the potential abuse cases, I would not be confident marking this as non-harmful right now. That said, significant effort has gone into making sure any harm is minimized (e.g., only first party unless granted by feature policy, requiring a permission, changing focus releases the lock, users are in control, etc.). Thus, I'm seeing worth prototyping as a way for us and the DAP WG to continue exploring how to minimize any potential harms we might have overlooked at this early stage.

Is that a backwards way of looking at it? Or is that ok?

[bholley]

How confident are you about worth prototyping as compared to non-harmful?

I think there is value in replacing NoSleep.js with something that gives users more agency. Per #210 (comment) I think it's hard to be certain whether the net ecosystem impact will be positive. But given that the API allows us to (a) implement accountability out the gate, and (b) restrict the capability in response to what we see in the wild, I think it's worth a shot.

[anssiko]

Wake Lock API case study: 300% increase in purchase intent indicators on BettyCrocker.com:

https://web.dev/betty-crocker/

Cc @tomayac to answer any questions you may have.

[marcoscaceres]

Pretty neat and exactly the kind of use case I’d envisioned. As someone who cooks a lot from websites, really encouraging to see (more so, the engagement metric). Hopefully we get support for this in Fx too, in the not too distant future 🤞

[marcoscaceres]

Given recent changes at Mozilla, I wonder if it might be worth reevaluating Mozilla's position on this? Right now, there is a sense of hope that Mozilla might prototype this. If that is no longer the case, it might be prudent to reappraise the position to "defer" as to not provide false hope that work is happening on this specification.

[mconca]

Given recent changes at Mozilla, I wonder if it might be worth reevaluating Mozilla's position on this? Right now, there is a sense of hope that Mozilla might prototype this. If that is no longer the case, it might be prudent to reappraise the position to "defer" as to not provide false hope that work is happening on this specification.

I can see how the semantics of "worth prototyping" might imply more action than what is currently happening, but it feels like the position assigned to a specification should be independent of the implementation. Priorities change all the time, and Mozilla may (will) shift resources around based on what we deem to be important at any given time. The merits of a specification, though, should be judged independently, decoupled from the whims of business decisions.

[bholley]

I'll also just note that I don't think recent changes at Mozilla are all that relevant to this issue. This wasn't on any team's roadmap in March [1], and Gecko resourcing hasn't changed dramatically since then either. So while I agree the Firefox team is unlikely to be working on this feature soon, that's because it remains a lower priority for us than other opportunities to advance the Web, and not because of any kind of organizational or strategic change.

We'd certainly consider taking a patch though!

[1] As @mconca correctly notes, "worth prototyping" describes our willingness to experiment with the feature in Firefox rather than any commitment to resourcing it (though I can see how Marcos' comment in May could be misunderstood to imply that resourcing for this particular API was imminent).

[marcoscaceres]

though I can see how Marcos' comment in May could be misunderstood to imply that resourcing for this particular API was imminent

Apologies, I didn't mean to imply that. Thanks for clarifying.