I’ve been thinking about this since my last message, and I wanted to step back and clarify something for myself.
First, this discussion pertains to FF on Windows, Mac, Android and Linux, I assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide on things like this. Is this correct? From a WebVR perspective, the polyfill (that uses device-orientation) defers to the built in WebVR API if it exists. We have WebVR on Windows, and will hopefully(?) have it on all these other platforms soon-ish (I am unsure of timelines for this). On top of this, device orientation really is mostly used on mobile, so Android is likely the main platform of concern here? Some Windows/Linux machines (tablets?) have orientation, I assume (although I haven’t looked at it in a few years on such a device), but most don’t. So is this discussion mostly about Android? One question might be: how long till we ship WebVR of some form on Android? Most people don’t have “VR” displays for their Android phones (e.g., Daydream, GearVR, etc), but I’m wondering if we might have part of the mitigation we’re thinking about be to have our WebVR implementation work on all devices, not just ones with “real” VR support. The next API (now called WebXR) will include support for what the community is calling “Magic Window” VR/AR, which is just AR/VR without a headmounted display. All of this is to say: if we assume that within 2018, we could conceivably have WebXR of some form available in FF on all our platforms, to handle the cases the WebVR polyfill currently handles, does this change this discussion? The main use will them be for things like panoramic images / 360 video viewers — when we aren’t talking “VR”, perhaps throttling might work, or perhaps other approaches might be suitable that aren’t appropriate for VR. > On Jan 11, 2018, at 6:30 AM, Jonathan Kingston <j...@mozilla.com> wrote: > > We have three categories of solutions suggested here: > - Throttling > - An explicit gesture to approve using the API > - A prompt > > We might be able to do some/all of those depending on the situation. Is > there anything else I have missed that has been suggested? > > I honestly would like to request we do some user studies on different > content strings for prompts and see if users understand the risks. > Prompts are a UX pattern that are convention already, inventing new ones > will take more experimenting to perfect. So if we can find the right > content where users understand some of the time, this is better than not > giving users the ability to ever understand where their data is going. > > Thanks > > On Thu, Jan 11, 2018 at 7:20 AM, Anne van Kesteren <ann...@annevk.nl> wrote: > >> On Thu, Jan 11, 2018 at 5:39 AM, Chris Van Wiemeersch <c...@mozilla.com> >> wrote: >>> Anne and Martin, can you think of changes to request for the Sensor API >>> that we would resolve or reasonably improve the existing fingerprinting >>> concerns? >> >> It sounds like Chrome's approach is throttling, which would probably >> work, but it doesn't work for WebVR, right? (At which point we're back >> at looking at a permission prompt and being unsure how to phrase the >> question.) >> >> >> -- >> https://annevankesteren.nl/ >> _______________________________________________ >> 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
