>> What's the reason for this? I don't know for sure, but it may be necessary >> for things like AR/VR to have higher resolution than that. > The reason is to limit the frequency of sensor data the web application > receives to allow it to guesstimate the changes to the device position to > limit how accurately it can guess how the device is being used. It was just > an idea I copied from the spec for discussion, not sure if it is effective or > not really. > > We discussed this a bit with Anne on IRC. It seems like this API is a good > use case for a permission prompt to the user. Since the API works by > registering an event listener, the only realistic option seems to be > Permission.request() before registering the event listeners. Unfortunately > it seems that a while ago we have pushed back on this API > <https://github.com/w3c/permissions/issues/83>, but it seems that this use > case wasn't considered back then. Anne said he'll look into opening up that > discussion again to see if we can use a permission prompt for this API…
I’d love to see a discussion about this — I’ve been thinking about the question of “informed consent” by users to this “less obviously problematic” data (to a typical person: it seems more obvious why geolocation might be more of a problem than device orientation) in the context of augmented reality on the web. We’re also thinking about other data that might exposed eventually by AR sensors. But in theory, for the AR/VR use cases, I’m not against asking user permission: for me, one of the strengths of doing AR/VR on the web is that fact that the UA can give user’s control over what data each site/experience has access to. I’d actually love to go further, and allow user’s to see what’s being used and toggle it on/off while the experience is running (we experimented with location access in the Argon4 AR web browser this summer, letting the user toggle location access on/off easily without reloading the page). One question I would have is how to deal with permission fatigue. If an AR/VR app generates 3 or 4 separate permission requests (location, deviceorientation, camera, and perhaps other sensors eventually), is it possible to think about how to aggregate these into one or more groups that might also explain to users why all of these are needed? (“AR applications need access to camera, location and orientation”) (I’m not sure if this has been talked about in the past). (For those who are interested: a group of us over in Emerging Technology have been working on expanding WebVR to include AR/MR use cases, we’re documenting this “WebXR" proposal in github.com/mozilla/webxr-api, and building a sample implementation in github.com/mozilla/webxr-polyfill. We’ve also got a sample iOS app, for demonstrating/using it on iOS, that leverages ARKit, in github.com/mozilla/webxr-ios). I mention this because, at some point in the future, there will hopefully be VR and AR/MR apis (perhaps via this webxr proposal, perhaps via a different one) in most browsers, and that that point, the uses for this API may diminish. They are still used by various polyfills (e.g., the WebVR polyfill uses deviceorientation), since WebVR isn’t in all browsers yet, and will be used by WebXR and other similar efforts for some time as well. But I wonder, at some point, what apps will still need this? If AR/VR don’t, and apps like “viewing 360 video or panoramic images” can use the AR/VR apis to access the data … there might bit a lot more we can do with this API at that point, to reduce it’s impact. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
