When the language for the permission prompt isn't going to be clear about
what the user is exposing (screen, camera and mic) we should be talking
about risks.
For GPS we only ever talk about "location", I still don't think that is a
far stretch from head/position tracking.
On Wed, Jan 3, 2018 at 2:47 PM, Blair MacIntyre <bmacint...@mozilla.com>
wrote:
> 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/1XThujZ2VJm0z0Gon1zbFkYhYo6K8n
> MxJjxNJ3wk9KHo/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
