686401 - Restrict DeviceMotion to top-level document and same-origin frames

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect)

Description

[Jesse Ruderman]

It might not be obvious to web developers that including a third-party ad allows that ad server to snoop on keystrokes intended for the main page.  Perhaps we should expand the fix for bug 681562 to block DeviceMotion in third-party frames.

Comment 1

[Doug Turner (:dougt)]

this was discussed at the w3c geolocation face to face.  the reason that this isn't a good idea is that it will break widget applications that get embedded into a parent document.  Similar is true for geolocation.

Comment 2

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

That is not a good reason, IMHO, to not to do this.
We don't want ad server to be able to listen for keystrokes.

This needs more discussion, again IMHO.

Comment 3

[Ian Melven :imelven]

geolocation is a bad example IMO since when a site wants to use your location, it prompts asking "<site> wants to use your location". Even if it's in a third party frame, it will prompt with the source of the frame (or should, if it doesn't, this is a pretty bad bug).

The widget use case is a good argument against this restriction, is the argument for snooping keystrokes that an attacker can detect typed keys purely from accelerometer data ? I have heard about research/findings in this area from Lucas but need to dig more to find the primary source.

Comment 4

[Jesse Ruderman]

Bug 681562 comment 0 contains a link to the primary source.

Comment 5

[Daniel Veditz [:dveditz]]

What about a completely different approach: disable accelerometer events when the focus is on a type=password input field or autocomplete=off field/form. Pretty hacky, but a reasonable rough cut at "this site thinks this data is sensitive".

Comment 6

[Daniel Veditz [:dveditz]]

Or add a DOM call that a non-top-level frame needs to call to request DeviceMotion data, and require explicit opt-in if they're not same-origin with the top-level frame. Make the choice rememberable and then it's not so bad in the widget case.

Comment 7

[Doug Turner (:dougt)]

sg:moderate?

Comment 8

[Ian Melven :imelven]

(In reply to Doug Turner (:dougt) from comment #7)
> sg:moderate?

see https://wiki.mozilla.org/Security_Severity_Ratings

this rating is open to discussion and dialogue, as it always is.

Comment 9

[Johnny Stenback (:jst)]

(In reply to Daniel Veditz from comment #5)
> What about a completely different approach: disable accelerometer events
> when the focus is on a type=password input field or autocomplete=off
> field/form. Pretty hacky, but a reasonable rough cut at "this site thinks
> this data is sensitive".

That doesn't cover the case where I'm using gmail or some other web mail or what not and I'm writing a confidential/personal email that is very sensitive etc etc.

Comment 10

[Doug Turner (:dougt)]

what we know:

1) right now the proof-of-concept attack is at its very early stages -- poor accuracy, implemented to a 10 key keyboard not a full keyboard.

2) the attack *might* get better.


If we do nothing:

1) there is a possibility that the attack gets better, that a site embeds content that uses this api, and there is a privacy loss.


If we restrict the event:

Any site that wants to use iframes for widgets (think igoogle, or similar) will not be able to use orientation events.

Google Chrome is not going to put this restriction in, and so we will have sites that "Work in Chrome and HTML5", and those same sites not working in Firefox.


It seems to me that the decision really rests with if the attack quality getting better.  If the attack can reliably get keydata, then I would be more likely to fix this problem.  If the attack doesn't get any better than it is, i tend to think we are over-reacting.

The course of action should be to monitor this style of attack, and if it improves, we move ahead with this restriction.

Comment 11

[Ian Melven :imelven]

(In reply to Doug Turner (:dougt) from comment #10)
> what we know:
> 
> 1) right now the proof-of-concept attack is at its very early stages -- poor
> accuracy, implemented to a 10 key keyboard not a full keyboard.
> 
> 2) the attack *might* get better.

70% accuracy is not that poor, they don't need to get an exact read of the password etc. just enough that brute forcing even with lockouts etc becomes significantly more feasible.

An additional requirement for their attack is that the algorithm be 'trained' also, ie you need to teach it what each number looks like. To me, this implies it's going to be device/hardware specific as well, as training it against one device seems like it may not carry over to a device with a different hardware sensor or weight/size differences etc. This plus the fact that as Doug points out 

I think monitoring the attacks and the posture of other implementors

Comment 12

[Ian Melven :imelven]

Oops, accidentally clicked Save Changes too soon :(

This plus the fact that as Doug points out the attack has currently only been shown against a 10 key numeric soft keyboard, not a full keyboard containing alphanumerics and symbols leads me to think that sg:moderate is an appopriate rating here.

I think monitoring the attacks and the posture of other implementors, including plugins, in regards to protections around accelerometer is a decent strategy here.

Comment 13

[Josh Aas]

If we don't think this is a significant threat to our users now (Ian, am I reading your comments correctly?) then I think we should open this bug up. People will likely be better off informed here and we'll benefit from a wider discussion of this possible threat.

Agreed, Ian?

Comment 14

[Lucas Adamski [:ladamski]]

I agree with opening this up.

Comment 15

[Ian Melven :imelven]

(In reply to Josh Aas (Mozilla Corporation) from comment #13)
> If we don't think this is a significant threat to our users now (Ian, am I
> reading your comments correctly?) then I think we should open this bug up.
> People will likely be better off informed here and we'll benefit from a
> wider discussion of this possible threat.
> 
> Agreed, Ian?

I agree also, as does Curtis. Opening this up.

Comment 16

[Ian Melven :imelven]

Removing sec-review-needed and myself as sec reviewer since for now we're just tracking and discussing this concern.

Comment 17

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

Marcos, do you happen to know if the spec is going to say something about this, and should it?

Comment 18

[Marcos Caceres [:marcosc]]

It currently doesn't, but I've filed a bug on the spec to mention it:
https://github.com/w3c/deviceorientation/issues/13

Comment 21

[Marion Daly [:mdaly]]

Marking as incomplete.