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

Open
marcoscaceres opened this Issue Oct 9, 2017 · 11 comments

Comments

Projects
None yet
6 participants
@marcoscaceres
Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Oct 9, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Oct 9, 2017

Collaborator

Agree... will split it out.

Collaborator

marcoscaceres commented Oct 9, 2017

Agree... will split it out.

@marcoscaceres marcoscaceres changed the title from RFP: Generic Sensors and Geolocation Sensor to RFP: Generic Sensors Oct 9, 2017

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Oct 9, 2017

Collaborator

Ok, moved it here #36

Collaborator

marcoscaceres commented Oct 9, 2017

Ok, moved it here #36

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Oct 9, 2017

Collaborator

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Oct 9, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Mar 1, 2018

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip 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?

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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Mar 29, 2018

Collaborator

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@foolip

foolip 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.

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

This comment has been minimized.

Show comment
Hide comment
@jonathanKingston

jonathanKingston Jul 20, 2018

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Jul 20, 2018

Member

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.

Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment