Recommend some UI indicator for when wake lock is active

[David-Chadwick]

Screen-wake-lock if not specified and implemented correctly can be a perfect DOS mode of attack by flattening the battery of the user's machine and rendering it unusable.

1. Whilst only visible documents can acquire the screen-wake-lock, nevertheless the user must be able to control this. Currently the specification says that it is only RECOMMENDED that the user agent shows this to the user, and no reasons are given for this. This should be converted to MUST so that the user definitely has control over it. It you want to stay with RECOMMENDED then you should specify the conditions when MUST does not apply.

2. A state transition diagram would be extremely beneficial to understand when the lock is on or off and how it is activated/deactived etc.

3. The security section as written is rather weak. "Implementations should consider preventing wake lock application if they determine that the remaining battery capacity is low." This is a rather weak statement if we want to prevent DOS attacks. A stronger statement would be "Implementations MUST prevent wake lock application if they determine that the remaining battery capacity is low."

[kenchris]

Btw, today you could do the same by playing back a 1x1 pixel video and it will probably drain the battery faster. Browsers like Chrome will keep the screen alive as long as there is a video playing within the visual viewport

@tomayac

[tomayac]

Btw, today you could do the same by playing back a 1x1 pixel video and it will probably drain the battery faster. Browsers like Chrome will keep the screen alive as long as there is a video playing within the visual viewport

This is the approach taken by the popular library NoSleep.js.

[reillyeon]

Having personally seen my system fail to go to sleep because there is a small video playing on a page I left open the status quo argument isn't particularly compelling to me. A purpose of this specification is to allow sites to be explicit about when they want to acquire a wake lock so that browsers can provide better automated and manual controls to prevent intentional and incidental issues.

As currently implemented in Chromium there is no visible indicator. This concern was raised during internal security review and the winning argument was that the feature announces itself by the fact that the screen remains on and the user is always in control because they can take manual steps to turn the screen off. We agreed that if abuse of the API was observed then further steps could be taken, including adding a visible indicator or automatically denying the wake lock.

At this point in its development I think it is premature to mandate particular mitigations against potential abuse. Browser implementations must be able to evaluate the behavior they see affecting their users and experiment with ways to protect them. I think the current language of SHOULD when it comes to these mitigations is appropriate.

[marcoscaceres]

@David-Chadwick, for completeness and to allow the spec to continue along the W3C Rec Track, are you satisfied with @reillyeon's response?: #282 (comment)

[David-Chadwick]

Not really. If you want to stay with RECOMMENDED then you should specify the conditions when MUST does not apply. Then I will be happy as you are giving guidance to implementors when they can legitimately not show this to the user.

[marcoscaceres]

@David-Chadwick, that's fair. Let's see if we can come up with something together. Let see if we can come up with some draft text and can ping you for review (?).

If anyone wants to propose some text in the meantime, that would be greatly appreciated! 🤗

[marcoscaceres]

@David-Chadwick, reading over the spec text, and giving this some more thought:

you should specify the conditions when MUST does not apply. Then I will be happy as you are giving guidance to implementors when they can legitimately not show this to the user.

Having worked with a lot of browser security UX teams, I think this would be overstepping. Browser security XU teams are in the best position to decide when and how indicators are shown. The spec says:

It is RECOMMENDED that a user agent show some form of unobtrusive notification that informs the user when a wake lock is active...

I don't think we can mandate anything beyond the above, as browser UX is outside our purview.

As an example, browsers like Safari already show notifications (not specifically indicators) when a tab is using significant memory (which could be adapted to show the same thing when a tab is having a significant impact on battery life).

Similarly, Firefox allows users to access a tab's "energy impact" usage via "about:performance":

Thus, to concur with what my colleague @reillyeon said above #282 (comment) - it wouldn't be appropriate for us to mandate anything beyond the above RECOMMENDATION.

I'm going to go ahead and close this and there is no further action can be taken here.

However, happy to continue to discuss alternative viewpoints.

[David-Chadwick]

From RFC 2119 ""RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and carefully weighed before choosing a different course."

So you could add some text along the following lines "To not do so could severely impact the user by draining the device's battery and depriving the user from further using their device."

Kind regards
David

[marcoscaceres]

That's a good suggestion, @David-Chadwick... I might make frame it like:

"Providing such an indicator (or UI that serves a similar function) could help end users to identify if a particular web application is having a negative energy impact on the device, and allow them to take action if so desired."

[David-Chadwick]

Yes fine, many thanks

[marcoscaceres]

Sent a PR with the suggested text #323 - ☝️ @xfq for wide review tracker 🙏

[marcoscaceres]

@David-Chadwick, I moved your suggestion for a state-change diagram to #325 so we don't lose track of it. That was a really good suggestion.