Introduce rate limiting to prevent wake lock abuse

[arturjanc]

In addition to the security and privacy considerations already covered in the spec (https://www.w3.org/TR/wake-lock/#security-and-privacy-considerations), it seems that there are a couple of other concerns:

1. The side-channel based on the OS-level lock allows communication not only between different documents, but also between completely separate browser profiles or User Agents running on the same device. This may allow identifying users who rely on such compartamentalization for privacy.

2. When a website acquires the Wake Lock, this necessarily leaks a bit of information about user activity to other origins. For example, a screen wake lock may indicate that the user started watching a video.

Is it possible to limit the number of times the User Agent may change the state of a wake lock in a given time period (e.g. on the order of a couple of times per minute)? This would prevent the side-channel concern.

When it comes to (2), I'm not sure about a great way to tackle this, other than perhaps not resolving the promise if the acquirer of the wake lock is cross-origin from the listener. Any ideas?

[andrey-logvinov]

On your first point, I think the communication channel between separate User Agents can be prevented by only reporting wake lock status for this particular user agent, not system-wide status. I.e. when a user agent has not requested wake lock, it will report wake lock status as inactive even though some other user agent or another OS-level application might be currently holding the wake lock.

As for cross-origin channel, I think it is possible to mitigate by only reporting wake lock status to an origin if it has at least one outstanding wake lock request (if it doesn't, report as inactive). In this case, an origin can only see wake lock status if it itself has requested the wake lock and it wouldn't be able to tell if some other origin has also requested it, provided that requests from multiple origins are combined using logical OR (which they are).

@arturjanc
As for number of times limiting, how would this prevent side channels?

[andrey-logvinov]

By the way, the spec already addresses (1), in that it determines wake lock status depending on whether the UA has acquired or released the wake lock, regardless of what other applications do:

Whenever user agent acquires or releases a wake lock, the user agent MUST perform the following steps for each WakeLock object:
If WakeLock object's type attribute is not equal to type, abort these steps.
Queue a task which updates the WakeLock object's active attribute and fires an event named activechange at the WakeLock object.

But I think this should be mentioned more explicitly.

[kenchris]

The side-channel based on the OS-level lock allows communication not only between different documents, but also between completely separate browser profiles or User Agents running on the same device. This may allow identifying users who rely on such compartamentalization for privacy.

The active should only show the state of a given WakeLock object. So even if a existing wake lock is active of the same type, the new object will only report active after it has been activated. UAs can delay resolving the promise to hide whether a wake lock was already active.

That is not how it is done currently, but I think it make sense @reillyeon @anssiko @tomayac

[reillyeon]

My recollection is that acquiring a wake lock doesn't actually take an appreciable time at an OS level and at a browser level we simply maintain a count of the number of WakeLock instances that are active. It is theoretically possible to exploit the slightly longer delay associated with activating an OS level wake lock as a side-channel. This could be mitigated by adding a small delay before resolving the Promise returned by request(). For all practical purposes the uncertainty introduced by cross-process messaging may be sufficient to avoid the side-channel. This will have to be measured.

[marcoscaceres]

I'm going to close this as addressed.

Right now, per spec, the we always call into "acquire a wake lock", which always asks the OS to get the lock. Further, we have a note that makes it clear that:

The acquire a wake lock algorithm may ultimately be unable to acquire a lock from the operating system, but this is indistinguishable from a successful lock acquisition to avoid user fingerprinting (failure to acquire a lock can indicate low battery levels, for example).