The suggestion that was made in the past was to tie orientation to
geolocation. I think that this would be obvious enough to pass.
Orientation is basically a refinement of position. It clearly makes
sense for AR applications. Pure VR applications might only care about
relative orientation and so might suffer a little.
I realize that friction is always a concern, but the amount of
side-channel information that leaks through the API is hard to ignore.
I think that a prompt is wise, while we investigate ways in which we
might improve the UX.
For instance, we could attempt to interpret gross movement as a
deliberate indication of intent. Then sites could use this to
implement their own permission process ("shake your phone/head to
start").
On Fri, Dec 22, 2017 at 2:52 AM, Jonathan Kingston <j...@mozilla.com> wrote:
> Following the intent to deprecate filed on Sunday for the Ambient Light and
> Proximity sensor APIs
> <https://groups.google.com/forum/#!topic/mozilla.dev.platform/DcSi_wLG4fc>,
> we propose to discuss the future of the Device Orientation API.
>
> DeviceOrientation
> <https://w3c.github.io/deviceorientation/spec-source-orientation.html>
> (deviceorientation, deviceorientationabsolute, and devicemotion events) has
> far more usage than the other two sensor APIs and so we need to be more
> careful with it to prevent breakage.
>
> Currently this API is restricted to first party domain scripts only,
> however Chrome has filed an intent to ship to have a feature policy to
> enable this in third party scripts
> <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/RX0GN4PyCF8/6XVhJ_oTCgAJ>.
> This would mean that advertisements and others would have unrestricted
> access to the users sensor information assuming they’re included through an
> iframe with the relevant allow attribute set.
>
> Risks
>
> Some of the keylogging risks are outlined in papers [1] and [2], however
> there are also risks of the user being identified by physical or
> environmental factors like mapping the swing of the device to walking gate
> patterns and the angle and shaking of the phone to match to patterns in
> altitude and terrain type.
>
> The current API provides unprompted floating point precision of sensor data
> at 60hz to the website.
>
> Generic sensor API
>
> These APIs are being replaced by the work on the generic sensor API as
> outlined in the following TAG thread
> <https://github.com/w3ctag/design-reviews/issues/207>, though it’s
> currently unclear how to properly deal with the risks of sensors other than
> throttling. It’s unclear that throttling sufficiently addresses the risks
> and also makes them a poor choice for VR.
>
> Chrome has stated their plan for the UX of the generic sensor API
> <https://docs.google.com/document/d/1XThujZ2VJm0z0Gon1zbFkYhYo6K8nMxJjxNJ3wk9KHo/edit#>
> and it doesn’t address the unprompted access to sensors, nor do we feel
> showing a new indicator about sensor usage goes far enough to mitigate the
> risk.
>
> We feel that Firefox should prompt users in some manner when accessing
> granular sensor information. Until these concerns are mitigated it seems we
> shouldn’t open up access to these sensors via a feature policy to third
> parties.
>
> Ideas to reduce user risk from the current API:
>
> - Dialling down the precision of this event or frequency it is fired from
> 60hz to 5hz however this would limit it’s usage in Web VR.
>
> - Restrict to secure contexts; this reduces some risk in particular with
> man-in-the-middle proxies that modify traffic, but is not going to address
> the overall issue on its own
>
> - We could place these events behind a permission prompt preventing drive
> by usage; a big problem with this suggestion is that it’s unclear what to
> ask the user
>
> - Restrict access to only the active tab
>
> Kind regards,
>
> Anne van Kesteren, Jonathan Kingston, and Frederik Braun
>
> [1] https://www.usenix.org/legacy/event/hotsec11/tech/final_files/Cai.pdf
>
> [2] https://dl.acm.org/citation.cfm?id=2714650
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
