w3c / deviceorientation

W3C Device Orientation spec
https://www.w3.org/TR/orientation-event/
Other
49 stars 32 forks source link

Add integration with Permissions Policy #64

Closed reillyeon closed 9 months ago

reillyeon commented 5 years ago

This has already been implemented in Chrome (issue 796894) based on the Feature Policy specification however this should be mentioned directly in this specification.

anssiko commented 5 years ago

Given both Safari and Firefox seem to restricted these events to top-level document and same-origin frames they'd comply with the default Feature Policy behavior of default allowlist set to ["self"]. Correct?

If that's the case, this seems like an obvious addition to the spec. I suspect it was not added to the spec in tandem with the Chrome implementation work due to the unfortunate fact this spec was unmaintained at that time.

reillyeon commented 5 years ago

Discussed at TPAC 2019 F2F. Resolved to implement this issue.

https://www.w3.org/2019/09/19-dap-minutes.html#x16

xfq commented 4 years ago

Note that Feature Policy has been renamed: https://github.com/w3c/webappsec-permissions-policy/pull/379

rakuco commented 1 year ago

For the record: both Blink and WebKit already integrate this API with the Permissions Policy spec, but Gecko does not.

When it comes to permissions policy tokens:

rakuco commented 10 months ago

The additional "magnetometer" requirement for ondeviceorientation on WebKit seems to come from the non-standard version of the Device Orientation API shipped on iOS and its compass-related attributes:

    [ImplementedAs=compassHeading] readonly attribute unrestricted double? webkitCompassHeading;
    [ImplementedAs=compassAccuracy] readonly attribute unrestricted double? webkitCompassAccuracy;
    undefined initDeviceOrientationEvent(optional [AtomString] DOMString type = "",
                                    optional boolean bubbles = false,
                                    optional boolean cancelable = false,
                                    optional unrestricted double? alpha = null,
                                    optional unrestricted double? beta = null,
                                    optional unrestricted double? gamma = null,
                                    optional unrestricted double? compassHeading = null,
                                    optional unrestricted double? compassAccuracy = null);

(see also: Apple's DeviceOrientationEvent documentation)

The non-iOS version of the Web IDL excerpt above allows creating a synthetic DeviceOrientation event with absolute=true:

    readonly attribute boolean? absolute;
    undefined initDeviceOrientationEvent(optional [AtomString] DOMString type = "",
                                    optional boolean bubbles = false,
                                    optional boolean cancelable = false,
                                    optional unrestricted double? alpha = null,
                                    optional unrestricted double? beta = null,
                                    optional unrestricted double? gamma = null,
                                    optional boolean? absolute = null);

but the ondeviceorientationabsolute event itself (which would require magnetometer access) is not supported.

My proposal is to standardize Blink's behavior (i.e. require "accelerometer"+"gyroscope" for ondevicemotion and ondeviceorientation, and "accelerometer"+"gyroscope"+"magnetometer" for ondeviceorientationabsolute) instead.

rakuco commented 10 months ago

My proposal is to standardize Blink's behavior (i.e. require "accelerometer"+"gyroscope" for ondevicemotion and ondeviceorientation, and "accelerometer"+"gyroscope"+"magnetometer" for ondeviceorientationabsolute) instead.

The current text in the spec does give some leeway to implementations to use a magnetometer for ondeviceorientation:

The deviceorientation event tries to provide relative values for the three angles (relative to some arbitrary orientation), based on just the accelerometer and the gyroscope. The implementation can still decide to provide absolute orientation if relative is not available or the resulting data is more accurate. In either case, the absolute property must be set accordingly to reflect the choice.

The Gecko implementation seems to do this on e.g. Android:

In order for the spec to be airtight, we'd need to either require "magnetometer" or stop allowing implementations to fall back to absolute orientation.

reillyeon commented 10 months ago

Could the we specify that implementations may only fall back to absolute orientation if the document has "magnetometer" permission?

rakuco commented 10 months ago

I think that could work, even though it doesn't match the behavior of any of the implementations :smile:

I'll work on a draft patch.

reillyeon commented 10 months ago

I believe that is how Chromium works: https://source.chromium.org/chromium/chromium/src/+/main:content/browser/generic_sensor/frame_sensor_provider_proxy.cc;l=24;drc=73975654a11ff311bdd908f2a699096ba5dd07e2

rakuco commented 10 months ago

Ah, good point, I was only looking at the Blink-side checks but forgot that there are content-side checks as well.