This is the repository in which the W3C's Device Orientation and Motion specification is jointly maintained by the Devices and Sensors Working Group and the Web Applications Working Group.
Please see CONTRIBUTING.md
W3C Device Orientation spec
Home Page: https://www.w3.org/TR/orientation-event/
License: Other
This is the repository in which the W3C's Device Orientation and Motion specification is jointly maintained by the Devices and Sensors Working Group and the Web Applications Working Group.
Please see CONTRIBUTING.md
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:
Cross-origin access is allowed in:
Proposal:
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
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.
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 API should provide some way to get request the current orientation without needing to subscribe to events.
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.
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.
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.
Hi!
i have met a question when using DeviceMotion event, it only returns a value of null when init the app.
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
Currently they needlessly are interfaces.
acceleration
/rotationRate
: https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/DeviceMotionEvent.idl?rev=267813Blink currently is the only implementation that exposes the interfaces.
The title says it all.
#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 }
@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
For example, see Pointer Events
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.
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 ?
See whatwg/webidl#778.
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.
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.
Without them, where is one to get instances of these interfaces for the DeviceMotionEvent
constructor?
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};
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?
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
For context, see #34.
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
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?
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!
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
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
While crawling DeviceOrientation Event Specification, the following links to other specifications were detected as pointing to non-existing anchors:
This issue was detected and reported semi-automatically by Strudy based on data collected in webref.
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.
Needed for whatwg/webidl#365.
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?
The spec defines an enum with the name PermissionState
- this conflicts with the name used in the Permission API.
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
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:
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
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.
This has already been implemented in Chrome (issue 796894) based on the Feature Policy specification however this should be mentioned directly in this specification.
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).
ondeviceorientation, oncompassneedscalibration and ondevicemotion are mentioned, but not spec'd in the way that most specs do.
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.
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)
About w3c/gyroscope , what is difference ? Other than the fact that deviceorientation is purely event-driven and gyrospcope requires instantiation.
@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.
requestPermission()
is called?cc @cdumez
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
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 }
While crawling DeviceOrientation Event Specification, the following links to other specifications were detected as pointing to non-existing anchors, which should be fixed:
This issue was detected and reported semi-automatically by Strudy based on data collected in webref.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.