I would tend to think that GPS location is more sensitive then device orientation, and so exposing device orientation if they’ve given location perms seems like a good avenue to explore, yes.
I was more concerned about the idea (or, at least what I though might be suggested) that you only get orientation if they give location permission. This seems overkill: even if I know what the data means, I can see uses of orientation that I’d be comfortable with but that I wouldn’t be comfortable giving my geolocation. that’s all I was talking about. > On Jan 3, 2018, at 10:48 AM, Jonathan Kingston <j...@mozilla.com> wrote: > > 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 > <mailto: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 > > <mailto: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 > > <mailto: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 > >> <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 > >> <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 > >> > >> <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 > >> <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# > >> > >> <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 > >> <https://www.usenix.org/legacy/event/hotsec11/tech/final_files/Cai.pdf> > >> > >> [2] https://dl.acm.org/citation.cfm?id=2714650 > >> <https://dl.acm.org/citation.cfm?id=2714650> > >> _______________________________________________ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org> > >> https://lists.mozilla.org/listinfo/dev-platform > >> <https://lists.mozilla.org/listinfo/dev-platform> > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org> > > https://lists.mozilla.org/listinfo/dev-platform > > <https://lists.mozilla.org/listinfo/dev-platform> > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
