Intent to Remove: Insecure usage of DeviceOrientationEvent and DeviceMotionEvent

[Balazs Engedy]

Primary eng (and PM) emails

eng...@chromium.org

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2LXKVWYkOus%5B1-25%5D

Summary

For both DeviceOrientationEvent and DeviceMotionEvent, whenever these APIs are used in a non-secure browsing context, we have been showing deprecation warnings [1] since 2015. It is time to actually restrict these APIs to secure browsing contexts.

[1] https://chromium.googlesource.com/chromium/src/+/d2a9364e140da89b73dda49d5e786d0128199447%5E%21/

Motivation

This change brings Chromium’s implementations in line with the privacy and security recommendations in the spec [2], and is aligned with the overarching effort to deprecate powerful features on insecure origins [3].

[2] https://w3c.github.io/deviceorientation/#security-and-privacy

[3] https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins

Interoperability and Compatibility Risk

Edge: Unknown.

Firefox: An intent was sent out for removal of all sensor APIs (on secure and insecure origins), but ultimately it was decided to keep DeviceOrientation/Motion for the time being as there was significant legitimate usage including WebVR. See [4] and [5].

Safari: The sensor APIs are gated on the “Motion & Orientation Access” setting, which is disabled by default in iOS 12.2 beta 1. However, there seems to be an ongoing discussion around what would be the best permission UX going forward. See [6].

[4] https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM

[5] https://www.fxsitecompat.com/en-CA/docs/2018/various-device-sensor-apis-are-now-deprecated/

[6] https://github.com/w3c/deviceorientation/issues/57

Alternative implementation suggestion for web developers

Both APIs are still available in secure browsing contexts. Users (e.g. websites building VR/AR/XR experiences) are advised to migrate to HTTPS. In insecure contexts, the Screen Orientation API [8] can be used as an alternative way to detect and respond to orientation changes.

[8] https://w3c.github.io/screen-orientation/

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/668

https://www.chromestatus.com/metrics/feature/timeline/popularity/670

As of Feb 2019, insecure usages of DeviceOrientationEvent and DeviceMotionEvent are observed on ~0.82% and ~0.12% of page loads, respectively, and trending downwards. Out of 40 randomly selected sites that HTTP Archive indicated to have been using these features in the last 3 months, 20 sites appeared to be no longer using them and/or already migrated over to HTTPS. On 19 sites, no obvious user-visible changes were observed, and on a single site an eye-candy parallax effect stopped working.

Entry on the feature dashboard

https://www.chromestatus.com/feature/5874690627207168

https://www.chromestatus.com/feature/5556931766779904

[Mike West]

The usage numbers are pretty high, so I skimmed through a few of the HTTPArchive hits myself. I also saw usage overwhelmingly from third-party contexts, usually with domain names that looked a lot like advertising. I didn't dig into the detail of whether or not the API was being used for fingerprinting or for some more benign purpose. The visible usage I saw was along the same lines as what Balazs notes below: parallax effects use this API, but nothing else that I saw in the sites I dug through. The breakage therefore seems smaller than the overall usage numbers would indicate.

That said, I'd like to understand the plan: simply locking the event handler to secure contexts could cause pages to start throwing exceptions. Can I assume that you'll follow the advice in https://w3c.github.io/deviceorientation/#security-and-privacy by allowing registration (e.g. `window.ondeviceorientation = whatever;`) and continuing to expose interfaces, but simply refusing to fire events in non-secure contexts?

(On that note, do we aim to follow the rest of the recommendations in that section as well? I didn't see the top-level browsing context/same-origin nested context restriction, for example, while skimming through //third_party/blink/renderer/modules/device_orientation. +timvo...@chromium.org)

-mike

[Balazs Engedy]

The usage numbers are pretty high, so I skimmed through a few of the HTTPArchive hits myself. I also saw usage overwhelmingly from third-party contexts, usually with domain names that looked a lot like advertising. I didn't dig into the detail of whether or not the API was being used for fingerprinting or for some more benign purpose. The visible usage I saw was along the same lines as what Balazs notes below: parallax effects use this API, but nothing else that I saw in the sites I dug through. The breakage therefore seems smaller than the overall usage numbers would indicate.

Yes, that matches my observations. Specifically, the two main use cases I observed were the 1) parallax effect, and 2) embedded street-view style widgets, which, however, appeared to be only probing the API.

That said, I'd like to understand the plan: simply locking the event handler to secure contexts could cause pages to start throwing exceptions. Can I assume that you'll follow the advice in https://w3c.github.io/deviceorientation/#security-and-privacy by allowing registration (e.g. `window.ondeviceorientation = whatever;`) and continuing to expose interfaces, but simply refusing to fire events in non-secure contexts?

Yes, that's the plan. For now, it will still be possible to register an event handler, it will simply never be fired.

(On that note, do we aim to follow the rest of the recommendations in that section as well? I didn't see the top-level browsing context/same-origin nested context restriction, for example, while skimming through //third_party/blink/renderer/modules/device_orientation. +timvo...@chromium.org)

This is implemented by means of Feature Policy, see: http://crbug.com/796894.

[Philip Jägenstedt]

On Tue, Feb 12, 2019 at 10:40 AM Balazs Engedy <eng...@chromium.org> wrote:

The usage numbers are pretty high, so I skimmed through a few of the HTTPArchive hits myself. I also saw usage overwhelmingly from third-party contexts, usually with domain names that looked a lot like advertising. I didn't dig into the detail of whether or not the API was being used for fingerprinting or for some more benign purpose. The visible usage I saw was along the same lines as what Balazs notes below: parallax effects use this API, but nothing else that I saw in the sites I dug through. The breakage therefore seems smaller than the overall usage numbers would indicate.

Yes, that matches my observations. Specifically, the two main use cases I observed were the 1) parallax effect, and 2) embedded street-view style widgets, which, however, appeared to be only probing the API.

That said, I'd like to understand the plan: simply locking the event handler to secure contexts could cause pages to start throwing exceptions. Can I assume that you'll follow the advice in https://w3c.github.io/deviceorientation/#security-and-privacy by allowing registration (e.g. `window.ondeviceorientation = whatever;`) and continuing to expose interfaces, but simply refusing to fire events in non-secure contexts?

Yes, that's the plan. For now, it will still be possible to register an event handler, it will simply never be fired.

Yeah, for events it's pretty hard to cause exceptions by not firing the events, the worst case breakage would rather be some code that never runs and a UI stuck in an in-between state. Probably not for these events though.

However, for web developers this means it won't be possible to detect that change has happened at all. What would you think of following the example of https://w3c.github.io/sensors/#the-sensor-error-event-interface and adding [SecureContext] to all interfaces in https://w3c.github.io/deviceorientation/? We didn't do that for getUserMedia(), but with event constructors the risk is rather a lot lower -- there's usually no reason to create synthetic events, especially when UA-created events of the same type are never fired.

Balazs, if you think this would make sense, a search of HTTPArchive for "new DeviceOrientationEvent" and similar should give a good idea about the risk.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD1EjnY%3DXfAP68t_uGeSQqDLAfA_GLRuuK8pW44vW8gxCiUVvg%40mail.gmail.com.

[Joe Medley]

Balazs,

Can you please create new status entries specifically for the removals? (We need to keep the history provided by the old ones.) They'll need tracking bugs when you have them.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

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/CAARdPYd6%3Dy6kpZOZ7QaqyQ5WTccTE-TFiwgtDM9h7-Fq9D4pxA%40mail.gmail.com.

[Balazs Engedy]

@Joe, I filed a tracking bug and status entries, let me know if there is anything else to add:

https://crbug.com/932078

https://www.chromestatus.com/feature/5468407470227456
https://www.chromestatus.com/feature/5688035094036480

@Philip, that makes perfect sense to me. I analyzed the data from HTTPArchive in two ways to estimate breakage:

1. Out of 45k script response bodies that contained `DeviceOrientationEvent`, only a handful (<5) contained code snippets that would directly throw `ReferenceErrors` if the global went away. See [1].
2. Of course, scripts could just stash away `window.DeviceOrientationEvent` into a variable, and throw when they try accessing properties on it, but according to [2], > 93% of all scripts using DeviceOrientationEvent did something that looked a lot like feature detection.

The results look similar to DeviceMotionEvents. Please let me know if this analysis makes sense, or if you have further concerns.

[1]:

SELECT

   REGEXP_EXTRACT(reduced_body, "(.{0,99}[^a-zA-Z]DeviceOrientationEvent[^a-zA-Z].{0,99})") AS snippet

FROM (

  SELECT

    body,

    REGEXP_REPLACE(body, "[a-zA-Z]+\\.DeviceOrientationEvent[^.]|typeof DeviceOrientationEvent|\'DeviceOrientationEvent\'|\"DeviceOrientationEvent\"|\\|DeviceOrientationEvent\\|", "") AS reduced_body

  FROM [httparchive:response_bodies.2019_01_01_desktop]

  WHERE url LIKE '%.js'

    AND body CONTAINS "DeviceOrientationEvent"   

  GROUP BY body, reduced_body)

WHERE REGEXP_MATCH(reduced_body, "[^a-zA-Z]DeviceOrientationEvent[^a-zA-Z]")

GROUP BY snippet

 

... if(DeviceOrientationEvent) ...

... function(e,t){return new DeviceOrientationEvent(e,t)} ...

(see rest as attachment)

[2]:

SELECT

  COUNT(body), SUM(p1), SUM(p2), SUM(p3), SUM(p4), SUM(p5), SUM(p6), SUM(p7), SUM(p8), SUM(p9), SUM(p0), SUM(p1 + p2 + p3 + p4 + p5 + p6 + p7 + p8 + p9 + p0 > 0)

FROM (

SELECT

  body,

  REGEXP_MATCH(body, "![a-zA-Z]+\\.DeviceOrientationEvent") as p1,

  REGEXP_MATCH(body, "[a-zA-Z]+\\.DeviceOrientationEvent ?\\&\\&|\\&\\& ?[a-zA-Z]+\\.DeviceOrientationEvent") as p2,

  REGEXP_MATCH(body, "[a-zA-Z]+\\.DeviceOrientationEvent ?\\|\\||\\|\\| ?[a-zA-Z]+\\.DeviceOrientationEvent") as p3,

  REGEXP_MATCH(body, "== ?[a-zA-Z]+\\.DeviceOrientationEvent|[a-zA-Z]+\\.DeviceOrientationEvent ?==|[a-zA-Z]+\\.DeviceOrientationEvent ?!=") as p4,

  REGEXP_MATCH(body, "[a-zA-Z]+\\.DeviceOrientationEvent ?\\?") as p5,

  REGEXP_MATCH(body, "typeof ([a-zA-Z]+\\.)?DeviceOrientationEvent") as p6,

  REGEXP_MATCH(body, "[a-zA-Z]+\\[[\'\"]DeviceOrientationEvent[\'\"]\\]") as p7,

  REGEXP_MATCH(body, "[\'\"]DeviceOrientationEvent[\'\"] ?in ?[a-zA-Z]+") as p8,

  REGEXP_MATCH(body, "if ?\\( ?[a-zA-Z]+\\.DeviceOrientationEvent ?\\)") as p9,

  REGEXP_MATCH(body, "\\|DeviceOrientationEvent\\||DataView DeviceOrientationEvent Document") as p0, // False positives.

FROM [httparchive:response_bodies.2019_01_01_desktop]

WHERE url LIKE '%.js'

  AND body CONTAINS "DeviceOrientationEvent"

  AND REGEXP_MATCH(body, "DeviceOrientationEvent[^:]")

GROUP BY body, p1, p2, p3, p4, p5, p6, p7, p8, p9, p0)

Row f0_ f1_ f2_ f3_ f4_ f5_ f6_ f7_ f8_ f9_ f10_ f11_  

1 10468 2078 1556 348 1007 205 291 20 1625 500 3114 9982

[Joe Medley]

Thanks!

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Yoav Weiss]

On Tue, Feb 12, 2019 at 9:18 AM Mike West <mk...@chromium.org> wrote:

The usage numbers are pretty high, so I skimmed through a few of the HTTPArchive hits myself. I also saw usage overwhelmingly from third-party contexts, usually with domain names that looked a lot like advertising.

Is it possible to add usecounters that split the main context from third party context usage?

I'd be more comfortable with breaking 3rd parties where we suspect the main use-case is fingerprinting, but it would be useful to understand how much of the usage is first-party contexts, which are more likely to have a legitimate use for the APIs.

 

--
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/CAKXHy%3Ddv_SSYqgQTq7SmvB3LqPyssXh1Tq13KC4NGX7ZU4VfMQ%40mail.gmail.com.

[Philip Jägenstedt]

On Thu, Feb 14, 2019 at 10:24 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Feb 12, 2019 at 9:18 AM Mike West <mk...@chromium.org> wrote:

The usage numbers are pretty high, so I skimmed through a few of the HTTPArchive hits myself. I also saw usage overwhelmingly from third-party contexts, usually with domain names that looked a lot like advertising.

Is it possible to add usecounters that split the main context from third party context usage?

I'd be more comfortable with breaking 3rd parties where we suspect the main use-case is fingerprinting, but it would be useful to understand how much of the usage is first-party contexts, which are more likely to have a legitimate use for the APIs.

+Luna Lu may know of more recent developments, but last I checked we need to add separate use counters manually to make distinctions like this. NotificationAPIInsecureOriginIframe vs NotificationAPISecureOriginIframe is an example of this.

[Philip Jägenstedt]

Thanks for the excellent analysis, Balazs!

There is one thing in there that's cause for concern, and that is `if(DeviceOrientationEvent)`. This feature detection is broken as it will throw an exception if the DeviceOrientationEvent interface isn't exposed. One has to do `if (window.DeviceOrientationEvent)` or `if (typeof DeviceOrientationEvent !== "undefined")`.

Do you have numbers for how common that form for one of the two interfaces was?

One thing which could save the situation is that wpt.fyi shows that Safari (desktio) doesn't expose the interfaces. However, pointing Safari on iOS at http://w3c-test.org/orientation-event/idlharness.window.html (non-secure context) shows that it does expose the interface. So, mobile content could still well depend on the interfaces being exposed.

This is quite an unfortunate situation. I think some further compat analysis of `if(DeviceOrientationEvent)` and similar is what it'd take to move forward.

https://github.com/w3c/deviceorientation/pull/65 is the spec issue, and whatever conclusion we arrive at would be good to have reflected there as well.

[Balazs Engedy]

There is one thing in there that's cause for concern, and that is `if(DeviceOrientationEvent)`. This feature detection is broken as it will throw an exception if the DeviceOrientationEvent interface isn't exposed. One has to do `if (window.DeviceOrientationEvent)` or `if (typeof DeviceOrientationEvent !== "undefined")`.

Do you have numbers for how common that form for one of the two interfaces was?

I did some more analysis. In summary, I observed three code patterns [5, 6, 8] that would suddenly throw if we no longer exposed the DeviceOrientationEvent interface:

• In conditionals: `if(DeviceOrientationEvent)`. This is used in literally a single script that is referenced on a total of 4 sites, three of which are served over HTTPS, and the 4th having an Alexa rank of 1,944,803.
• Constructor calls: `new DeviceOrientationEvent`, which is used in a single script used by a single site with an Alexa rank of 71716.
• As function arguments: `foo(DeviceOrientationEvent)`. It turns out there is a single script with this pattern, which is used on 3349 sites (mostly secure), however, it does seem to do feature probing correctly:
  `function(){return"function"==typeof DeviceOrientationEvent&&a239.a341.a66(DeviceOrientationEvent)}`

I looked for similar patterns involving `DeviceMotionEvent`, with virtually the same results [11, 13], i.e. virtually negligible breakage.

I also looked at code patterns that would suddenly start throwing exceptions if `window.ondeviceorientation`and `window.ondevicemotion`went away in non-secure contexts, but haven't found any [9, 10], and after discussing with Mike again, we could not come up with any theoretically either.

One thing which could save the situation is that wpt.fyi shows that Safari (desktio) doesn't expose the interfaces. However, pointing Safari on iOS at http://w3c-test.org/orientation-event/idlharness.window.html (non-secure context) shows that it does expose the interface. So, mobile content could still well depend on the interfaces being exposed.

I re-ran my queries against the mobile crawl data [3, 4, 11, 12]. The feature probing rate was similarly in the 90-95% range, and I did not observe any more unsafe code patterns.

 

https://github.com/w3c/deviceorientation/pull/65 is the spec issue, and whatever conclusion we arrive at would be good to have reflected there as well.

Based on the results above, restricting all interfaces and EventHandler attributes in the spec to [SecureContext] does not seem to be running the risk of fatally breaking sites as a result of exceptions being thrown unexpectedly.

So at this point the question is: How do we decide if we are comfortable with removing the capability in non-secure contexts (without breaking anything else, as demonstrated above); and whether we want to create carve-outs for mobile / first parties?

[Mike West]

LGTM1. I'm comfortable with the analysis you've done so far, Balazs, and I'm confident that the user-visible impact of limiting gyroscope access to secure-contexts will be minimal.

-mike

[Philip Jägenstedt]

LGTM2, huge thanks Balazs for the careful analysis. In the past when we've gone through usage this carefully and not found anything that would break more than a few scripts, removals have been successful. I trust that will be the case now as well, but as always we should revert and reconsider if we get bugs filed about regressions.

[Rick Byers]

LGTM3. 

Having Chrome roughly match the behavior of other browsers without the feature (eg. desktop Safari) in insecure contexts seems like it should be extremely safe. Thanks for the thorough analysis Balazs!

The one potential area for concern which hasn't been discussed yet is WebView (/cc Changwan). I took a look at the internal WebView-specific UseCounters and DeviceOrientationInsecureOrigin is at about 0.37% of PageVisits - which seems pretty high (DeviceMotion was much lower 0.05%). But that doesn't really tell us anything about the risk of exceptions due to APIs disappearing in code written to only ever run in Android WebView. Perhaps we should consider leaving this enabled in WebView, or relying on a target SDK quirk? But I think that decision can be made offline with the WebView team independent of this blink intent.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcwnEHmZ%3DLVqs828yzSi7moWtdZDZ6bD-qpyzKZb1A_DA%40mail.gmail.com.

[Balazs Engedy]

Thank you all for the super helpful feedback!

This change is now implemented in Blink ([1], [2]) and is expected to ship in M74. The IDL in the spec [3] has also been updated to reflect its own recommendations in the Security and Privacy considerations section. Will carefully monitor any potential breakage and developer feedback.

[1]: https://chromium-review.googlesource.com/c/chromium/src/+/1473992

[2]: https://chromium-review.googlesource.com/c/chromium/src/+/1486091

[3]: https://w3c.github.io/deviceorientation/#idl-index

[jacobst...@gmail.com]

I'm not sure how recently this change actually went live, but it has affected a service that I provide to businesses and I'm searching for information and hopefully a workaround. 

I create virtual tours of tiny homes using krpano and allow builders/designers to embed them directly on their websites, as an interactive marketing tool. A special feature of this is the ability to load VR on mobile devices (for the likes of Google Cardboard). I just completed a tour for a client who reported that they do not have the option to load VR. Both my source site and his site are secure HTTPS but the tour on his page is loading through an iframe, which I'm assuming is being treated as not-secure (only on mobile, because on desktop the VR button still shows). 

At the time of writing this, here is the actual location of the tour -> https://www.tinynestproject.com/explore/tiny-healthy-homes/hugge_skp/ 

And here is where it is embedded on my client's site -> https://www.bengarratt.com/workshops 

Any suggestions to make this work on mobile? Is there a property that I can add to the embed or another method of embedding altogether? Why would this be treated as not-secure when there is no insecure content involved?

[Reilly Grant]

This change shouldn't have affected your site however in Chrome 66 feature policy controls were activated for this feature. Documented here: https://github.com/w3c/webappsec-feature-policy/blob/master/features.md#sensor-features

If you are embedding content that listens for these events without the appropriate feature policy configured then there should be a console warning in DevTools. You should be able to enable usage of these policy-controlled features in an iframe by adding allow="gyroscope accelerometer magnetometer" to the <iframe> tag.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Ian Clelland]

On Wed, May 1, 2019 at 12:56 PM Reilly Grant <rei...@chromium.org> wrote:

This change shouldn't have affected your site however in Chrome 66 feature policy controls were activated for this feature. Documented here: https://github.com/w3c/webappsec-feature-policy/blob/master/features.md#sensor-features

If you are embedding content that listens for these events without the appropriate feature policy configured then there should be a console warning in DevTools. You should be able to enable usage of these policy-controlled features in an iframe by adding allow="gyroscope accelerometer magnetometer" to the <iframe> tag.

Yep, that sounds right -- though the WebVR and WebXR APIs are *also* restricted in cross-origin frames the same way, so you might need to use allow="gyroscope; accelerometer; magnetometer; vr" to get it all working. (And note that you'll need semicolons between the different feature names, otherwise the second and subsequent names will be treated as a list of origins, rather than features)

Ian

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMb2AffhjeXTYkO-wkr_MmvFQ4-E3uAbAD591eBFQaX2BA%40mail.gmail.com.

[jacobst...@gmail.com]

Thank you so much :) 

It felt like a shot in the dark to post here, but your suggested additions to my iframe tag worked and it is a great relief not to have to rethink how to deploy these embeds. 

Thanks again for taking the time to reply, and hopefully others might come across this and benefit as well.

[kmdan...@gmail.com]

Hi. I'm running into the same issue. Where, exactly, did you add this?

[Reilly Grant]

On Wed, May 15, 2019 at 9:25 AM <kmdan...@gmail.com> wrote:

Hi. I'm running into the same issue. Where, exactly, did you add this?

The "allow" attribute must be added to the <iframe> tag. As Ian pointed out my original example was wrong, the individual policy names must be separated by semicolons so the tag would look like,

<iframe src="..." allow="gyroscope; accelerometer; magnetometer">