On 09/22/2017 11:33 AM, Blair MacIntyre wrote:
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).
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. :-)
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?
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
