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
