Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
63 lines (46 sloc) 3.01 KB

This is to compile our privacy comments regarding the Wake-Lock API.

https://www.w3.org/TR/wake-lock/

Please review the draft specification and share your views.

  • If a web application makes a wake-lock request that is implemented by the user agent, what does this mean for other applications that are set to allow access to geolocation, NFC, camera, microphone when the screen is on?
  • Should this feature only be available in secure contexts?

from Lukasz Olejnik https://github.com/w3c/wake-lock/issues/78

I see several possible security and privacy issues here.

  • Malicious popups/ads claiming some resources and making the device to (1) deplete their batteries (2) trick the user to think their hardware is faulty in some way, make them to install some app to fix the issue.

  • Potential of cross-origin, even cross-browser or cross-device linking/communication? Scenario:

    • App/tab/device1 keeps a lock for e.g. screen

    • App/tab/device2 takes advantage of Ambient Light Sensors and tries to detect whether there is any light source nearby When feasible, this would make the WL API to behave in possibly unexpected ways from security and privacy point of views. This could allow a possible communication channel to either exfiltrate some data or synchronize identifiers.

Therefore I suggest considering the following for this moment:

Implementations should be wary of possible Wake Lock 
API abuses. In certain circumstances, abuse of the API 
could trick the user into performing an otherwise 
unwanted action. An example could be a malicious popup 
attempting to convince the user that the (e.g.) the
screen is faulty

Ability to lock some parts of device peripherals, 
in particular the screen, could possibly open 
unexpected channels of communication, leading to 
cross-domain or cross-device communication and linking

The mechanism SHOULD be subject to permissions.
-> The entire screen wake lock feature is already 
polyfillable with a hidden video tag (see e.g. 
https://github.com/richtr/NoSleep.js) and it 
requires no permissions at all, AFAIK. So even if 
we add a superior security model to this spec, 
malicious site authors will just use other existing 
methods such as the video tag to achieve the same end.

I'm not against introducing permissions for Wake 
Lock API in principle, in fact we considered it 
(please see https://lists.w3.org/Archives/Public/public-device-apis/2016Jun/att-0046/minutes-2016-06-16.html) 
but decided to go with a simpler model at this time.

The User-Agent MUST allow to view the past and 
current Wake Lock usage 
-> This constitutes a conformance requirement, yet 
the spec does not define what it means exactly to 
allow to view the past and current Wake Lock usage
(what is the UI for viewing, how far into the past 
etc). It is also hard (if at all possible) to write 
an automated conformance test for that. I suggest 
using SHOULD instead of MUST, as is the case e.g. 
for Vibration API and Battery API.

Are there any other uses of WL API other than screen?

-> Not yet
You can’t perform that action at this time.