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
