Intent to Ship: GravitySensor API

[Mandy, Arnaud]

Contact emails

arnaud...@intel.com, raphael.ku...@intel.com, rei...@chromium.org

Explainer

https://github.com/arskama/GravitySensor/blob/main/explainer.md

Specification

https://w3c.github.io/accelerometer/#gravitysensor-interface

API spec

Yes

Summary

Expose the GravitySensor API, which provides a 3-axis reading of the gravity force, to users.

Blink component

Blink>Sensor

Search tags

sensors, gravity, fugu

TAG review

https://github.com/w3ctag/design-reviews/issues/207

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Generic Sensor APIs, as well as other hardware-related APIs, can be controversial when it comes to interoperability because other browser engine developers have voiced privacy-related concerns. We believe the Chromium implementation addresses those concerns. Additionally, all the data exposed by this API can already be read by users in JavaScript by calculating gravity from the Accelerometer and LinearAccelerometer readings we already provide.

Gecko: Negative Mozilla has not been asked about this specific API, but have raised concerns about the Generic Sensor APIs, including Accelerometer.

WebKit: Negative (https://webkit.org/tracking-prevention/) Although Apple has not been specifically asked about this API, they are not part of the Devices & Sensors WG, and have generally been contrary to the Generic Sensor APIs.

Web developers: Positive (https://crbug.com/1163993)

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

Yes

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1163993

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5384099747332096

This intent message was generated by Chrome Platform Status.

[Alex Russell]

I'm recused from this intent, but via Mike West, I was glad to see that permissions API integration has been added to the design and that resolution clamping has already been discussed and adopted:

https://chromium-review.googlesource.com/c/chromium/src/+/2684575

Looking forward to seeing this ship.

On Monday, March 15, 2021 at 3:58:46 AM UTC-7 arnaud...@intel.com wrote:

Contact emails

arnaud...@intel.com, raphael.kubo....@intel.com, reill...@chromium.org

[Mike West]

LGTM1.

This seems like a reasonable thing for the platform to offer, with fairly clear evidence of developer interest, analogous APIs on other platforms `CMDeviceMotion`'s gravity acceleration vector on iOS and the gravity sensor type on Android), and security/privacy protections equivalent to the existing accelerometer sensor that we've already decided to ship. Since the information this sensor exposes is derived from the same sensor fusion that powers `LinearAccelerationSensor`, the privacy delta should be negligible.

I was initially concerned that the TAG review was quite old, but it appears that the `GravitySensor` interface was present in the accelerometer specification at the time of the review.

That said, one note about signals below:

On Thu, Mar 18, 2021 at 8:29 PM Alex Russell <sligh...@chromium.org> wrote:

I'm recused from this intent, but via Mike West, I was glad to see that permissions API integration has been added to the design and that resolution clamping has already been discussed and adopted:

https://chromium-review.googlesource.com/c/chromium/src/+/2684575

Looking forward to seeing this ship.

On Monday, March 15, 2021 at 3:58:46 AM UTC-7 arnaud...@intel.com wrote:

Contact emails

arnaud...@intel.com, raphael.ku...@intel.com, rei...@chromium.org

Explainer

https://github.com/arskama/GravitySensor/blob/main/explainer.md

Specification

https://w3c.github.io/accelerometer/#gravitysensor-interface

API spec

Yes

Summary

Expose the GravitySensor API, which provides a 3-axis reading of the gravity force, to users.

Blink component

Blink>Sensor

Search tags

sensors, gravity, fugu

TAG review

https://github.com/w3ctag/design-reviews/issues/207

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Generic Sensor APIs, as well as other hardware-related APIs, can be controversial when it comes to interoperability because other browser engine developers have voiced privacy-related concerns. We believe the Chromium implementation addresses those concerns. Additionally, all the data exposed by this API can already be read by users in JavaScript by calculating gravity from the Accelerometer and LinearAccelerometer readings we already provide.

Gecko: Negative Mozilla has not been asked about this specific API, but have raised concerns about the Generic Sensor APIs, including Accelerometer.

WebKit: Negative (https://webkit.org/tracking-prevention/) Although Apple has not been specifically asked about this API, they are not part of the Devices & Sensors WG, and have generally been contrary to the Generic Sensor APIs.

I'd appreciate you asking about this specific feature. It seems clear that the shape of the API is objectionable to Mozilla and Apple (per comments in https://github.com/mozilla/standards-positions/issues/35), but it seems equally clear that objecting to the generic sensor framework is not the same as objecting to individual capabilities that framework might expose (https://github.com/mozilla/standards-positions/issues/35#issuecomment-335089405 makes this distinction clear).

Since Chromium has decided to ship the generic sensor API, and this new API is simply an ergonomic/performance improvement, I don't think we need to block on feedback from other vendors. At the same time, I think it's important for us to at least try to agree on a set of use cases and functionality that supports them. Given the interest in AR/VR across the board, I'm hopeful that there's room for more high-level agreement than initially suggested here.

Thanks!

-mike

Web developers: Positive (https://crbug.com/1163993)

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

Yes

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1163993

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5384099747332096

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8df880de-6f34-4e3e-9547-5f0d6f536cb3n%40chromium.org.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcYySK-rWHjPAv90Dih6usCvB1w2sRKYrc4_rBD1%2BLkeQ%40mail.gmail.com.

[Daniel Bratell]

First off, I'm not happy that this whole sensor subsection of the browser is shunned by Mozilla and Apple, and that common ground has been so hard to find. Still, given that Chromium already ships similar sensors, this is a reasonable addition that doesn't change the overall picture negatively.

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-q72%3Dxf1JR1ibZ2qFxqtV4ZxeJoqoY1X9KnsdivWwAng%40mail.gmail.com.