LGTM -Ekr
On Fri, May 25, 2018 at 5:23 PM, L. David Baron <dba...@dbaron.org> wrote: > OK, sorry to not get this drafted until too close to the deadline to > be likely to get feedback, but here's what I currently have for > proposed comments that I'll submit on the charter. (If you happen > to be able to get feedback to me in the next 3 hours, great... > otherwise feedback may still be useful for later followup > discussions.) > > -David > > ------ > We'd like to see this charter change a bit. That desire for change > comes out of our concern about the privacy implications of many of these > APIs. Researchers have demonstrated that a number of these APIs can be > used for tracking users or for learning various other types of > information about what users are doing, and some of these have actually > been used for tracking web users. See, for example, this pair of > articles about use of the battery status API for tracking: > https://www.theguardian.com/technology/2016/aug/02/ > battery-status-indicators-tracking-online > https://www.theguardian.com/technology/2016/nov/01/ > firefox-disable-battery-status-api-tracking > > The APIs proposed in this charter have varying amounts of privacy risk. > It is likely that some of them can be structured to provide a reasonable > amount of information with meaningful user consent, but some of them > cannot. Therefore we'd like it to be more explicit in the charter that > concluding that a specification cannot be done in an appropriate way is > a possible success condition of the working group. (The charter > currently mentions that "APIs that cannot be demonstrated to be > implementable securely within the default browser context will not be > released.", but this doesn't explicitly mention privacy and it doesn't > explicitly say that abandoning work is a desirable outcome if that's the > appropriate choice.) > > The APIs that we're most concerned about in this regard are: > Battery Status API > See articles cited above; we previously unshipped support for this. > Network Information API > (I should have more details here, but don't.) > DeviceOrientation Event specification > (I should have more details here, but don't.) > Proximity Sensor > Ambient Light Sensor > Accelerometer > Gyroscope > Magnetometer > Orientation Sensor > These sensors have the problem that web access at a high enough > resolution to be useful for many of the use cases allows sites using > the API to learn various sorts of information about the user that > are hard to explain in a way to get good informed consent, such as > where the user is, what sort of activities they're doing, what > they're typing, what activities are happening nearby, etc. > > See, for example: > https://blog.lukaszolejnik.com/privacy-of-ambient-light-sensors/ > https://blog.lukaszolejnik.com/stealing-sensitive- > browser-data-with-the-w3c-ambient-light-sensor-api/ > https://blog.lukaszolejnik.com/privacy-analysis-of-w3c- > proximity-sensor/ > https://www.bleepingcomputer.com/news/software/firefox- > gets-privacy-boost-by-disabling-proximity-and-ambient-light-sensor-apis/ > https://dieidee.eu/2015/10/14/accelerometer-and-gyroscope- > sensor-data-can-create-a-serious-privacy-breach/ > > > > While it's useful to have a forum that is appropriate for discussion of > how to address these privacy issues, I don't think there is currently > consensus that it is appropriate to make these APIs part of the web > platform. Normally I think that would suggest that the documents aren't > ready to be put on the Recommendation track; in this case things are > more awkward because many of them are already on the Recommendation > track. (That said, it's not entirely clear to me whether AC review of a > charter is expected to represent consensus that a specification is > appropriate for the Web.) > > Given that, it would be preferable to move some of these documents off > of the Recommendation track back to earlier stages of incubation until > there's a clearer path for addressing the privacy concerns with them. > If that isn't possible, the working group should at least be given the > explicit possible success criterion of choosing that particular > specifications are not viable, and should be tasked with building > broad consensus outside of the working group that the proposed APIs are > suitable for the web. > ------ > > On Friday 2018-05-04 11:40 -0700, Kyle Machulis wrote: > > Filling in some of the gaps here: > > > > WakeLock API is still used on android, afaik so we don't let the phone > turn > > off while playing media. > > > > We ship the Vibration API on android, have since FxOS. Not much happening > > there these days, other than some discussion about permissions around it. > > > > We still have battery code around Firefox, but the API isn't exposed to > > content. I think we're still trying to figure out whether to just > > completely remove it. > > > > DeviceOrientation is shipped everywhere, weirdly enough. There's a bug to > > fix that for platforms where we don't have info about it. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1037982 > > > > On Thu, May 3, 2018 at 11:02 PM, Anne van Kesteren <ann...@annevk.nl> > wrote: > > > > > On Fri, May 4, 2018 at 2:07 AM, L. David Baron <dba...@dbaron.org> > wrote: > > > > On the flip side, sensor APIs are offered by mobile (and to some > > > > degree desktop) operating systems and widely used by apps running on > > > > them, and there's clear demand for having them on the Web. So I > > > > think it seems worth having a clear venue for that discussion, which > > > > would suggest that it's good to have the discussion in the scope of > > > > the working group. > > > > > > This is true for a number of APIs not offered by the web, many of > > > which don't have standardization efforts or a viable path to be > > > exposed (or were standardized and then dropped due to issues, e.g., > > > batteries). > > > > > > > > > > I'm inclined to think that if we want to suggest changes to address > > > > this security/privacy issue, we should be suggesting clarifying the > > > > success criteria for the working group so that these issues are > > > > clearly considered, and making it more explicitly OK for the group > > > > to decide not to produce some of its deliverables. > > > > > > > > The final paragraph of section "1. Goals" already says a bit here, > > > > as does the third paragraph of "2.1 Success Criteria", but perhaps > > > > there's more to say, perhaps by making not producing a spec > > > > explicitly OK in both "2.1 Success Criteria" and "3. Deliverables"? > > > > And perhaps something in there should also explicitly mention the > > > > difficulty of properly informing the user in order to obtain > > > > informed consent for the real risks underlying the sensors, or > > > > something like that? > > > > > > > > Or do you instead think that some of the deliverables should be > > > > removed from the charter because they're not likely to succeed? If > > > > so, which? > > > > > > I hadn't looked in detail yet, but they're doing quite a lot of APIs. > Of > > > those > > > > > > Generic Sensor API > > > Geolocation Sensor > > > > > > might be the least controversial as its a new API for an existing > > > feature, but I have not looked in detail whether this is a straight > > > mapping or not. If Google's Layered APIs initiative > > > (https://github.com/drufball/layered-apis) is successful that might > > > also be a better way to go about things. > > > > > > Wake Lock API > > > > > > We've explored this for FxOS. In terms of mozilla/standards-positions > > > I guess this would be non-harmful. > > > > > > Battery Status API > > > > > > We've unshipped this: harmful. > > > > > > Network Information API > > > > > > I'm pretty sure Mozillians have raised issues with this in the past > > > and we don't intend to ship it. I suspect harmful. > > > > > > DeviceOrientation Event specification > > > > > > We ship this on Android I think, but per earlier dev-platform threads > > > we're not exactly happy with it. > > > > > > Proximity Sensor > > > Ambient Light Sensor > > > Accelerometer > > > Gyroscope > > > Magnetometer > > > Orientation Sensor > > > > > > These are the ones my initial comment was for. As I understand it the > > > proposed defense is to restrict these to foreground top-level browsing > > > contexts without user prompt. It's unclear to what extent they are > > > throttled. If they are throttled, they are less or not useful for > > > AR/VR. If they are not throttled, they are an interesting > > > fingerprinting vector. It's unclear to me how a standardization group > > > is going to help resolve that and I don't think we'd want them to make > > > that trade-off for us. > > > > > > There's also Vibration API and HTML Media Capture and I'm not sure > > > what the state of those is. Neither seems particularly problematic. > > > > > > Hope that helps, > > > > > > > > > -- > > > https://annevankesteren.nl/ > > > _______________________________________________ > > > dev-platform mailing list > > > dev-platform@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-platform > > > > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914) > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
