RFP: Generic Sensors

[marcoscaceres]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Generic Sensor API - and friends...
• Specification or proposal URL: https://www.w3.org/TR/generic-sensor/

Other information

This has also spawned other sensors that inherit the generic interface - which refactor sensors we already have exposed (and in many cases had to remove) in the browser.

[martinthomson]

It's probably a good idea to split the geolocation thing out if you want a position. That is potentially a very different story given that we have a perfectly serviceable, if clunky, API for that.

[marcoscaceres]

Agree... will split it out.

[marcoscaceres]

Ok, moved it here #36

[annevk]

I don't think we can have a position on this without knowing about the (UX) security story for each individual API. That is, what Martin suggests for geolocation is true for all of them.

[martinthomson]

That actually suggests to me a negative consequence of truly generic features (c.f., permissions). Managing how to expose something like permissions for a generic feature like this seems difficult. UX being somewhat central to this particular API, but only one aspect of the larger problem with features that provide generic capabilities.

Perhaps the best way to manage this is to consider the merits of each sensor as a feature in isolation, but then separately consider the advantages posed by having a unified interface to those. That suggests questions on whether we want to expose the gyroscope, ambient light sensor, air pressure sensor, etc... Then we can - for the set of those things that we care about - come back here and make an assessment about the unified API.

[jonathanKingston]

Perhaps the best way to manage this is to consider the merits of each sensor as a feature in isolation

Agreed, I think we could assess the sensor doc in it's generic sense and from a privacy/security stand point it's probably fine.

Just an update here we are in the process of unshipping ambient light and proximity sensors and deprecating orientation and motion all of which have better counter parts in generic sensors. However as @annevk points out there isn't a decent story for adding privacy to any of these sensors yet.

[foolip]

I came here from the Intent to Ship: Generic Sensors-based Motion Sensors on blink-dev.

On the issue of different privacy/security policies for different types of sensors or between UAs, it looks to me like the solution for this is the SensorErrorEvent interface and there's a good example for Accelerometer covering the exception thrown in the constructor and error events fired later. Does that address the concerns in this thread?

[annevk]

The way I understand it the answer to w3ctag/design-reviews#207 (comment) (can you ask the user about this?) is to not ask the user and just lower the resolution. However, at least Mozilla's XR folks have said that low resolution is not adequate at which point it doesn't really seem worth exposing these.

[foolip]

For the sensors that correspond to https://w3c.github.io/deviceorientation/spec-source-orientation.html which are enabled already by default, the answer indeed to not ask the user, and to use the same resolution as for the existing APIs. Just to be sure I tried http://googlesamples.github.io/web-fundamentals/fundamentals/native-hardware/device-orientation/dev-orientation.html on Firefox Nightly for Android and it works.

If at some point in the future one or more vendors wanted to gate access to those sensors on asking the user, then it looks to me like the Generic Sensors API is well equipped to allow that, but the risks of trying to ship that are similar to trying to limit the deviceorientation and devicemotion events, namely that web developers just assume they work and the result will be a non-functional page.

[jonathanKingston]

To clarify I don't think we should block on implementing these APIs so long as that we gate the experience with some form of user consent (probably the default doorhanger) or implement them behind a pref. I personally think the Mozilla stance should be that any API with access to physical data MUST require some level of user understanding and consent.

If Mozilla implements without this gated experience, we likely end in a place where we have to add it in afterwards. I would much rather us ship bad UI than roll out without user controls like WebVR and have to implement it later causing web-compat issues.

That was largely the resolution to this at the all hands right @martinthomson?

[martinthomson]

There is bad UI and there is bad UI. I think that the principle should be that we don't ship features for which we believe that require consent unless we have a very clear story about how that consent is obtained. That means that we need great UX if the feature depends on UX.

The other part was that generic was generally not considered as a valuable property when it comes to deciding whether a feature is worth shipping. Each capability needs to be assessed on its own merits.

That's a slightly different emphasis, but not fundamentally different.

[rniwa]

FWIW, Apple's WebKit team doesn't support generic sensors API either for similar reasons as Mozilla's.