>>> 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). > > Yeah this has come up in the past. The difficulty at the API level is that > these things all have different API entry points that trigger the permission > prompt, so at the time that the browser is about to prompt for permission X > it can't predict that a page may soon prompt for permission Y. We could > however build our permission prompt UI in a way that could deal with multiple > prompts in a better way than showing individual door hangers. > > But since we already have various different permission prompts, this is an > existing problem, so solving it shouldn't be a prerequisite for the > discussion in the current thread. :-)
Good points, I agree, it shouldn’t be a blocker … it just seemed like this might be one of those situations that really exacerbates it. >> 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. > Games are a common use case also AFAIK. > > What kinds of modifications to the API did you have in mind? That last statement was mostly aimed at the idea that “if the applications that require high resolution data, perhaps including games, could shift to using WebVR/WebAR APIs to get at orientation, then having filtered data, or permission prompts, would impact less of the use cases”. Beyond that, I was mostly just thinking about the things that have been suggested - permission prompts - perhaps allowing pages to request lower fidelity data, or reduced data: if I’m a game that really just wants to tilt left/right, perhaps I can just request that? Or (as suggested) reduce frequency. The location API has multiple levels of fidelity you can request. - since the APIs are often used for relative motion, perhaps we could add a random starting orientation delta, so they don’t align with the world. Not sure how feasible/useful they are, and what the programmer ergonomics would, but it certainly reduces the data being sent to the browser. And perhaps some lower precision, or “offset / filtered” versions could be returned without user permission prompts, while others could result in prompts. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
