#928: DeviceOrientation Event Specification

Visit on Github.

Opened Feb 5, 2024

こんにちは 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:
  • 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 https://github.com/w3ctag/design-reviews/issues/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

Discussions

2024-02-05

Minutes

Matthew: this is interesting... started in 2011... in 2016 it had a CR but then retired... and now has come back in 2019... since 2022 has had loads of work... Seems pretty well fleshed out. APA had some accessibility consideraitons... these can be worked out...

2024-03-11

Minutes

Dan: we had a message from anssi .. they gave us a deadline that we've missed. the update aligns the spec with implementations. Sounds good in terms of multi implementer support.

Matthew: apa provided comments relating to a11y. On the cusp of proposing an accessibility considerations section for them, hopefully today. No major concerns - just alternatives to things that developers should provide. Didn't see anything risky from an architectural perspective. They have S&P which we should pay attention to. They are doing testing to get feedback on s&p issues.

Dan: I've reviewed their responses to the self-review - no red flags. Should we be evaluating this against our new guidence on access to devices?

Matthew: app should not be able to distinguish between denying permission and... I don't remember seeing anything along those lines but worth checking

Dan: this is an iteration on an existing thing

Matthew: we didn't land the PR

Dan: we got positive reviews and addressed the requested change

Matthew: if we're talking about permssions stuff in this principle I agree with sangwhan's review... wouldn't have expected permissions in it from the title of the issue. If we land this it's worth raising an issue for this so we think about it again, but not hold it up on this.

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

</blockquote>

Matthew: filed w3ctag/design-principles#479 for us to keep track of Sangwhan's review of w3ctag/design-principles#470.

2024-03-18

Minutes

Dan: Anssi got back to us... DAS WG believes the spec is compliant with the Permissions guidance, however in response to our concern they opened an issue https://github.com/w3c/deviceorientation/issues/148

Matthew: there's a typo in the permissions spec in /TR ... also I'm wondering if the permissions spec Anssi linked to ... I'm wondering if our advice is compatible?

Matthew: I don't think we can say no to them since this is in agreement with Anssi's approach.. We're saying we don't want to block devices & sensors wg work...

<blockquote>

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 https://github.com/w3ctag/design-principles/issues/481 to track.

</blockquote>

Matthew: APA WG suggested an Accessibility Considerations section (also, it's been great working with this group, as ever).

closed as satisfied