(I’m CC:ing a few of the MR team folks, although I’m sure many of them are on the dev-platform list already).
Speaking for myself (not the official stance of the WebVR team), I share these concerns and like the trajectory you suggest. I would HOPE that in the long run (some number of years?) all browsers with support the WebVR APIs and new uses of this API for VR will stop needing this API. But that will take some time, and (unfortunately) ignores that there are many sites that currently use this to do “3 degree of freedom” (orientation only) AR views. Eliminating the API breaks all of these sites and experiences. This includes non-VR uses like looking at panoramic photos or images. Of the 4 suggestions at the bottom, the first seems problematic (as you say, doesn’t really eliminated the problem, and breaks the WebVR usage). But, the other three seems reasonable. Adding a permission prompt would increase friction, perhaps, and it’s not clear what to ask (“This website wants to use the motion of your device”?). I’ll let others chime in. > On Dec 21, 2017, at 10: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
