W3C home > Mailing lists > Public > public-device-apis-log@w3.org > November 2016

Re: [battery] Mitigating potential privacy-invasive usage

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
Message-ID: <issue_comment.created-257554180-1478003210-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:52 UTC