Tim, Gecko doesn't actually restrict access to same-origin iframes, does it?  https://bugzilla.mozilla.org/show_bug.cgi?id=686401 was resolved Won't Fix with the justification that the risk was low and didn't seem to justify the cost of breaking legitimate use cases.

My understanding is that it does (from correspondence with mozilla dev). The fix ships with Firefox 46.

Bug 1197901 - Risks in the current implementation of Firefox on Android in accessing to the mobile orientation and motion sensors via JavaScript codes
(https://bugzilla.mozilla.org/show_bug.cgi?id=1197901)

is the more recent one which contains the patch and is marked as fixed.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/21a19aa03091e1b0b0be9ab87e97d86d15527b94

commit 21a19aa03091e1b0b0be9ab87e97d86d15527b94
Author: timvolodine <timvolodine@chromium.org>
Date: Thu Mar 02 21:03:52 2017

Add rappor logging for Device Orientation on security origins different from the main frame

To address privacy/security concerns regaring exposing sensor
related information on cross origin sub frames it has been
suggested to restict usage of the api to frames with same
origin as the main frame ( crbug.com/523320 , crbug.com/598674).

As a first step towards applying this restriction this patch adds
some rappor logging to assess the current usage of Device Orientation
on cross origin frames. This is to ensure we don't break pages and
to analyze existing cross-origin use cases of the API.

BUG=598674

Review-Url: https://codereview.chromium.org/2698723002
Cr-Commit-Position: refs/heads/master@{#454373}

[modify] https://crrev.com/21a19aa03091e1b0b0be9ab87e97d86d15527b94/third_party/WebKit/Source/core/frame/DeviceSingleWindowEventController.cpp
[modify] https://crrev.com/21a19aa03091e1b0b0be9ab87e97d86d15527b94/third_party/WebKit/Source/core/frame/DeviceSingleWindowEventController.h
[modify] https://crrev.com/21a19aa03091e1b0b0be9ab87e97d86d15527b94/third_party/WebKit/Source/modules/device_orientation/DeviceMotionController.cpp
[modify] https://crrev.com/21a19aa03091e1b0b0be9ab87e97d86d15527b94/third_party/WebKit/Source/modules/device_orientation/DeviceOrientationController.cpp
[modify] https://crrev.com/21a19aa03091e1b0b0be9ab87e97d86d15527b94/tools/metrics/rappor/rappor.xml

Incidentally, this keeps came up again. https://twitter.com/KrauseFx/status/905822185284972546

Instead of restricting to same origin, can we instead do what we did for vibrate, i.e. require a cross-origin frame to have had a user gesture before it can use the API? If you interact with the frame, that's effectively permission for the frame to do something. This limits the attack surface enough IMO that there's no incentive for trying to exploit this.

Should this be higher priority?

Introducing of Feature Policies for the Device Orientation API (https://bugs.chromium.org/p/chromium/issues/detail?id=796894) will fix this issue.

 Issue 523320  has been merged into this issue.

This breaks embedded 360degree image panoramas in AMP.