<html>
<head>
<base href="https://bugs.webkit.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [Privileged Contexts] Enable opt-in to DeviceOrientation and DeviceMotion for HTTPS-based iframes"
href="https://bugs.webkit.org/show_bug.cgi?id=152299#c17">Comment # 17</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [Privileged Contexts] Enable opt-in to DeviceOrientation and DeviceMotion for HTTPS-based iframes"
href="https://bugs.webkit.org/show_bug.cgi?id=152299">bug 152299</a>
from <span class="vcard"><a class="email" href="mailto:rich.tibbett@gmail.com" title="Rich Tibbett <rich.tibbett@gmail.com>"> <span class="fn">Rich Tibbett</span></a>
</span></b>
<pre>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 `<a href="http://some-cross-origin-page">http://some-cross-origin-page</a>` 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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>