> > Specifically: I was wondering about the real impact of the webvr polyfill > > not working, on Firefox users. My mention of the work implementing WebVR > > was pointing out that we will hopefully not need to worry about the > > webvr-polyfil working on Gecko-based browsers in the not-to-distant future, > > whenever we have full platform coverage for a real WebVR/WebXR > > implementation. > > My ideal here is that we have an explicit user action / gesture or prompt > for: Magic window, WebVR/XR and device orientation. We might choose to make > several prompts rolled into one for VR but ultimately it will still require > the user to understand the risks. I'm not really sure there is an obvious way > of protecting the user from magic window being just as dangerous as device > orientation.
I think that breakdown of categories is a good set. Right now, WebVR/XR (HMD’s) has been using one approach. "Magic window”-like apps have not been implement in WebVR, but rather using device orientation (akin to the polyfill), so anything that looks like that (right now) is just as dangerous, as you say. My hope is that the “Magic window” style of AR/VR is supported directly by the WebXR api. There will be some pushback at increased friction (right now, experiences like that start working immediately because of device orientation) but I think on the whole, the community group understands the need for some sort of user action / gesture. > > if we’re including iOS in the list of platforms we may want to try and > > remove device orientation from > > I don't think we need to remove it just provide UI in the short term to > require the user to approve. Great. I would agree with that approach. > > when WebXR (including “Magic Window” support) will ship in all versions of > > Firefox > > I'm unsure here too, I'm not after restricting these websites from working at > least in the short term. I think the functionality should still exist if we > can come up with the right controls to these APIs. > > I suspect we are mostly talking about fennec but I'm also not sure if any > laptops/tablets use these APIs if the sensors exist. If the APIs are in use > again I think the prompts should be clear to the user about the risks they > have. > > One thing that we could try is taking the user though an on-boarding tutorial > when they first see a website that uses this API. The tutorial could explain > to them what the API will be called, how they will be prompted and what the > risks are to them. I think we (folks in the MR team) would be interested to explore that with you; I personally would be, partially because I suspect we may need such an “education” approach with future sensors and capabilities. If we look down the road at the kind of sensor data advanced AR displays collect (using sensors to build models of the world around the user, for example), we will eventually want to explore how to expose that data into the web (as part of WebXR, or some other API). Explaining what this means to users will be hard, much like device orientation. Thanks for your patience with all of this! > > On Thu, Jan 11, 2018 at 6:15 PM, Blair MacIntyre <bmacint...@mozilla.com > <mailto:bmacint...@mozilla.com>> wrote: > Oh, I see what you are saying. I think there is some confusion here > (perhaps on my part only). > > I do not know if the main use of (and motivation for) the sensor APIs is > webvr, but I have not been involved in it. I thought that (newer) API was > brought up in this discussion as a suggestion for a replacement for the > deviceorientation APIs. (Again, I’m unaware of the history or motivations > behind that API.) > > There has been some supposition in this discussion that the main use of the > device orientation APIs is the WebVR polyfill. I do not know if that is > true, I don’t think Chris or I said that — I haven’t seen any mention of any > data to support or not support that. It is clear that _a_ use of the device > orientation APIs is supporting WebVR polyfill. But it also used for > panoramic photo viewers, 360 video viewers, and probably other (legitimate) > things. Regardless, I fully understand the security/privacy concerns. > > My message this morning was intended to (perhaps) reframe the discussion and > (perhaps) let us move forward. Specifically: I was wondering about the real > impact of the webvr polyfill not working, on Firefox users. My mention of > the work implementing WebVR was pointing out that we will hopefully not need > to worry about the webvr-polyfil working on Gecko-based browsers in the > not-to-distant future, whenever we have full platform coverage for a real > WebVR/WebXR implementation. > > What is/was unclear to me is: > - if we’re including iOS in the list of platforms we may want to try and > remove device orientation from. Matters insofar as we WON’T be able to > implement WebVR/WebXR there. > - when WebXR (including “Magic Window” support) will ship in all versions of > Firefox. I could “guess” but that’s not useful (I have no control over that). > > But, if we laid out a plan that said “in the short term we’ll do X, which may > not be ideal, when WebXR is available we’ll do Y”, that might help. I hope > that the second step is not too far in the future, but thinking of it that > way at least doesn’t lock us into “we need to find a satisfactory solution > that keeps the webxr-polyfill working indefinitely” since it doesn't need to > work indefinitely. > > Please forgive me for the lack of clarity. And, of course, if that sort of > approach isn’t acceptable, just say so. > > > > On Jan 11, 2018, at 12:53 PM, Anne van Kesteren <ann...@annevk.nl > > <mailto:ann...@annevk.nl>> wrote: > > > > On Thu, Jan 11, 2018 at 6:48 PM, Blair MacIntyre <bmacint...@mozilla.com > > <mailto:bmacint...@mozilla.com>> wrote: > >>> In that case I'm not entirely sure why we'd also pursue new > >>> variants separately. > >> > >> I’m not sure what this means? > > > > That if our main usage for the new sensor APIs (those discussed in > > https://github.com/w3ctag/design-reviews/issues/207 > > <https://github.com/w3ctag/design-reviews/issues/207>) is WebVR/XR and > > we don't have any other uses that are compelling enough, and WebVR/XR > > will come with their own APIs for this, there's no reason for us to > > worry about the new sensor APIs. > > > > > > -- > > https://annevankesteren.nl/ <https://annevankesteren.nl/> > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
