- From: Frederick Hirsch <w3c@fjhirsch.com>
- Date: Mon, 14 Mar 2016 13:42:49 -0400
- To: Andrey Logvinov <alogvinov@yandex-team.ru>
- Cc: W3C Device APIs WG <public-device-apis@w3.org>
we may wish to include Dom's comments as well in what we share. > On Mar 14, 2016, at 1:39 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote: > > I suggest you share this result with PING to see if any further comment on these responses from them (or I can share it if you prefer) > > regards, frederick > >> On Mar 9, 2016, at 6:04 AM, Andrey Logvinov <alogvinov@yandex-team.ru> wrote: >> >> I have reviewed the Wake Lock API spec against the Security and Privacy Self-Review Questionnaire: https://w3ctag.github.io/security-questionnaire/ >> >> Here are the results: >> >> 3.1. Does this specification deal with personally-identifiable information? >> No, the only information Wake Lock API deals with is the Screen.keepAwake boolean attribute, which is set by the page script itself and so it does not constitute personally-identifiable information. >> >> 3.2. Does this specification deal with high-value data? >> No, the Wake Lock API does not deal with user-originated data at all. >> >> 3.3. Does this specification introduce new state for an origin that persists across browsing sessions? >> No, the Screen.keepAwake attribute introduced by the Wake Lock API is not persisted across browsing sessions. >> >> 3.4. Does this specification expose persistent, cross-origin state to the web? >> No. The Wake Lock API exposes no persistent and/or cross-origin state. >> >> 3.5. Does this specification expose any other data to an origin that it doesn’t currently have access to? >> No. The access policy of Screen.keepAwake attribute is that of the Screen object which is not accessible from outside of the Document's effective script origin. >> >> 3.6. Does this specification enable new script execution/loading mechanisms? >> No. >> >> 3.7. Does this specification allow an origin access to a user’s location? >> No. >> >> 3.8. Does this specification allow an origin access to sensors on a user’s device? >> No. >> >> 3.9. Does this specification allow an origin access to aspects of a user’s local computing environment? >> No. >> >> 3.10. Does this specification allow an origin access to other devices? >> No. >> >> 3.11. Does this specification allow an origin some measure of control over a user agent’s native UI? >> No. The Wake Lock API does affect device screen state (on vs off) which is the direct purpose of the API but it doesn't alter any information displayed on the screen. >> >> 3.12. Does this specification expose temporary identifiers to the web? >> No. >> >> 3.13. Does this specification distinguish between behavior in first-party and third-party contexts? >> No, but this shouldn't be an issue because the Wake Lock API does not introduce or use any shared state between script origins. The Wake Lock API specifically does not involve network requests and/or cookies. >> >> 3.14. How should this specification work in the context of a user agent’s "incognito" mode? >> As the Wake Lock API specification doesn't expose any underlying user agent state, it conforms to the "Ideally" case. The website cannot determine if the user is in "incognito" by using this specification. >> >> 3.15. Does this specification persist data to a user’s local device? >> No. >> >> 3.16. Does this specification have a "Security Considerations" and "Privacy Considerations" section? >> Not yet. Though keeping the screen awake is a potential opportunity for DOS-type attack on the user device by keeping the screen on for prolonged periods of time, which might cause the device to consume battery charge faster than the user would normally expect. When the battery becomes fully discharged, the device will turn off and leave the user without access to network and/or phone services, including emergency call service. This is already somewhat mitigated by the limitation that a wake lock request is considered only when the requesting Document is visible. I think "Security Considerations" section is worth adding to the specification. >> >> 3.17. Does this specification allow downgrading default security characteristics? >> No. >> >> -- >> Kind regards, >> Andrey Logvinov >> +7 (903) 600-56-97 >> alogvinov@yandex-team.ru >> > > regards, Frederick > > Frederick Hirsch > Chair, W3C Device APIs WG (DAP) > > www.fjhirsch.com > @fjhirsch > > > regards, Frederick Frederick Hirsch Chair, W3C Device APIs WG (DAP) www.fjhirsch.com @fjhirsch
Received on Monday, 14 March 2016 17:43:19 UTC