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