> > 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
> 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,
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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 –
>
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
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
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
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
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,
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
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
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
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
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
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
(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?)
32 matches
Mail list logo