Re: Device orientation/motion events privacy issues

[Tom Ritter]

On Fri, Sep 22, 2017 at 8:39 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> * Ensure that we don't leak this information when fingerprinting
> resisting is turned on for the Tor Browser if we don't already.

Tor sets device.sensors.enabled to false, which should disable these
events. (If that's not the case, we'd love to hear about it!)

We also 'set' this pref (without setting it) when
privacy.resistFingerprinting is set. This is
https://bugzilla.mozilla.org/show_bug.cgi?id=1369319

-tom

[Ehsan Akhgari]

Great, thanks for checking Tom!

Cheers,
Ehsan

[Ehsan Akhgari]

On 09/22/2017 10:20 AM, James Willcox wrote:
>
>
> On Fri, Sep 22, 2017 at 8:39 AM, Ehsan Akhgari

> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>> wrote:
>
> Hi everyone,
>
> A couple of weeks ago, this proof of concept attack circled its
> way around Twitter:
>
> https://krausefx.github.io/whats-the-user-doing/
> <https://krausefx.github.io/whats-the-user-doing/>
>
> This simple web app, once loaded on mobile, with a disturbing
> degree of accuracy, can tell what the user is doing with their
> phone, for example, using it while walking, lying in bed, etc. 
> The way it does this is through listening to
> deviceorientation/devicemotion events as defined in
> <https://www.w3.org/TR/orientation-event/
> <https://www.w3.org/TR/orientation-event/>>.
>
>
> I just tried this web app and I have to say I'm not very impressed.
> It's just taking a wild guess based on some smoothed out orientation
> data, the heuristic is not very advanced[0]. However, I guess it may
> be possible to craft a more clever analyzer using ML or something, so...

Of course.  As the author describes in the README, this is a 1 hour
Sunday night project that he did in order to raise awareness about this
privacy issue, it wasn't designed to be really good at stealing your
private information.  I think it is good enough demonstration to show
that we need to act on addressing this problem.

> We recently discussed an intent to remove the rest of the sensor
> APIs we currently support, besides these two:
> <https://groups.google.com/d/msg/mozilla.dev.platform/45XApRxACaM/Fc3XxHgzCAAJ
> <https://groups.google.com/d/msg/mozilla.dev.platform/45XApRxACaM/Fc3XxHgzCAAJ>>.
> These two events are considered to be useful for web applications
> that want to create experiences that rely on being able to tell
> the orientation of the device, for example.
>
> I would like to start a discussion about how to address the
> recently surfaced privacy concerns.  There are several things that
> we can do which come to mind:
>
>   * Restrict dispatching these events to secure contexts.  That
> way we don't potentially leak this information to MITM attackers
> on the network.
>
>
> This seems fine as long as localhost is also allowed.
localhost is a secure context, so it will be allowed.
>
>   * Apply some of the precautions recommended in
> <https://www.w3.org/TR/2016/CR-orientation-event-20160818/#security-and-privacy
> <https://www.w3.org/TR/2016/CR-orientation-event-20160818/#security-and-privacy>>,
> for example, refrain from displatching these events inside
> invisible pages or background pages.  Also, only fire them in
> top-level browsing contexts and same-origin nested browsing
> contexts in order to avoid leaking this information to third-party
> iframes.
>
>
> We already block these events for cross-origin iframes. Turning them
> off for background pages sounds good if we don't already do it. This
> would save battery and largely mitigate the kind of privacy attack above.
Great.  Thinking about this more, should we also disable these events
when the phone screen is turned off?
>
> And limit the frequency of the event dispatches to once per
> refresh cycle maximum.
>
>
> 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...

[Blair MacIntyre]

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

(For those who are interested: a group of us over in Emerging Technology have been working on expanding WebVR to include AR/MR use cases, we’re documenting this “WebXR" proposal in github.com/mozilla/webxr-api, and building a sample implementation in github.com/mozilla/webxr-polyfill. We’ve also got a sample iOS app, for demonstrating/using it on iOS, that leverages ARKit, in github.com/mozilla/webxr-ios).

I mention this because, at some point in the future, there will hopefully be VR and AR/MR apis (perhaps via this webxr proposal, perhaps via a different one) in most browsers, and that that point, the uses for this API may diminish. They are still used by various polyfills (e.g., the WebVR polyfill uses deviceorientation), since WebVR isn’t in all browsers yet, and will be used by WebXR and other similar efforts for some time as well.

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.

[James Willcox]

On Fri, Sep 22, 2017 at 8:39 AM, Ehsan Akhgari <ehsan....@gmail.com>

wrote:

> Hi everyone,
>
> A couple of weeks ago, this proof of concept attack circled its way around
> Twitter:
>
> https://krausefx.github.io/whats-the-user-doing/
>

> This simple web app, once loaded on mobile, with a disturbing degree of
> accuracy, can tell what the user is doing with their phone, for example,
> using it while walking, lying in bed, etc. The way it does this is through
> listening to deviceorientation/devicemotion events as defined in <
> https://www.w3.org/TR/orientation-event/>.
>

I just tried this web app and I have to say I'm not very impressed. It's
just taking a wild guess based on some smoothed out orientation data, the
heuristic is not very advanced[0]. However, I guess it may be possible to
craft a more clever analyzer using ML or something, so...


>

> We recently discussed an intent to remove the rest of the sensor APIs we
> currently support, besides these two: <https://groups.google.com/d/

> msg/mozilla.dev.platform/45XApRxACaM/Fc3XxHgzCAAJ>. These two events are
> considered to be useful for web applications that want to create
> experiences that rely on being able to tell the orientation of the device,
> for example.
>
> I would like to start a discussion about how to address the recently
> surfaced privacy concerns. There are several things that we can do which
> come to mind:
>
> * Restrict dispatching these events to secure contexts. That way we
> don't potentially leak this information to MITM attackers on the network.
>

This seems fine as long as localhost is also allowed.

> * Apply some of the precautions recommended in <
> https://www.w3.org/TR/2016/CR-orientation-event-20160818/

> #security-and-privacy>, for example, refrain from displatching these
> events inside invisible pages or background pages. Also, only fire them in
> top-level browsing contexts and same-origin nested browsing contexts in
> order to avoid leaking this information to third-party iframes.
>

We already block these events for cross-origin iframes. Turning them off
for background pages sounds good if we don't already do it. This would save
battery and largely mitigate the kind of privacy attack above.

> And limit the frequency of the event dispatches to once per refresh cycle
> maximum.
>

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.

James


[0]
https://github.com/KrauseFx/whats-the-user-doing/blob/master/index.html#L69

[Anne van Kesteren]

On Fri, Sep 22, 2017 at 4:50 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> 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 filed https://github.com/w3c/permissions/issues/158 for a simplified
version of the API and pinged Jeffrey Yasskin from Google about it on
IRC. Another alternative we could pursue is add something dedicated
for orientation/motion somewhere; perhaps on the navigator dumping
grounds. But it would be good if we could get orientation/motion
events maintained somehow then so this can just be put in that
document.


--
https://annevankesteren.nl/

[Ehsan Akhgari]

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?

[Blair MacIntyre]

>>> 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. :-)

Good points, I agree, it shouldn’t be a blocker … it just seemed like this might be one of those situations that really exacerbates it.

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

That last statement was mostly aimed at the idea that “if the applications that require high resolution data, perhaps including games, could shift to using WebVR/WebAR APIs to get at orientation, then having filtered data, or permission prompts, would impact less of the use cases”.

Beyond that, I was mostly just thinking about the things that have been suggested
- permission prompts
- perhaps allowing pages to request lower fidelity data, or reduced data: if I’m a game that really just wants to tilt left/right, perhaps I can just request that? Or (as suggested) reduce frequency. The location API has multiple levels of fidelity you can request.
- since the APIs are often used for relative motion, perhaps we could add a random starting orientation delta, so they don’t align with the world.

Not sure how feasible/useful they are, and what the programmer ergonomics would, but it certainly reduces the data being sent to the browser. And perhaps some lower precision, or “offset / filtered” versions could be returned without user permission prompts, while others could result in prompts.