DeviceOrientation Event Specification

[anssiko]

こんにちは TAG-さん!

I'm requesting a TAG review of DeviceOrientation Event Specification.

This specification defines several DOM events that provide information about the physical orientation and motion of a hosting device.

• Explainer¹ (minimally containing user needs and example code): This feature has a good MDN entry with example code, see also Motion Sensors Explainer for an introduction to low-level and high-level motion sensors, key concepts
• Specification URL: https://www.w3.org/TR/orientation-event/
• Tests: https://wpt.fyi/results/orientation-event (expected updates)
• User research: [url to public summary/results of research]
• Security and Privacy self-review²: [self-review]
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/deviceorientation/
• Primary contacts (and their relationship to the specification):
  • Reilly Grant (@reillyeon), Google, editor, co-chair
  • Raphael Kubo da Costa (@rakuco), Intel, editor
  • Anssi Kostiainen (@anssiko), Intel, co-chair
• Organization(s)/project(s) driving the specification: Google, Intel
• Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification:
  • This specification is implemented by the major browser engines, see MDN browser compatibility and caniuse.com.
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: A new CR Snapshot expected in March 2024.
• The group where the work on this specification is currently being done: Devices and Sensors WG
  • This specification is expect to become a joint deliverable with the WebApps WG to be jointly published by the two groups before it advances to Rec.
• Major unresolved issues with or opposition to this specification: None
• This work is being funded by: Google, Intel

You should also know that...

This spec initially reached CR in August 2016 (history) and was retired in 2017 due to the Geolocation WG closure. In 2019 DAS WG adopted this spec and during 2019-2024 made substantial interoperability, test automation, privacy and editorial improvements as outlined in the changes section.

These changes since the previous CR Snapshot from 2016 align the specification with widely available implementations, improve interoperability including testability, and add new features for enhanced privacy protections.

This is a high-level API whose low-level API correspondence Orientation Sensor was reviewed by TAG in #207 The functional diff is explained in high-level vs. low-level and Orientation Sensor.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[anssiko]

We've indicated to horizontal groups we'd like to get feedback by 2024-02-29. Making good progress, overall HR status tracked in w3c/deviceorientation#130

We provided an executive summary in the "You should also know that..." part. We hope context this helps. TL;DR: this update aligns the specification with widely available implementations. WebApps WG is now on board, so we're able to publish this jointly with all implementers represented. Thanks for your support.

[torgo]

Hi @anssiko - thanks for sending this our way and thanks for the additional metadata.

We're largely happy from an architectural point of view and I appreciate this is an update to an existing spec and that there is multi-implementer consensus - so great!

In line with generally tightening up our privacy-related guidance, we have just updated our wording in the Design Principles about exposing identifying information about devices and I'd like to draw your attention to it: In our new guidance in 9.1, we say "A web app should not be able to distinguish between the user rejecting permission to use a sensor/capability, and the sensor/capability not being present." From our read on the current spec, it's not clear what the behaviour is if a user rejects permission. Can you clarify?

[anssiko]

@torgo thanks for your review and updates to the Design Principles. I'm happy to hear the additional metadata about the spec's history and high-level status was considered useful.

Regarding your guidance and question:

"A web app should not be able to distinguish between the user rejecting permission to use a sensor/capability, and the sensor/capability not being present."

My understanding is the spec complies with your newly added guidance, because https://www.w3.org/TR/permissions/#dfn-denied is defined as: "The user, or the user agent on the user's behalf, has denied access to this powerful feature".

@reillyeon and @rakuco to correct me.

With this, we acknowledge the receipt of your feedback and will consider your review completed. Thank you!

(FTR: related design discussion w3c/deviceorientation#74 resulted in changes w3c/deviceorientation#123 to match WebKit's behavior.)

[reillyeon]

The specification currently seems to violate the updated TAG guidance because when no permission is granted no event is fired while when the sensors are unable to provide readings (either entirely or for a particular feature e.g. the gyroscope) an event with those readings set to null is fired.

[anssiko]

(FTR: TAG guidance "exposing identifying information about devices" is now noted in an issue w3c/deviceorientation#148)

[torgo]

Hi @anssiko & @reillyeon - First of all, thanks for raising the issue in your repo in response to our feedback. We're happy to close the review on that basis.

...and... It's clear we need some harmonisation between the TAG guidance on devices and powerful features and what the WebAppSec group has developed around this topic. Thanks for bringing that to our attention. We've opened up an issue on our design principles doc w3ctag/design-principles#481 to track.