Intent to Implement and Ship: Feature Policies for the Device Orientation API

[Mikhail Pozdnyakov]

Contact emails

mikhail.p...@intel.com, alexander...@intel.com

Spec

https://github.com/WICG/feature-policy/pull/102

Summary

By default the deviceorientation, deviceorientationabsolute and devicemotion events will be restricted to top-level document and same-origin frames.

The default behavior can be modified with explicit enabling/disabling of the dedicated sensor policy-controlled features. The sensor policy-controlled features are shared between the Device Orientation events and the corresponding Generic Sensor motion sensor classes which expose same sensor data. Please see https://github.com/WICG/feature-policy/pull/102 for details.

Event name	Required sensor policy-controlled features
deviceorientation	“accelerometer”, “gyroscope”
deviceorientationabsolute	“accelerometer”, “gyroscope”, “magnetometer”
devicemotion	“accelerometer”, “gyroscope”

Motivation

There are several motivations behind this intent

1. Address security and privacy concerns of exposing sensor data to cross-origin subframes (pls see https://bugs.chromium.org/p/chromium/issues/detail?id=598674 )

2. Improve interoperability with Firefox and Safari by providing the same default behavior

3. Consistent behavior with the feature policies introduced in the Generic Sensor API (https://w3c.github.io/sensors/#feature-policy-api).

For example, if the ‘accelerometer’ feature is disabled in a frame, then it should not be possible to get the accelerometer data in the frame by any means including devicemotion events.

4. Both Generic Sensor API and DeviceOrientation Event API use the same mojo component on browser side, so the implementation of sensor feature policies there affects both the APIs.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Shipped (DeviceMotion/Orientation events are restricted to top-level document and same-origin frames which is compatible with the intended default behavior)

Safari: Shipped (DeviceMotion/Orientation events are restricted to top-level document and same-origin frames which is compatible with the intended default behavior)

Web developers: No signals

Ergonomics

The Device Orientation API shape remains the same. However, web developers would need to explicitly enable the corresponding sensor policy-controlled features in order to use the API from a cross-origin subframe..

Activation

Web developers who use DeviceMotion/Orientation events from a cross-origin subframe will require the corresponding sensor policy-controlled features to be enabled.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Tests are to be added together with the intent implementation.

The WP tests for Generic Sensor feature policies are upstreamed https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/LayoutTests/external/wpt/generic-sensor/generic-sensor-feature-policy-test.sub.js

Link to entry on the feature dashboard TBD

Requesting approval to ship?

Yes

BR,

Mikhail

[Ojan Vafai]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/270bfa24-3250-4fca-94af-c38063fe908c%40chromium.org.

[Jochen Eisinger]

lgtm2

[Mike West]

LGTM3.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b4f2a971-ca8c-47c9-899b-b0cedddc3ab1%40chromium.org.

[Anne van Kesteren]

On Tue, Dec 19, 2017 at 6:17 PM, Mikhail Pozdnyakov
<mikhail.p...@intel.com> wrote:
> Risks
>
> Interoperability and Compatibility

>
> Firefox: Shipped (DeviceMotion/Orientation events are restricted to top-level document and same-origin frames which is compatible with the intended default behavior)

While true, at Mozilla we're not particularly happy with these sensor
APIs. We're considering finding ways to unship them or at least make
them much less risky. (We're going ahead with unshipping ambient light
and proximity, but these have slightly higher usage unfortunately.)


--
https://annevankesteren.nl/

[Kostiainen, Anssi]

My preferred longer term plan would also be to deprecate the legacy DeviceMotion/Orientation events.

 

That said, this change actually paves the way to that future by requiring web developers to use Feature Policy for cross-origin sensor access for the legacy events. The exactly same Feature Policy tokens and infrastructure are used by the next generation Generic Sensor-based APIs currently implemented in Chrome and available as an Origin Trial. This smooths out the migration path for web developers.

Thanks,

-Anssi  

[Anne van Kesteren]

On Wed, Dec 20, 2017 at 7:17 PM, Kostiainen, Anssi
<anssi.ko...@intel.com> wrote:
> My preferred longer term plan would also be to deprecate the legacy
> DeviceMotion/Orientation events.
>
> That said, this change actually paves the way to that future by requiring
> web developers to use Feature Policy for cross-origin sensor access for the
> legacy events. The exactly same Feature Policy tokens and infrastructure are
> used by the next generation Generic Sensor-based APIs currently implemented
> in Chrome and available as an Origin Trial. This smooths out the migration
> path for web developers.

Does it? As I understand it cross-origin sensor access is currently
not possible (except through postMessage()). This would enable it. So
it seems this would allow more than is currently possible when it
comes to cross-origin documents.


--
https://annevankesteren.nl/

[Kostiainen, Anssi]

Chrome, Edge (and IE11) allow cross-origin access to DeviceMotion/Orientation events, while Firefox and Safari do not, see:

https://github.com/w3c/deviceorientation/issues/46

In order to align Chrome with Firefox and Safari we need a mechanism for safely enabling cross-origin access to sensors. We have data that shows this particular use case has demand and should be addressed properly, thus Feature Policy.

Thanks,

-Anssi  

[Raymes Khoury]

I would add that if the Mozilla's concern here is that this change implies that Firefox will have to support the old sensor APIs inside iframes, I don't think that is true. Chrome and FF already diverge here. At this point I think it's preferable not to expose the old sensor APIs in iframes, but unfortunately in Chrome we already do.

An alternative to the approach proposed here would just be to deprecate these old APIs in iframes in Chrome. +Reilly Grant +ju...@chromium.org I'm not sure if that's feasible based on usage but the fact that there is no support in FF or Safari may help.

On Thu, 21 Dec 2017 at 10:30 Raymes Khoury <ray...@chromium.org> wrote:

> As it currently stands the Chrome Origin trial doesn't address the concerns with our existing events. Perhaps there has been more advanced work on quantization to mitigate the risks?

I'm not sure if this is the right thread to have that discussion. There may be privacy concerns with the existing or new APIs but the change proposed here does not add to them. In fact it does the opposite by disabling these APIs in embedded contexts unless the embedding page explicitly allows them.

> As it currently stands the Chrome Origin trial doesn't address the concerns with our existing events. 

If you feel there are privacy concerns with existing events in Chrome, please file a bug. Here is our current plan for sensor UX for new APIs that we are exposing which you may also be interested in.

Thanks,

Raymes

On Thu, 21 Dec 2017 at 09:57 Jonathan Kingston <j...@mozilla.com> wrote:

As it currently stands the Chrome Origin trial doesn't address the concerns with our existing events. Perhaps there has been more advanced work on quantization to mitigate the risks?

My overarching concern is that these sensors are given to the web page without the users knowledge.

I'm not convinced that we would be servicing our users well by continuing this unprompted access let alone providing this to third party advertisements to detect user and environment behaviour.

[Raymes Khoury]

> As it currently stands the Chrome Origin trial doesn't address the concerns with our existing events. Perhaps there has been more advanced work on quantization to mitigate the risks?

I'm not sure if this is the right thread to have that discussion. There may be privacy concerns with the existing or new APIs but the change proposed here does not add to them. In fact it does the opposite by disabling these APIs in embedded contexts unless the embedding page explicitly allows them.

> As it currently stands the Chrome Origin trial doesn't address the concerns with our existing events. 

If you feel there are privacy concerns with existing events in Chrome, please file a bug. Here is our current plan for sensor UX for new APIs that we are exposing which you may also be interested in.

Thanks,

Raymes

On Thu, 21 Dec 2017 at 09:57 Jonathan Kingston <j...@mozilla.com> wrote:

As it currently stands the Chrome Origin trial doesn't address the concerns with our existing events. Perhaps there has been more advanced work on quantization to mitigate the risks?

My overarching concern is that these sensors are given to the web page without the users knowledge.

I'm not convinced that we would be servicing our users well by continuing this unprompted access let alone providing this to third party advertisements to detect user and environment behaviour.

[Jonathan Kingston]

> I'm not sure if this is the right thread to have that discussion.

Indeed, sorry to take you off topic there.

> Here is our current plan for sensor UX for new APIs that we are exposing which you may also be interested in.

I had seen this document before, indeed our concerns are with this and less regarding the Feature Policy mentioned here.

However I suspect if we were to implement the Generic Sensor APIs right now, we would implement the same restriction for first party only and not implement relaxing our current restrictions with a Feature Policy until these concerns are ironed out.

So despite being off topic, it's somewhat an answer to mine and Anne's stance. However we don't speak for Mozilla as a whole obviously.

> If you feel there are privacy concerns with existing events in Chrome, please file a bug.

I think we should continue this on dev-platform@mozilla, we were drafting a response for tomorrow regarding this Device Orientation issue before filing anything formal.

Thanks

[Jonathan Kingston]

As it currently stands the Chrome Origin trial doesn't address the concerns with our existing events. Perhaps there has been more advanced work on quantization to mitigate the risks?

My overarching concern is that these sensors are given to the web page without the users knowledge.

I'm not convinced that we would be servicing our users well by continuing this unprompted access let alone providing this to third party advertisements to detect user and environment behaviour.

[Raymes Khoury]

Thanks for explaining in more detail. I think taking the stance of not shipping the new generic sensors API in embedded contexts until the API has been proven out is a reasonable one. I don't think having a feature policy makes things too much worse because the embedder still has to choose for the iframe to be able to use the API, and it could equally send the data to the iframe in other ways. I understand there are nuances though and if you think Chrome should follow suit with not exposing the new API in iframes, please do include it in your feedback and we can make sure to address it before the Generic Sensors API ships.

The only way I can see the above question impacting this thread is if we're worried about alignment of Feature Policy feature names for the old/new APIs - that we might regret the names chosen here because they somehow conflict later on. However the risk seems low to me - the names seem uncontroversial, match with the underlying sensor types and match with the permission names that were decided on. And of course if we could just deprecate the old API in iframes directly, we would be able to punt on this question altogether.

Thanks,

Raymes

[Mikhail Pozdnyakov]

Missing links:
Entry on the feature dashboard: https://www.chromestatus.com/feature/5758486868656128
Tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=796894

BR,
Mikhail