- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Nov 2016 12:26:52 +0000
- To: public-device-apis-log@w3.org
Now that we have learned more about the possible attack vectors (thanks to [Chrome and Firefox shipping the API since Oct 2014](http://caniuse.com/#feat=battery-status)), I propose that as a further mitigation strategy against potentially malicious content using the API (e.g. framed tracker scripts) we should consider making the API available only within a [secure context](https://w3c.github.io/webappsec-secure-contexts/#secure-context) that is also a [top-level browsing context](https://www.w3.org/TR/html51/browsers.html#top-level-browsing-context). This would disallow the use of the API within framed content, as well as from any content that is not a secure context. See [top-level documents](https://w3c.github.io/webappsec-secure-contexts/#examples-top-level) and [framed documents](https://w3c.github.io/webappsec-secure-contexts/#examples-framed) for illustrations. Along with [other mitigation strategies](https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0005.html), I believe this would alleviate the concerns raised. There exists a hook in the spec to implement this change with no API surface changes: one could leave the promise returned by [`getBattery()`](https://w3c.github.io/battery/#h-the-navigator-interface) in a pending state if invoked from within a browsing context that is not a secure context and not a top-level browsing context without breaking existing content or leaking any information. @lknik Do you have any concrete input to the normative prose of the spec? -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/battery/issues/5#issuecomment-257554180 using your GitHub account
Received on Tuesday, 1 November 2016 12:26:59 UTC