- From: Nick Doty <npdoty@berkeley.edu>
- Date: Fri, 29 Sep 2017 13:23:30 -0700
- To: Christine Runnegar <runnegar@isoc.org>
- Cc: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
- Message-Id: <7FA71655-B18E-49D4-8EC3-E32729BF1BCE@berkeley.edu>
On Sep 26, 2017, at 4:00 PM, Christine Runnegar <runnegar@isoc.org> wrote: > > => An updated Wake Lock API (on its way to CR): https://www.w3.org/TR/wake-lock/ <https://www.w3.org/TR/wake-lock/> I think we should probably be looking at the current editor's draft: https://w3c.github.io/wake-lock/#security-and-privacy-considerations <https://w3c.github.io/wake-lock/#security-and-privacy-considerations> > Changes include: … support for system wake lock use cases, addressing feedback from the TAG [2], updates to promise handling, changes to clarify state transitions when the device is manually > locked, updates to the security and privacy considerations (including update to self-review questionnaire [3]) and editorial fixes. We discussed Wake Lock on a call last year, and there have been a few issues raised regarding its security and privacy considerations. Notes from last year: https://github.com/martasect/ping/blob/af74fb50958671f248b521f215a9b953019ec6cc/wake-lock-privacy.md <https://github.com/martasect/ping/blob/af74fb50958671f248b521f215a9b953019ec6cc/wake-lock-privacy.md> Issues: https://github.com/w3c/wake-lock/issues/78 <https://github.com/w3c/wake-lock/issues/78> https://github.com/w3c/wake-lock/issues/77 <https://github.com/w3c/wake-lock/issues/77> I'm concerned that currently the Security and privacy considerations section is listing a series of issues without presenting any mitigations. Yes, some cross-origin communication is enabled. Yes, locking can be used to harm the user. Yes, the request system makes it possible to identify if the battery is low. Can UAs mitigate these harms beyond not implementing the API? In addition, it seems like global event triggering here can allow for additional means by which separate origins can identify that they are running on the same device. The harms of this are mitigated in part by the default origin policy ["self"], which means that embedded third-party iframes won't have access unless explicitly granted it by the hosting site. It wasn't clear whether Wake Lock (both the promise request and the subscription events) are limited to currently visible pages, though that seems like a useful mitigation. —Nick
Received on Friday, 29 September 2017 20:23:55 UTC