Device motion and orientation API may expose sensitive information. Most of the web platform APIs that expose powerful features, are only accessible from secure context. It might be a good idea to restrict this API only to secure contexts.

I quickly checked implementation and run some tests, all browsers (safari, mozilla, edge, ie, chrome) expose device motion and orientation to both, secure and non-secure contexts.

As per [SECURE-CONTEXTS], sensor access considered to be powerful web platform feature, therefore, should exposed only to secure contexts.

The DeviceMotionEventInit dictionary has members of interface type, DeviceAcceleration and DeviceRotationRate. Those interfaces have no interface objects, and no constructors, and thus can't be constructed by user scripts. Thus, populating the dictionary is difficult.

Should the dictionary perhaps reference sub-dictionaries (e.g. DeviceAccelerationInit / DeviceRotationRateInit) instead?

Since all origins displayed to a device will share the same pattern of device orientation changes, this API may provide an avenue for cross-origin correlation. If that threat can't be mitigated, it should at least be noted (and user agents may want to disable access or provide users a means to disable access to these data)

Hi, I was wondering if you guys had developed a method to set the target of these controls. I am working on a project where we want to walk users thru different views and we'd like to override the current orientation of the device with the target (direction) of the view so that they see specific objects in the scene.

Thanks! and amazing work!

WebIDL dropped [Callback] extended attributes in its 07 February 2012 – LCWD #3, see:

http://www.w3.org/TR/WebIDL/#changes

DeviceAcceleration and DeviceRotationRate should align.

Currently they needlessly are interfaces.

• WebKit uses dictionaries for acceleration/rotationRate: https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/DeviceMotionEvent.idl?rev=267813
• Gecko uses no-interface-object interfaces: https://searchfox.org/mozilla-central/rev/353f334d13359f7cb879b3cb38a94294231c2aa8/dom/webidl/DeviceMotionEvent.webidl

Blink currently is the only implementation that exposes the interfaces.

Due to the privacy issues related to this API (e.g. https://www.wired.com/story/mobile-websites-can-tap-into-your-phones-sensors-without-asking/ and https://arxiv.org/pdf/1605.08763.pdf), we are considering adding to WebKit a permission dialog in order to ask the user if they want to expose their device orientation/motion to the Website.

However, because trackers already register such event listeners on top sites, we are worried about the risk of over-prompting. We wouldn't want this prompt to start showing on a lot of top-sites.

To address the issue, we'd like to propose adding a new API allowing the page's script explicitly ask for permission to access the device / motion. We think we should also require a user-gesture to call this new API.

It could look something like this (similar to Notification API):

[Exposed=(Window)]
interface DeviceOrientation {
  [Exposed=Window] static Promise<boolean> requestPermission();
};

What are your thoughts?

We need to decide if we want to incorporate Apple's webkitCompassHeading and webkitCompassAccuracy in to the specification. iOS-based implementations of Device Orientation Events provide an arbitary, non-absolute 'alpha' reading which does not lend itself well to Augmented Reality use cases.

The background reason for this decision can be read @ http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0014.html

More information on both properties is currently documented @ https://developer.apple.com/library/safari/documentation/SafariDOMAdditions/Reference/DeviceOrientationEventClassRef/DeviceOrientationEvent/DeviceOrientationEvent.html#//apple_ref/javascript/instp/DeviceOrientationEvent/webkitCompassHeading

On #68 I commented that the new requestPermission() method should be defined in terms of the same permissions tokens as those used by the Generic Sensors family of specifications.

Alignment between these specifications will ease the transition for developers.

Some implementations of DeviceOrientationEvent don't work well for Virtual Reality (VR) head tracking. The main problem is drift: even when your head is stationary, your field of view will slowly rotate in some random direction. The cause of this problem is that in these implementations, DeviceOrientationEvents are absolute and fire based on the magnetometer, which is adversely affected by ever-present nearby metallic objects.

The plan to fix this in Chrome for Android is to switch the existing deviceorientation event to use Android's Sensor.TYPE_GAME_ROTATION_VECTOR and produce {absolute: false} events by default. This has the added benefit of bringing parity to the Chrome and Safari implementations. However, this is problematic for Augmented Reality and compass applications, which then have no way of getting absolute heading.

To address this, we want to add a new absolutedeviceorientation event which provides the same data format as the current 'deviceorientation' event, but will use Sensor.TYPE_ROTATION_VECTOR and provide {absolute: true} events by default. The other approach is to standardize webkitCompassHeading, or the Web Sensor API but these requires substantial standardization and implementation time and effort.

Do folks in this group have any objections to this approach?

https://w3c.github.io/deviceorientation/#devicemotionevent

There's no prose for what the constructor does, but questions that can't be answered from looking at the Web IDL definition.

Specifically, can acceleration, accelerationIncludingGravity and rotationRate ever be null? Because DeviceMotionEventInit takes init dictionaries for these members, I would guess that they can't, but prose could say something about this.

While crawling DeviceOrientation Event Specification, the following links to other specifications were detected as pointing to non-existing anchors:

• https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

The IDL says:

dictionary DeviceMotionEventInit : EventInit {
  DeviceAccelerationInit? acceleration;
  DeviceAccelerationInit? accelerationIncludingGravity;
  DeviceRotationRateInit? rotationRate;
  double interval = 0;
};

but the IDL spec says:

If the Type is an identifier followed by ?, then the identifier must identify an interface, enumeration, callback function or typedef.

and

If the type of the dictionary member, after resolving typedefs, is a nullable type, its inner type must not be a dictionary type.

when discussing dictionary members in https://heycam.github.io/webidl/#idl-dictionaries. So the above IDL is not valid, and a conformant IDL parser will reject it.

This was discussed during TPAC 2023. WebDriver support in the Generic Sensor API spec was fully rewritten a few months ago, and the tests in WPT are not implementation-specific anymore.

It would be good to do the same with this spec, as several existing web tests in WPT rely on Chromium Mojo JS mocks and are therefore not easily interoperable.

One idea would be to make this specification reference the automation bits in the Generic Sensor API one (in other words, implementations are not expected to implement the Generic Sensor API itself, only the WebDriver extension commands defined in https://w3c.github.io/sensors/#automation). This would make it possible to set e.g. DeviceMotionEvent data by calling test_driver.create_virtual_sensor("accelerometer") (and others) and test_driver.update_virtual_sensor("accelerometer", {x: 1, y: 2, z: 3}).

If this is a worthwhile approach, then the two opens I see at the moment are

1. What kind of virtual sensor type to use for the deviceorientation and deviceorientationabsolute events. We can clearly use "accelerometer", "linear-acceleration" and "gyroscope" for DeviceMotionEvent, but there's no clear mapping to one or more sensor types for DeviceOrientationEvent. One could require "accelerometer" and "gyroscope" for relative orientation, for example, but implementations are arguably free to obtain the Euler angles data from the platform in another manner altogether, so I'm tempted to just go with making this specification define additional virtual sensor types, "relative-orientation-data" and "absolute-orientation-data" that takes Euler angles directly.
2. At the risk of contradicting some of the statements above, using 3 separate sensors ("accelerometer", "linear-acceleration" and "gyroscope") for DeviceMotionEvent may be racy since a new event may fire while one of the sensors is still being updated. In this case, we may need to define a new virtual sensor type that takes all 3 readings at once, and leave it to the implementation to update all readings at once on the platform side.

The title says it all.

Security & Privacy section must be made normative to avoid interoperability issues related to cross-origin API access, exposure of powerful features only to secure context, etc.

Currently, browsers implement cross-origin access to the API differently:

Cross-origin access is blocked in:

• Webkit
• Mozilla

Cross-origin access is allowed in:

• Chromium (Issue 598674)
• Edge
• IE (IE11)

Proposal:

• Make Security & Privacy normative
• Block access to cross-origin iframes
• As the Device Motion & Orientation exposes sensitive data, restrict access only to secure contexts #47
• Reuse applicable mitigation strategies from Generic Sensor API https://w3c.github.io/sensors/#security-and-privacy

@reillyeon and I were discussing the Chromium implementation of #68 and we figured it'd be good to get some clarification on how it integrates with Device{Orientation,Motion}Event -- either in terms of what the spec's supposed to mean or, if it's intentionally leaving some decisions up to implementations, what WebKit/Safari do so we can try to align some of the behavior across implementations.

• Does WebKit/Safari remember if permission's been granted to a given page or are users always asked for permission when requestPermission() is called?
• If an event listener for a deviceorientation/motion event is added before permission is granted, does anything happen (e.g. a null deviceorientation/motion event is fired)?
• Are users at all supposed to be able to add an event listener for those events before requesting permission?
• Once permission is granted, do previously registered event listeners start working or does the user need to add another event listener in order to start receiving events?

cc @cdumez

While crawling DeviceOrientation Event Specification, the following links to other specifications were detected as pointing to non-existing anchors, which should be fixed:

• https://html.spec.whatwg.org/multipage/interaction.html#triggered-by-user-activation

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

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

In example 9, the phone is described as being vertical, so accelerationIncludingGravity would register gravity affecting the y-axis, not the z-axis. This means the value should be { x: v^2/r, y: 9.8, z:0 }

Hello All,
Re: https://w3c.github.io/deviceorientation/spec-source-orientation.html#compassneedscalibration

W3C staff has not been able to find any conforming implementation beyond IE. At very least, it does not seem to make sense that support for this event be mandatory for implementations (which is what the current spec text requires).

This feature could remain in the spec, but it looks like it can only be optional given the lack of supporting implementations. Since implementers monitor this repo, would like to hear feedback.

-Giri Mandyam, W3C Geolocation Working Group Chair

According to the authors of this paper, the standard includes functionality that allows users to be fingerprinted with high fidelity. (quote: “the DeviceMotionEvent APIs, particularly DeviceMotionEvent.acceleration and DeviceMotionEvent.rotationRate”) don’t require permissions to access. The standard needs to be updated so that users cannot be passively fingerpritined.

Migrated from w3c/sensors#398

For example, see Pointer Events

Hi!
i have met a question when using DeviceMotion event, it only returns a value of null when init the app.

In the devicemotion specification:
https://w3c.github.io/deviceorientation/spec-source-orientation.html#devicemotion
The rotationRate: "It must be expressed as the rate of change of the angles defined in section 4.1"
So it means the rotation axes should be the following:
z axis: alpha
x axis: beta
y axis: gamma

However, Chrome on Android, Firefox browser on Android, and Safari browser on iPhone, they all implement rotationRate as the following:
x axis: alpha
y axis: beta
z axis: gamma

Given that this feature has been implemented in this way for a while and all the above browsers implement it in the same way which is different from the specification, updating the specification seems a better and easy solution. What do you think? Thanks!

The chromium related issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=541607

I also created a pull request:
#43

Jun

I'm a bit confused, the Editor's Draft is dated 26 February 2016 and the Candidate Recommendation is dated 18 August 2016, but there seems to be commits in between, does this mean that the Editor's Draft is unmaintained ?

DeviceMotionEvent.initDeviceMotionEvent() and DeviceOrientationEvent.initDeviceOrientationEvent() appear to be supported in all browsers implementing this spec, but are not in the spec.

I have added use counters in Blink for these, which may shed some light on their necessity:
https://www.chromestatus.com/metrics/feature/timeline/popularity/865
https://www.chromestatus.com/metrics/feature/timeline/popularity/866

Needed for whatwg/webidl#365.

There was instances where the deviceorientation refresh rate was so high that it could be used a microphone. https://bugzilla.mozilla.org/show_bug.cgi?id=1292751 (related paper linked to there).

The spec should suggest or say why sampling frequency should be capped at something reasonable (25-60hz).

The API should provide some way to get request the current orientation without needing to subscribe to events.

Without them, where is one to get instances of these interfaces for the DeviceMotionEvent constructor?

@xfq, can you take a look at these errors?

Specberus Errors:
  Wrong syntax for Latest Version link.
    {
      name: 'headers.dl',
      section: 'front-matter',
      rule: 'docIDLatestVersion'
    }
  Missing `data-editor-id` attribute for editor(s): Devices and Sensors Working Group
       .
    { name: 'headers.dl', section: 'front-matter', rule: 'editorSection' }

Details: https://labs.w3.org/echidna/api/status?id=6f885bbf-3aaa-4d8c-b23b-88414e12c7de

Each of the 3 event types defined in this specification have an excerpt that looks like this:

If an implementation can never provide motion information, the event should be fired with the acceleration, accelerationIncludingGravity and rotationRate attributes set to null.

This does not look entirely clear to me:

• Should implementations fire a single event with nullable attributes set to null, or does the text intend to give implementations some leeway so that they can continue trying (and consequently fire any number of "empty" events)?
• Doesn't it make more sense to just not fire an event at all?

The interval attribute is defined in IDL as nullable however the specification also says, "[t]he interval attribute must return the value it was initialized to. When the object is created, this attribute must be initialized to 0."

These appear to be contradictory because I believe it is impossible to differentiate between an intent to initialize the attribute to null and no initialization at all.

Should not the value of z of example7 be the opposite?

Example 7 says

A device lying flat on a horizontal surface with the screen upmost has an acceleration of zero and the following value for accelerationIncludingGravity:

{x: 0,
y: 0,
z: 9.8};

While everywhere, the specification consistently states the orientation of the z axis is down to up.

Up (Z) is perpendicular to the ground plane and positive upwards.

Even example 8 says:

A device in free-fall, with the screen horizontal and upmost, has an accelerationIncludingGravity of zero and the following value for acceleration:
{x: 0,
y: 0,
z: -9.8};

The spec should include information about how deviceorientation and devicemotion events are expected to behave relative to the current orientation of a device's screen.

Some background reading on this topic is available here:
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0296.html
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23072
https://groups.google.com/d/msg/mozilla.dev.webapi/SCK80a0Oqws/X2PrzXDMk6UJ
http://lists.w3.org/Archives/Public/public-geolocation/2014Jan/0010.html (bottom of response email reply)

Requests in the above discussions seem to indicate that the spec should be changed from mandating that 'the device coordinate frame is defined relative to the screen in its standard orientation' to 'the device coordinate frame is defined relative to the current up orientation of the screen' (where we should define 'up orientation' also in the spec).

It makes sense to define this according to the window.orientation API for now (with screen rotations available as 0, 90, 180, -90 degrees from the standard screen orientation position as it rotates counter-clockwise) until the Screen Orientation API [1] is updated to include window.orientation-like behavior (proposed at [2]).

Having deviceorientation/devicemotion events report data relative to the current 'up' frame of the screen will mean web developers will not have to manually 're-wire' deviceorientation/devicemotion data according to the current screen 'up' frame in order for their creations to work as expected.

An alternative approach is for the DeviceOrientation Events spec to provide developers with the necessary way to 're-wire' deviceorientation and devicemotion events via their own JavaScript as the screen orientation changes (e.g. [3]). This would be sub-optimal because it assumes all web developers will incorporate this 're-wire' code in their deviceorientation/motion based web apps.

Any further ideas here? Is there broad agreement from developers and implementers that deviceorientation should be provided relative to a screen's current 'up' frame?

[1] https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24698
[3] http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/att-0296/Remapping_Table.PNG

The spec defines an enum with the name PermissionState - this conflicts with the name used in the Permission API.

For context, see #34.

In issue #18 @foolip determined that the DeviceMotionEvent.initDeviceMotionEvent() and DeviceOrientationEvent.initDeviceOrientationEvent() methods which are implemented by Chrome, Edge, Firefox and Mobile Safari have extremely low usage and so should not be added to this specification. However, given the fact that these methods are supported by a large number of implementations consensus that removal is the right choice should be reached.

So far the only public signals on this topic come from MSDN where it is documented that "as of Microsoft Edge, the createEvent()/initEvent() constructor pattern for synthetic events is deprecated." There is no specific mention of these methods.

See whatwg/webidl#778.

Dear Sirs/Madams,

Our team at Ben Gurion University has discovered an attack which takes advantage of a mobile device's gyroscope (either directly or through the Javascript DeviceOrientation API) to exfiltrate data. The attack requires that the adversary place a simple hardware device (basically a high-frequency speaker) next to the device under attack.
In contrast to the "Gyrophone" attack from 2014 [1], reducing the sampling rate of the gyroscope does not prevent our attack.
To mitigate this attack, we think it's a good idea to limit access to the orientation API. One way to achieve this is to ask the user's permission before enabling this API. Another way is to limit access to web pages delivered from insecure origins, as Chrome does for the Location API [2].

I'd be glad to attach a draft of our technical report to this issue, if there's some way to (temporarily) restrict access to it. Of course I'll be glad to mail the report to anybody on the standards team.

Sincerely,
Yossi Oren.

[1] Yan Michalevsky, Dan Boneh and Gabi Nakibly
Gyrophone: Recognizing Speech from Gyroscope Signals
https://crypto.stanford.edu/gyrophone/
[2] Chromium Security Team, "Deprecating Powerful Features on Insecure Origins",
https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins

Cross-references:

Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1276177
Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=615348
Safari: 641640531
IE: 33653

http://w3c.github.io/deviceorientation/spec-source-orientation.html is an ugly URL

https://w3c.github.io/deviceorientation/ would be a pretty URL, and would require fixing some mixed content issues, perhaps simply be using scheme-relative URLs.

The current ondeviceorientation text has the following excerpt:

If an implementation can never provide orientation information, the event should be fired with the alpha, beta and gamma attributes set to null.

It does not say anything about the absolute attribute. This is an event without any data so its value is not relevant, but I wonder if it should be specified normatively nonetheless.

Carefully consider with what name to expose these interfaces and then please drop this. We're going to remove it from IDL per whatwg/webidl#430 and whatwg/webidl#609.

See http://lists.w3.org/Archives/Public/public-geolocation/2015Nov/0003.html.

As suggested by @xfq in #52 we should probably convert the spec source to Bikeshed/ReSpec to make it easier to publish.

As of now, this spec inherited from Geolocation WG has 29 errors (and 5 warnings) in the Pubrules checker: https://www.w3.org/pubrules/?url=https%3A%2F%2Fw3c.github.io%2Fdeviceorientation%2F&profile=WD-Echidna&validation=simple-validation&noRecTrack=false&informativeOnly=false&echidnaReady=true&patentPolicy=pp2004

there is a security/privacy consideration around this API being used by a third party to detect key presses. Please see:

https://bugzilla.mozilla.org/show_bug.cgi?id=686401

The spec should make a mention of this.

ondeviceorientation, oncompassneedscalibration and ondevicemotion are mentioned, but not spec'd in the way that most specs do.

Example: https://fullscreen.spec.whatwg.org/#api

#55 made the init dictionary members non-nullable, and thus the acceleration/rotationRate attributes cannot be null.

It's also what Gecko implements:

> new DeviceMotionEvent("type").acceleration

DeviceAcceleration { x: null, y: null, z: null }

About w3c/gyroscope , what is difference ? Other than the fact that deviceorientation is purely event-driven and gyrospcope requires instantiation.