Mitigating potential privacy-invasive usage #5
Comments
|
Interesting issue. Since the considerations advise:
Would it be a good idea to consider returning a "fully-charged status" in such cases? |
|
@marcoscaceres do you have concrete proposals how to fix the API to allow you to continue ship the API and feel good about it? |
anssiko
changed the title
|
@marcoscaceres @anssiko I don't think the proposed conversation at TPAC happened; meanwhile, we ought to decide what the right next steps for this API should be (scrap, amend, or finalize) |
|
We ran out of time at TPAC (had so intense discussions related to sensors). I've seen no concrete solutions, so I'd amend the spec with non-normative text that makes it clear what the concerns are, and finalize it. The API ships in http://caniuse.com/#search=battery |
|
Just a slight addenum, aren't the current privacy considerations already reflecting it? |
|
It would be great if you @lknik could help review the current considerations section and let us know if we indeed have covered all of the Mozilla's concerns. |
|
Concerns specified in https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0000.html |
|
Let's add at the consideration's end:
(I don't think we should link to any media reports/blogs and mentioning media posts in the spec are probably not good practices?) We can also consider changing MAY to SHOULD, so rephrase:
to:
|
|
Hi, Just did it here lknik#1 |
|
@marcoscaceres does lknik#1 document your concerns adequately? |
|
Per https://bugzil.la/1313580 Mozilla is in process of unshipping the web-facing Battery Status API. Given the API is pretty high on the Edge wish list, we should probably consult other implementers on their interests and plans before we do any decisions in terms of Rec Track advancement. Also UC Browser with 17% worldwide market share on mobile has partial support per http://caniuse.com/#feat=battery-status |
|
Now that the unshipping news broke, there are strong reactions for and against, as expected. I'll add some pointers to historical discussion below in case we'll revisit this topic. Further pointers to helpful fact-based discussion welcome. Mozilla's heads-up: Mitigation strategies: Use cases: https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0011.html |
anssiko
changed the title
|
Now that we have learned more about the possible attack vectors (thanks to Chrome and Firefox shipping the API since Oct 2014), 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 that is also a 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 and framed documents for illustrations. Along with other mitigation strategies, 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 @lknik Do you have any concrete input to the normative prose of the spec? |
|
Ping @cpeterso for Mozilla's comments. |
|
Limiting access to the API (to a secure context of a top-level document) is good. Prompting the user for permission is another option, though I don't think most users can make an informed decision about allowing access to the battery status. Identifying the use cases for the battery API would help show where the API is exposing more information than necessary. For example, is |
|
@cpeterso Thanks for your comments. My response below is a bit wordy since I wanted to include some historical perspective, hope it's useful. As the co-editor of the spec, I've been watching from the front row how the spec has developed over the years, driven by implementers' feedback. About prompting: You're right about prompting. Studies show normal users do not grasp the concept. That's why prompting is not required, it is just an option ("The user agent may ask the user for battery status information access."), and not the only mitigation mechanism. About use cases: None of the high value use cases for browsers that I know of require high precision readouts. For example, all the use cases I enumerated are implementable with less precise readouts. How precise the readout is for each of the property of (We'd be happy to make this even more clear and concrete, we're open to suggestions for better wording.) The spec leaves it up to the implementation to decide what is considered the right precision for each property. Each browser strikes a different balance between privacy and exposing powerful features. The spec as worded allows implementers to innovate and compete in this regard, while still remain spec-compliant. For example, a privacy-aware browser might expose just hardcoded 20% or 80% readouts or round time-related readouts to nearest hour, while another implementation might offer higher precision readouts e.g. in cases when the user has established a stronger trust relationship with the web page. For example, a Progressive Web App that has been installed might get higher precision readouts. The API surface remains the same. There's more room for innovation here for browser vendors. About the history of the API: The API was refactored since Mozilla's initial Firefox OS-inspired proposal to make it browser-friendly and privacy-aware. Namely, in the current API After these changes Google felt good shipping the API in Chrome. |
|
Hi @anssiko you are right, let's go with top-level and secure contexts. Also, since high-level sensors won't provide too much details by design, why not considering to split Battery in a high/low-level sensor fashion? Thank you also for the historical perspective. However, the issue is that if someone wants to profile the user based on his device battery use, the situation is still somewhat tricky. Let's say that an Honest Ahmed Bicycle Service (HABS) observes that, say, people on Friday night tend to be a bit in a rush to get back home, and when their devices are low on battery they would tend to agree to pay more for a service... In those cases, even minimized data could reveal actionable insight. Thad said, on the technical side - I made sure that the wording in suggestions/considerations was adequate and it was leaving enough room for vendors. Thank you for a the context behind FirefoxOS motivations. I agree about user awareness. Browsers should offer sane settings by default. I'm also unsure about the real use cases for chargingTime/dischargingTime. Sounds like the real need for those is not clear. How about (@anssiko ?) sanitizing/removing those or make them optional? If not, I would still suggest to vendors to think whether these are needed, and how the actually reported values should be processed... Designing general privacy-vetted strategies APIs for browsers sounds just exciting. |
Mapping of "low", "medium", and "full" to implementation-specific
As the spec editor, I can't just remove features from the spec that are shipping. Implementers can make them less precise if they wish. Only if all the implementers agree, we can consider removing features from the spec. |
|
We agree on the minimization side, it was under long (more than a year now?) discussion, so good! As per the spec editing details - I understand. Thanks for clarifying. |
|
Given that browser vendors are pulling the API, we should rescind this spec and move on. |
|
@marcoscaceres Please note the concrete privacy-vetted mitigation strategies discussed in this issue are generic, not specific to this API -- they apply more broadly. I feel giving up would set a wrong precedent. My personal motivation is to identify concrete proposals reviewed by domain experts, so that we can collectively continue to ship powerful features on the Web in a privacy-aware manner also in the future. Looking at the current browser market share, especially on mobile (bigger than desktop browsing now) where the use cases are the most powerful, recent pull offs have practically no real-world impact. I'm all in for improving the spec together with implementers who don't feel like giving up on powerful features is the way to go. |
|
Agree with the motivations and goals, don't get wrong. But we are not talking about all features here, we are talking about one. We learned a lot from battery (that we can now apply more generally), but if it's being removed from browsers, we should consider rescinding it nonetheless. The question is: what UAs will continue shipping the API? and if we will have enough implementations to warrant continuing to push forward with it. |
Per http://caniuse.com/#feat=battery-status (show all) the UAs currently shipping include Firefox, Chrome, Opera, Android Browser, Opera Mobile, Chrome for Android, Firefox for Android, UC Browser for Android (partial), and Samsung Internet. Edit: Also Yandex Browser for Android ships the API with an innovative approach to privacy. I'm excited to see such innovation in exposing powerful features in a privacy-aware manner. Kudos! I feel it is my responsibility as the spec editor to keep maintaining and improving the specification as long as there are implementations, and that's why I'd like to keep this issue open. |
|
Ok, but it's no longer exposed to web content on the Mozilla side (so that affects all Firefox versions). If Blink decides to also unship it, then Blink-dependent browsers will be affected (taking the list above to zero implementations). Any word on what Blink folks are planning to do? |
|
|
It's recently linked with Blink>PermissionsAPI component in Blink. |
|
I opened #10 for the proposed concrete spec update, and will close this issue. |
…face. In other words, stop exposing this API to insecure origins. This has been discussed since at least 2016 (see #5). #11 made access from an insecure origin throw a SecurityError at a time when the `[SecureContext]` Web IDL extended attribute was not widespread. Unfortunately, the spec change was not accompanied by a change in the implementation(s) and, to this day, Blink's implementation (the only remaining one) continues to expose the API to insecure origins. Years later, #30 was added in the context of the discussions in #15 where it was noted that the spec was still manually throwing a SecurityError when checking if it was called by a secure origin. Besides stopping throwing a SecurityError (which was never implemented), #30 also recognized the current situation by noting that the API _should_ use `[SecureContext]` but did not because it only made sense to do so when the implementation was updated accordingly. This change finally adds `[SecureContext]` to the spec's Web IDL because I am also handling the Blink implementation [1][2]: starting with Chrome 99, users will be warned that using the Battery Status API in an insecure origin is deprecated, and starting with Chrome 103 doing so will no longer be possible. [1] https://chromestatus.com/feature/4878376799043584 [2] https://groups.google.com/a/chromium.org/g/blink-dev/c/w80tJL8uEV8/m/PfrHlvtgAgAJ From a testing perspective, there isn't much to be done: - web-platform-tests/wpt#5871 changed the existing tests to run in HTTPS. - web-platform-tests/wpt#32556 removed the test for the SecurityError exception that never passed. Fixes #15
…face. In other words, stop exposing this API to insecure origins. Even though this API is not new, it provides user information that, transmitted insecurely, can pose a risk to user privacy. See https://w3ctag.github.io/design-principles/#secure-context for more information on the guidelines we are trying to follow. This has been discussed since at least 2016 (see #5). #11 made access from an insecure origin throw a SecurityError at a time when the `[SecureContext]` Web IDL extended attribute was not widespread. Unfortunately, the spec change was not accompanied by a change in the implementation(s) and, to this day, Blink's implementation (the only remaining one) continues to expose the API to insecure origins. Years later, #30 was added in the context of the discussions in #15 where it was noted that the spec was still manually throwing a SecurityError when checking if it was called by a secure origin. Besides stopping throwing a SecurityError (which was never implemented), #30 also recognized the current situation by noting that the API _should_ use `[SecureContext]` but did not because it only made sense to do so when the implementation was updated accordingly. This change finally adds `[SecureContext]` to the spec's Web IDL because I am also handling the Blink implementation [1][2]: starting with Chrome 99, users will be warned that using the Battery Status API in an insecure origin is deprecated, and starting with Chrome 103 doing so will no longer be possible. [1] https://chromestatus.com/feature/4878376799043584 [2] https://groups.google.com/a/chromium.org/g/blink-dev/c/w80tJL8uEV8/m/PfrHlvtgAgAJ From a testing perspective, there isn't much to be done: - web-platform-tests/wpt#5871 changed the existing tests to run in HTTPS. - web-platform-tests/wpt#32556 removed the test for the SecurityError exception that never passed. Fixes #15
…face. In other words, stop exposing this API to insecure origins. Even though this API is not new, it provides user information that, transmitted insecurely, can pose a risk to user privacy. See https://w3ctag.github.io/design-principles/#secure-context for more information on the guidelines we are trying to follow. This has been discussed since at least 2016 (see #5). #11 made access from an insecure origin throw a SecurityError at a time when the `[SecureContext]` Web IDL extended attribute was not widespread. Unfortunately, the spec change was not accompanied by a change in the implementation(s) and, to this day, Blink's implementation (the only remaining one) continues to expose the API to insecure origins. Years later, #30 was added in the context of the discussions in #15 where it was noted that the spec was still manually throwing a SecurityError when checking if it was called by a secure origin. Besides stopping throwing a SecurityError (which was never implemented), #30 also recognized the current situation by noting that the API _should_ use `[SecureContext]` but did not because it only made sense to do so when the implementation was updated accordingly. This change finally adds `[SecureContext]` to the spec's Web IDL because I am also handling the Blink implementation [1][2]: starting with Chrome 99, users will be warned that using the Battery Status API in an insecure origin is deprecated, and starting with Chrome 103 doing so will no longer be possible. [1] https://chromestatus.com/feature/4878376799043584 [2] https://groups.google.com/a/chromium.org/g/blink-dev/c/w80tJL8uEV8/m/PfrHlvtgAgAJ From a testing perspective, there isn't much to be done: - web-platform-tests/wpt#5871 changed the existing tests to run in HTTPS. - web-platform-tests/wpt#32556 removed the test for the SecurityError exception that never passed. Fixes #15
…face. (#51) In other words, stop exposing this API to insecure origins. Even though this API is not new, it provides user information that, transmitted insecurely, can pose a risk to user privacy. See https://w3ctag.github.io/design-principles/#secure-context for more information on the guidelines we are trying to follow. This has been discussed since at least 2016 (see #5). #11 made access from an insecure origin throw a SecurityError at a time when the `[SecureContext]` Web IDL extended attribute was not widespread. Unfortunately, the spec change was not accompanied by a change in the implementation(s) and, to this day, Blink's implementation (the only remaining one) continues to expose the API to insecure origins. Years later, #30 was added in the context of the discussions in #15 where it was noted that the spec was still manually throwing a SecurityError when checking if it was called by a secure origin. Besides stopping throwing a SecurityError (which was never implemented), #30 also recognized the current situation by noting that the API _should_ use `[SecureContext]` but did not because it only made sense to do so when the implementation was updated accordingly. This change finally adds `[SecureContext]` to the spec's Web IDL because I am also handling the Blink implementation [1][2]: starting with Chrome 99, users will be warned that using the Battery Status API in an insecure origin is deprecated, and starting with Chrome 103 doing so will no longer be possible. [1] https://chromestatus.com/feature/4878376799043584 [2] https://groups.google.com/a/chromium.org/g/blink-dev/c/w80tJL8uEV8/m/PfrHlvtgAgAJ From a testing perspective, there isn't much to be done: - web-platform-tests/wpt#5871 changed the existing tests to run in HTTPS. - web-platform-tests/wpt#32556 removed the test for the SecurityError exception that never passed. Fixes #15
Starting with a concern raised in https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0000.html (see the full thread), we ended up discussing the permission model for the API, in particular why it is different from other APIs.
Let's use this issue to document proposed solutions that could be transformed into spec prose, while keeping compatibility with the existing shipping implementations.
The text was updated successfully, but these errors were encountered: