I don’t think tying orientation to GPS is really a viable approach.
The main use case for the orientation API, I think, is not AR; it’s 360 images
and videos, and “cardboard VR”, right now.
> On Jan 1, 2018, at 5:01 PM, Martin Thomson <m...@mozilla.com> wrote:
>
> 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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
