Re: Device Orientation API future

> > 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

Re: Device Orientation API future

> 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,

Re: Device Orientation API future

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

Re: Device Orientation API future

I don’t understand this comment. > On Jan 11, 2018, at 12:50 PM, Martin Thomson wrote: > > As Anne said, I don't know why you would define a new API rather than > enhancing the existing one, other than NIH. But I guess the damage is > now done. > > On Fri, Jan 12, 2018 at

Re: Device Orientation API future

On Thu, Jan 11, 2018 at 6:48 PM, Blair MacIntyre 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

Re: Device Orientation API future

As Anne said, I don't know why you would define a new API rather than enhancing the existing one, other than NIH. But I guess the damage is now done. On Fri, Jan 12, 2018 at 4:48 AM, Blair MacIntyre wrote: >> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre

Re: Device Orientation API future

> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre > wrote: >> 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? > > I

Re: Device Orientation API future

On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre wrote: > 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? I believe there's

Re: Device Orientation API future

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

Re: Device Orientation API future

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

Re: Device Orientation API future

On Thu, Jan 11, 2018 at 5:39 AM, Chris Van Wiemeersch 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

Re: Device Orientation API future

On Thu, Jan 11, 2018 at 3:39 PM, Chris Van Wiemeersch 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? In general, we can't improve the situation by adding more

Re: Device Orientation API future

Martin, you gave some reasonable mitigation steps earlier in this thread that I think are probably worth revisiting. 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? On Wed, Jan 10, 2018 at

Re: Device Orientation API future

What Anne said. None of these actions help address the primary concern. On Wed, Jan 10, 2018 at 2:23 PM, wrote: > Exciting to hear, Kyle! > > As mentioned earlier, Chrome for Android M63+ has shipped an implementation > (disabled by default, with an Origin Trial) of

Re: Device Orientation API future

On Wed, Jan 10, 2018 at 4:23 AM, wrote: > 1. Lock down the Device Sensor APIs APIs in Gecko to only secure contexts, > with `deviceorientation`, `absolutedeviceorientation`, and `devicemotion` > being enabled by default. This helps with encouraging HTTPS adoption, but

Re: Device Orientation API future

Exciting to hear, Kyle! As mentioned earlier, Chrome for Android M63+ has shipped an implementation (disabled by default, with an Origin Trial) of the Generic Sensor API, but TAG review (https://github.com/w3ctag/design-reviews/issues/207) feedback needs to be addressed. For our WebVR use

Re: Device Orientation API future

I took over the DOM: Device Interfaces component last month, and as part of that was looking at the Generic Sensor APIs (and have been following this conversation too). I've read over the spec, but that's about it so far. While we've had a couple of outside questions about implementation, it

Re: Device Orientation API future

On Thu, Jan 4, 2018 at 11:15 AM, Blair MacIntyre wrote: > If we are going to break existing websites, then perhaps looking at the > Generic Sensor API (as CVan suggests in his email) is a more rational > approach; is it implemented in FF yet? Plans for it? See

Re: Device Orientation API future

My hope is that any stickiness would be transitory. If someone is obviously using a VR headset, I don't think we would require much movement at all to trigger the automatic permission. That's clearly a primary input interface. On Thu, Jan 4, 2018 at 9:15 PM, Blair MacIntyre

Re: Device Orientation API future

On Thu, Jan 4, 2018 at 9:06 PM, chris wrote: > Thanks for the clarification, Martin. Providing that the UA persists > permissions (based on user action –or perhaps also leveraging Google’s Safe > Browsing API which Firefox and all other browsers already rely upon – >

Re: Device Orientation API future

I’m unclear of which side of the line we want to fall on between supporting existing sites or requiring them to change. If we are going to break existing websites, then perhaps looking at the Generic Sensor API (as CVan suggests in his email) is a more rational approach; is it implemented in

Re: Device Orientation API future

On Thu, Jan 4, 2018 at 5:50 PM, wrote: > FYI: As implemented in Chrome, permission is automatically granted to use the > Generic Sensor API (`chrome://flags/#enable-generic-sensor`) in secure > contexts (e.g., HTTPS, localhost). Requiring secure contexts is not a

Re: Device Orientation API future

On Wednesday, January 3, 2018 at 2:43:43 PM UTC-8, Martin Thomson wrote: > On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre > wrote: > > I was more concerned about the idea (or, at least what I though might be > > suggested) that you only get orientation if they give

Re: Device Orientation API future

On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre wrote: > We could chat about it, sure; how do you envision it working without > breaking old websites? With the understanding that this is purely spitballing... We would stop providing events (or provide them with

Re: Device Orientation API future

We could chat about it, sure; how do you envision it working without breaking old websites? > On Jan 3, 2018, at 5:43 PM, Martin Thomson wrote: > > On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre > wrote: >> I was more concerned about the idea (or,

Re: Device Orientation API future

On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre wrote: > I was more concerned about the idea (or, at least what I though might be > suggested) that you only get orientation if they give location permission. > This seems overkill: even if I know what the data means, I can

Re: Device Orientation API future

On Wed, Jan 3, 2018 at 7:48 AM, Jonathan Kingston wrote: > For GPS we only ever talk about "location", I still don't think that is a > far stretch from head/position tracking. > ​Users aren't going to understand why their tilt-the-tablet labyrinth game needs to know they're in

Re: Device Orientation API future

I would tend to think that GPS location is more sensitive then device orientation, and so exposing device orientation if they’ve given location perms seems like a good avenue to explore, yes. I was more concerned about the idea (or, at least what I though might be suggested) that you only get

Re: Device Orientation API future

When the language for the permission prompt isn't going to be clear about what the user is exposing (screen, camera and mic) we should be talking about risks. For GPS we only ever talk about "location", I still don't think that is a far stretch from head/position tracking. On Wed, Jan 3, 2018 at

Re: Device Orientation API future

I don’t think tying orientation to GPS is really a viable approach. The main use case for the orientation API, I think, is not AR; it’s 360 images and videos, and “cardboard VR”, right now. > On Jan 1, 2018, at 5:01 PM, Martin Thomson wrote: > > The suggestion that was

Re: Device Orientation API future

The suggestion that was made in the past was to tie orientation to geolocation. I think that this would be obvious enough to pass. Orientation is basically a refinement of position. It clearly makes sense for AR applications. Pure VR applications might only care about relative orientation and

Re: Device Orientation API future

(I’m CC:ing a few of the MR team folks, although I’m sure many of them are on the dev-platform list already). Speaking for myself (not the official stance of the WebVR team), I share these concerns and like the trajectory you suggest. I would HOPE that in the long run (some number of years?)

Device Orientation API future

Following the intent to deprecate filed on Sunday for the Ambient Light and Proximity sensor APIs , we propose to discuss the future of the Device Orientation API. DeviceOrientation