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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
