Bug 152299 – [Privileged Contexts] Enable opt-in to DeviceOrientation and DeviceMotion for HTTPS-based iframes

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebCore JavaScript

[Rich Tibbett]

With iOS 9.2 WebKit now blocks deviceorientation and devicemotion event access from cross-origin iframes.

I know we have discussed preventing access to powerful features such as DeviceOrientation and DeviceMotion events from non-https documents and sub-documents but WebKit on iOS, as of the 9.2 update, is also blocking cross-origin iframe access too. Has this additional restriction been discussed in any standards organization to date?

If this feature needs to stay then perhaps we could then allow website owners to opt-in to override that restriction and enable iframe sandboxes to access device sensors if they wish.

I would propose an opt-in mechanism via the sandbox attribute for website owners as follows:

    <iframe src="https://some-cross-origin-page" sandbox="allow-scripts allow-device-sensors"/>

I have created a quick patch for WebKit that enables 'allow-device-sensors' @ https://github.com/WebKit/webkit/compare/master...richtr:iframe-sandbox-allow-device-sensors.

Could we discuss this restriction added to iOS 9.2 and the 'allow-device-sensors' proposal in an open standards forum somewhere? Where should that be?

[Stephen Underwood]

This was something I was actively using, parent and child both being on HTTPS merely different domains.

For me this broke quite of a few of my live placements, would be great if we could sort at the very least an opt-in workaround for this pretty quickly.

[Stephen Underwood]

Linking in the issue that introduced this feature @ https://bugs.webkit.org/show_bug.cgi?id=150072

[Robert Bethke]

(In reply to comment #1)
> This was something I was actively using, parent and child both being on
> HTTPS merely different domains.
> 
> For me this broke quite of a few of my live placements, would be great if we
> could sort at the very least an opt-in workaround for this pretty quickly.

I am in the same boat on this. All my clients use iframes that are on different domains. I would like a way to opt-out as soon as possible

[bobvt]

Same here. In advertising the gyroscope function is sometimes used to add interaction to the ad unit. (After a click)

This change (#150072) breaks a part of the product we sell. Having an attribute on an iframe is a solution that we can work with.

Can this be implemented?

[bobvt]

Same here. In advertising the gyroscope function is sometimes used to add interaction to the ad unit. (After a click)

This change (#150072) breaks a part of the product we sell. Having an attribute on an iframe is a solution that we can work with.

Can this be implemented?

[Jasper P.]

Same problem here. A solution with  allow-device-sensors attribute on the iframe would be great!

[Radar WebKit Bug Importer]

<rdar://problem/25347168>

[Gregg Tavares]

Isn't enabling for ads precisely why this should NOT be enabled cross-domain?

Reading keystrokes from a nearby keyboard using the gyroscope
http://www.cc.gatech.edu/fac/traynor/papers/traynor-ccs11.pdf

Speech Recognition using the gyroscope
http://www.wired.co.uk/news/archive/2014-08/15/gyroscope-listening-hack

Looks like it's an issue of sample rate? Faster = easier to spy.

Maybe if you're not the same domain you get a lower sample rate where as same domain you get higher (for VR like apps)?

[Rick Byers]

If audio / keystroke capture are really the threat here, then limiting to cross-origin iframes isn't a mitigation.  Lots of legitimate sites have all sorts of third party code running in their main frame, and users visit all sorts of illegitimate sites (eg. Not safe for ads, but porn sites go ahead?).  I'm skeptical that the browser provides a high enough frequency for those attacks in practice (the audio paper says explicitly that Safari is not affected).

A more rational explanation for this behavior to me may be reducing battery usage.  This sort of thing would be a great discussion for https://github.com/WICG/interventions to increase the chance of interoperability around this.

[Rick Byers]

Actually, I just thought of a different attack.  Better talk to our security folks before I describe it :-)

[Stephen Underwood]

(In reply to comment #10)
> Actually, I just thought of a different attack.  Better talk to our security
> folks before I describe it :-)

Will wait for you to hear back from your security team.  Surely there is a way we can handle these vulnerabilities without blocking this feature.

[Brent Fulgham]

It's really not the prerogative of the site author to decide if device status should be shared cross-domain.

[Davide Orazio Montersino]

(In reply to comment #12)
> It's really not the prerogative of the site author to decide if device
> status should be shared cross-domain.

I think it is - Enabling specific domains to access gyroscope data doesn't seem like a security threat.

The website owner could anyways share gyroscope data cross domain (i.e. web sockets).

The proposed solution of 'allow-device-sensors' attribute would allow fine grained control from website owners.

[Stephen Underwood]

(In reply to comment #12)
> It's really not the prerogative of the site author to decide if device
> status should be shared cross-domain.

Aye this could already be done with a plethora of non-elegant means using postMessage, WebSockets as suggested earlier all the way through to embedding the event data in the URL after the hash and having the child frame listen for onhashchange.

Although it would be nicer to actually have native support if that is what the site owner is after.

[Davide Orazio Montersino]

(In reply to comment #14)
> (In reply to comment #12)
> > It's really not the prerogative of the site author to decide if device
> > status should be shared cross-domain.
> 
> Aye this could already be done with a plethora of non-elegant means using
> postMessage, WebSockets as suggested earlier all the way through to
> embedding the event data in the URL after the hash and having the child
> frame listen for onhashchange.
> 
> Although it would be nicer to actually have native support if that is what
> the site owner is after.

Any updates on the sandbox="allow-scripts allow-device-sensors" proposal?

Not implementing this solution does not add to security in any ways - enabling it or not is of course still prerogative of the site owner.

It just makes the web a more hackish place - using non-elegant ways achieve this is exactly what we and the whole industry is doing.

[Jono Brandel]

The `allow-device-sensors` has use cases far more integral than advertising purposes. I work at a company where we create, host, and distribute 360 videos, https://with.in/. All of our content runs off of a CDN https://player.with.in/

When we iframe our video player on our site ( e.g: https://with.in/watch/the-possible-speed-machine/ ) we get the CORS cross-domain error because it's a different subdomain. In this case I am the owner of both and feel that the developer has a right to decide which features may trickle down.

Because of the volume of our viewership, it is paramount that we host these massive files on a CDN. Our work around is to offer a touch version for our iOS visitors, whereas visitors on Android get deviceorientation events.

Also, for what it's worth the `allow-device-sensors` is stylistically a similar solution to `allowfullscreen` attributes on iframes.

I hope you'll consider merging Rich's patch into Webkit!

[Rich Tibbett]

Just to reiterate why this solution works.

A cross-domain page running in an iframe can not access the top-level document and therefore can not grant itself `allow-device-sensors` access.

However, a top-level document, running a script that has been added by the owner of that document can create an iframe that does provide `allow-device-sensors` in that iframe's sandbox attribute. That same script could then set `http://some-cross-origin-page` and that page will then have device sensors access.

Owners of the top-level document maintain control. Scripts injected from the top-level document are accountable for enabling `allow-device-sensors`.

This works in the same way as other iframe sandbox attributes and is useful if a top-level page owner wants to embed e.g. 360 image or video players from a 3rd-party domain.

[M.]

What is the status of this https://github.com/WebKit/webkit/compare/master...richtr:iframe-sandbox-allow-device-sensors? Is there any other alternative to use gyroscope with iframes?

[Eduardo Rodrigues]

Any news on this?
I see that after two years nothing was done. Every browser is doing it. What happened to WebKit? Stopped in time?

[Rich Tibbett]

Something similar has been proposed and implemented by browsers in W3C WICG Feature Policy specification: https://wicg.github.io/feature-policy/#iframe-allow-attribute.

Chromium now implements the following `allow` properties that are relevant to this bug:

* gyroscope
* accelerometer
* magnetometer

(see: https://developers.google.com/web/updates/2018/06/feature-policy)

If this feature is to be implemented then it should follow this specification.

Also, Safari 9.2+ completely blocks adding event listeners for `deviceorientation`, `deviceorientationabsolute` and `devicemotion`.

Adding the following code to a cross-origin iframe:

    window.addEventListener("devicemotion", () => {});

results in the following Inspector error:

    "Blocked attempt add device motion or orientation listener from child frame that wasn't the same security origin as the main page" 

This causes problems for people that are polyfilling and emitting these sensor events within cross-origin iframes (e.g. via postMessage. see: https://github.com/aframevr/aframe/issues/3422).

It would be good to see some progress on these issues. Especially, preventing even listening for device motion or orientation listeners in cross-origin iframes seems to be a very aggressive approach.

[Simon Taylor]

Another two-year gap update, but this one is more positive...

It looks like now there is a way for iframes to opt-in to allowing DeviceOrientation and DeviceMotion events in an iframe. Patches landed for webkit, but not yet in a public iOS release. See this bug for more:
https://bugs.webkit.org/show_bug.cgi?id=221399

[Sam Sneddon [:gsnedders]]

*** This bug has been marked as a duplicate of bug 221399 ***