DASWG: Drop Battery API for privacy and lack of implementer support #98
Comments
|
All privacy issues brought up to the group's attention have been documented [1] and reviewed with privacy experts [2] with mitigations specified [1]. The latest version of the Battery Status API has wide implementer support [3]. The DAS WG is commitment to security and privacy focused and use case-driven specification development and believes ceasing this work would be considered harmful. [1] https://w3c.github.io/battery/#security-and-privacy-considerations |
This is a question that came up several times during the discussion of the PrivacyCG charter, on how to distinguish "Google developed something up stream and downstream chromium folks haven't [yet?] pulled it out" vs "the down stream chromium folks support and think its good for the web." In other words, does "its in chromium" count as one implementor, or many? privacycg/privacycg.github.io#9 I dont think there was a clear answer to the above, but I think its fair to say that the general tenor of the conversation (including from the Google rep into the convo privacycg/privacycg.github.io#9 (comment)) was the former (if Google implements, thats one implementation, not many, unless someone downstream affirmatively says otherwise). |
|
Looks like there may just be a bug in caniuse's data, since it seems removed in gecko and Moz's docs. @anssiko is there a second, non blink implementation (or interest)? |
|
Yes, for example QQ Browser. |
|
@anssiko i am extremely not familiar with QQ browser, and couldn't easily find which engine it uses, but according to wikipedia at least, its also chromium, no? |
|
QQ Browser is interesting in a sense it supports multiple engines in some of its versions. see also UC Browser and KaiOS Browser that support the API. |
|
according to wikipeida at least, UC browser is also blink. KaiOS seems to use the Moz implementation that Moz no longer supports. Thats an interesting "implementor interest" situation i haven't seen considered anywhere 🤔 |
|
Some versions of UC Browser in the wild are based on “U3” which is a WebKit fork. All these browsers and their versions add up to global browser support in the ballpark of ~73% for this API per caniuse.com. Notably, the API is used in ~11% of page loads in Chrome per Chrome usage metrics. DAS WG is a global community that encourages implementations also by browsers not known to the Western world. |
|
It seems pretty unlikely those we would count those as implementations for the purpose of progressing the specification along the recommendation track, right? At least, without subverting the W3C process. [3] clearly shows that this doesn't have "wide support" in the same way we would consider other platform features (implemented in Gecko and WebKit) - only really single engine support, so it's pretty unlikey to reach REC status.
This should ring alarm bells. Do we know what possible reason a web page have to accessing this API? such high usage points to it being used by one or more trackers.
That's great! And all browsers engines are open sources so people from all over the world contribute to them, but there only 3 of them - so we can't really count chromium wrappers are independent implementations. |
|
Ok, yes, it's used as part of a tracking script: YouTube Widget. That would explain the wide distribution and not actual real usage. |
|
I think we should do some digging via GitHub search to see if we can find some legitimate uses of the API... I did a quick search, and didn't find much, but we should dig deeper. |
We’re not discussing a transition request in this issue. On topic, for consideration:
I did a search in this repo, and found these comments interesting: There are probably more, and in the spirit of use case-driven specification development, I suggest we document these in the specifications directly. Please add your findings to w3c/battery#25 |
|
Sure, the above are interesting, but they need to be balanced out with the actual risk that this is being used to track users. And we should see if there is anyone actually using in the way that Mounir and Rick suggest, otherwise it's just speculative and hypothetical (which is not a great reason to make something a Rec). As Rick suggests, we could start by clamping down the API by turning off by default and only enabling it via Permissions Policy. That would at least restrict third-party trackers. |
|
Ah, just saw that the Editor's draft has permissions policy, but /TR/ hasn't been updated (shakes first at /TR/ again). |
|
I just had a look at some common tracking/fingerprinting libraries, but didn't find any one that uses Battery Status API. (See fingerprintjs/fingerprintjs#55 for an issue in a popular fingerprinting library.) FWIW: Electron can monitor power state changes, but uses a different API. Some (but not all) MiniApp implementations support getting battery information. (See Baidu Smart Programs for an example.) |
|
That issue was closed in 2016, so might warrant new investigation. Again, the fact that 11% of sites are reporting using this API rings alarm bells.
Like in this case, that doesn't equate to legitimate uses of the API (i.e., non-tracking ones, inline with the use cases). Exposing the API doesn't really mean much. @pes10k, as someone who works with the Chromium community, could you check if anyone has sent a patch to plug the Permissions Policy hole as well as the The spec claiming to be private to be private by just adding Permission Policy and Can we change this group's working mode so that things don't land in specs before they implemented or have real implementation commitment? Otherwise, we are just pretending to make the web better and again misusing the W3C process. All specs in this group should be using: https://github.com/w3c/web-share/blob/master/.github/PULL_REQUEST_TEMPLATE.md to avoid us getting into this situation going forward. |
It would be useful if we have concrete examples of this. Can I get a pointer to a website (or a few websites, preferably well-known ones) that uses the Battery Status API for tracking? |
|
The Chrome usage stats point to websites. All those websites embed YouTube videos, and those videos embed the script: Search for getBattery() there. YouTube is a tracking widget.
Any website that embeds YouTube embeds a tracker. So basically pick any website you like, if it has a YouTube video, it has a reference to the API. Now, deciphering what the base.js script does is a different story, because that code is obfuscated... but I bet ya if Chrome turns on Permissions Policy the usage of this API drops to 0. Now, as a counter, would be nice to see one popular site using this in a legitimate (non-tracking) fashion - and in a way that benefits users at all. |
|
(trying to summarize conversations that have happened across email and slack and other similar GH issues) RE implementor threshold: I take @cwilso's point that something not-yet-being-implemented shouldn't be a blocking concern to include something a WG's charter / scope . But I think the concern here is different. Its not that there isn't enough implementation; its more that there has been implementation experience, and we learned that the majority use of these APIs are user-harmful. Thats not in-and-of-itself a reason to oppose trying again, things could go better the second time around. But its equally reasonable to conclude from previous implementation experience that these kinds of features might just be broadly on the wrong side of a risk / benefit trade off. (Thats at least what motivated my complaint / vote). In other words, "there aren't enough implementors for the WG to take it on" is a silly complaint, but "based on previous experience, we don't think this should be part of the web platform" seems like a totally valid (procedurally and on the substance) reason to remove items from the group's charter / scope of work. |
It's not. It's completely valid. A single implementer spec is not a standard.
I disagree. And this one provable. @pes10k, stop avoiding my direct question: is Brave going to do the work to actually enable Additionally, if Intel and Google are not going to do the actual work. They we should remove |
Sure, but we're not discussing whether this should be a spec, this discussion is about whether a WG should take on work for something that might eventually become a spec. I think we're agreeing on the broad point, but "there aren't currently enough implementations" is not in and of itself a reason to ask a WG to stop working on an item; it just means its not ready to move to rec.
Sorry, im not following, what are you disagreeing with? I / Brave voted the same way as Moz / @tantek here.
Please take the temperature down a bit here @marcoscaceres! I'm not avoiding a question, it looks like I missed a single GH message. But no, Brave has no intention to do any work at all implementing anything relating to the battery API. We don't support it. |
Really, then what's this?
Please understand why I'm getting really pissed off here: Brave is part of the Chromium project and you ship the API (I guess you didn't know that, surprise! 🎉 ), but you seem unwilling to go an actually fix stuff in the Chromium project you depend on. Anyway, seems like the only solution here is remove |
|
Those are the fake values we return to avoid breaking websites:
I don't know where this is coming from, but there has to be a better place for us to discuss than in this issue thread |
|
It relates directly to the discussion we are having here: It's hard to make a case that the spec should be killed when even well meaning implementers, like Brave, are unwilling to follow the spec with regard to SecureContext and Permissions Policy even when returning bogus values. See what I mean? |
|
There is an active Intent to Ship thread for implementing the specified Permissions Policy (and perhaps SecureContext) integrations in Blink: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/sUs1KsQaXjA |
|
Oh, that's great to see @reillyeon. Thank you! Looks like Blink folks are coming to the same conclusions. If the mitigations get shipped, I'm still betting on usage going down to 0.00n% usage (and this becoming non-harmful). At the same time, I'm hopeful we can see some legit breakage, so to allow us to deal with those legitimate cases better (e.g., if YouTube is actually using it for some codec selection, then that's probably better done in the At the same time, it seems Dev Tools is in a way better position to provide accurate battery consumption information on a per tab basis (see "about:performance" in Firefox), which provides a real time view of energy impact of a tab.
|
|
Most sites that want to use this API for good™ arguably just need to know if the battery level is below a certain limit (where commonly the OS's battery saver mode would kick in). Another way to convey this data could be to expose this info similar to how |
|
Those are good suggestions @tomayac. I'm still hopeful we can see actual cases where something like "prefers-reduced-energy" would help... like what would added/removed/changed. We talked about video above, so we would need to figure out if it could help there.... like, if |
|
Sorry for dropping in, but in summary, are there any conclusions reached here? ;-) |
|
My feeling on this discussion is that there is evidence that there are legitimate reasons for sites to react to the amount of power available in a device and the amount of power they are consuming. There are a number of proposals in this area, of which the current Battery Status API is one. There is also general agreement that the current design of that API is not the one we want to have in the platform. I would prefer that we were able to get this level of interest and engagement in developing better proposals during normal working group meetings, rather than in response to a unilateral request to cease working in this area entirely. |
|
The Director has approved the Devices and Sensors Working Group charter, and took into consideration the input from an experiment conducted by the Advisory Board and the TAG and decided that a chartered Working Group was best suited to address these concerns. These concerns will not be ignored but the discussion should be moved into the individual specification issue tracker where the concerns can be addressed. Moreover, the Director recommended this document be republished as a Working Draft, with a Changes section. See https://lists.w3.org/Archives/Member/w3c-ac-members/2020OctDec/0034.html (member-only link) for the Director's decision. |
Per DAS charter feedback: On the the grounds of privacy, and given a lack of implementer support, we would like the Devices and Sensors Working Group to cease work on the Battery API and see it published as a Working Group Note instead.
cc: @dwsinger @pes10k @marcoscaceres
(Originally published at: https://tantek.com/2020/188/b1/das-drop-battery-api)
The text was updated successfully, but these errors were encountered: