Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFP: Generic Sensors #35

Closed
marcoscaceres opened this issue Oct 9, 2017 · 11 comments
Closed

RFP: Generic Sensors #35

marcoscaceres opened this issue Oct 9, 2017 · 11 comments
Labels
w3c

Comments

@marcoscaceres
Copy link
Contributor

@marcoscaceres marcoscaceres commented Oct 9, 2017

Request for Mozilla Position on an Emerging Web Specification

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
Copy link
Member

@martinthomson martinthomson commented Oct 9, 2017

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
Copy link
Contributor Author

@marcoscaceres marcoscaceres commented Oct 9, 2017

Agree... will split it out.

@marcoscaceres marcoscaceres changed the title RFP: Generic Sensors and Geolocation Sensor RFP: Generic Sensors Oct 9, 2017
@marcoscaceres
Copy link
Contributor Author

@marcoscaceres marcoscaceres commented Oct 9, 2017

Ok, moved it here #36

@annevk
Copy link
Collaborator

@annevk annevk commented Oct 9, 2017

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
Copy link
Member

@martinthomson martinthomson commented Oct 9, 2017

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
Copy link

@jonathanKingston jonathanKingston commented Mar 1, 2018

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
Copy link

@foolip foolip commented Mar 29, 2018

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
Copy link
Collaborator

@annevk annevk commented Mar 29, 2018

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
Copy link

@foolip foolip commented Apr 3, 2018

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
Copy link

@jonathanKingston jonathanKingston commented Jul 20, 2018

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
Copy link
Member

@martinthomson martinthomson commented Jul 20, 2018

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.

@dbaron dbaron added the w3c label Aug 9, 2018
annevk added a commit that referenced this issue Jul 21, 2020
Closes #35.
@annevk annevk closed this in #398 Jul 23, 2020
annevk added a commit that referenced this issue Jul 23, 2020
Closes #35.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

6 participants
You can’t perform that action at this time.