New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Duplicate
Merged: issue 598674
Closed: Feb 15
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Security

issue 598674

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Risks in current privacy/security policies of accessing to the mobile orientation and motion sensors via JavaScript codes

Reported by, Aug 21 2015

Issue description

Steps to reproduce the problem:
I am writing to you on behalf of a team of researchers in mobile security from Newcastle University, UK. Based on our recent work, we have identified vulnerabilities in the current implementations of Chrome for both Android and iOS platforms in regards to accessing to mobile orientation and motion sensors via JavaScript codes. The results of our work show that it is possible to infer user’s touch actions such as click, scroll, and zoom, as well as his PINs based on the sensor streams accessible through different mobile browsers including yours. This feature seems to be implemented in Chrome according to the W3C device orientation event specification ( which needs to be revised too. 

A preliminary version of our work is already published here ( The detailed version of the paper including attacks on user’s PINs will be published soon. 
We would be very happy to provide you with more information in regards to this problem.
Maryam Mehrnezhad

What is the expected behavior?

What went wrong?
User's sensitive information will be compromised. 

Did this work before? N/A 

Chrome version: 44.0.2403.133  Channel: n/a
OS Version: 5.1.1
Flash Version: NA
Labels: Security_Impact-Stable Security_Severity-Low
Can you provide a site that demonstrates this data leak?
We are not aware of any website which performs this attack. We have implemented our own JavaScript code and trained a system to identify user's sensitive information such as PINs. A more detailed version of our work is available from here:

Labels: Cr-Security-UX Cr-Security
A similar attack was discussed in detail on .  The conclusion there (#50 by palmer) was "the risk is acceptable as long as the web origin taking the accelerometer readings is in the main frame, in the foreground."

palmer -- Do you think that applies here?

The unpublished paper [1] uses Chrome's 60Hz sampling, and cites a 70% accuracy rate at detecting PIN digits.  This presumes the user is tapping a number key pad while the attacker's site, or iframe, is in the foreground.


Comment 4 by, Aug 21 2015

It sounds like a good reason to restrict it from iframes.

However I am not too worried about the parent frame case, because why would you be typing your device PIN into a website anyway?
Answer to comment #3: Yes it is a similar attack. 
Also as we observed and reported it in our unpublished paper, Chrome has different behaviors on Android and iOS. It provides access to the inactive tab in iOS too. Our attack scenario is easily applicable to this case too. 

Answer to comment #4: I do not exactly understand your question. I assume you mean users are more likely to deal with a website which requires them passwords rather than PINs. If that is your concern, we approve that. At the moment, we are working on the full keyboard recognition. 
Project Member

Comment 7 by ClusterFuzz, Aug 25 2015

Labels: Untriaged-1

Comment 8 by, Aug 27 2015

Re #6:

What I mean is that it isn't a risk for a foreground parent frame to be able to tell what you're typing (since it can do so anyway). If we ensure that the API requires both foreground status and parent frame, I think this problem should be resolved?
Re #8
At the moment there exist two different vulnerabilities in Chrome. First, having access to the mentioned sensor data by an inactive tab in the implementation of Chrome for iOS. Second, having access to the sensor data via iframrs which their origin is not the active (foreground) tab, on Android and iOS. In this case, for example an advert with the malicious code, does not have access to what you type directly, but it has access to the side channel sensor data and will threaten user's privacy/security.
Project Member

Comment 10 by ClusterFuzz, Aug 28 2015

Labels: -Untriaged-1 Untriaged-2
Project Member

Comment 11 by ClusterFuzz, Sep 1 2015

Labels: -Untriaged-2 Untriaged-3
Status: Assigned
Over to felt in order to make a policy decision on this one.

Comment 13 Deleted

May I ask you please to update me if any decision/implementation has been made/suggested on this issue?

Comment 15 by, Dec 3 2015

Blocking: 598674
Quick update: we're still discussing the options here.  It's tempting to just copy mobile safari (issue 598674) but we're concerned about limiting valuable scenarios.  Eg. embedded spherical videos, embedded maps using orientation data, etc. 
Thanks for the update Rick. We believe that the concern is valid too. 
Some summaries from an internal discussion thread:
 - We don't want to rely on user prompts, we don't think users will generally understand the implications
 - We may be willing to allow parent frames to opt-in to delegating sensor access to iframes (they can do this if the really want to already by postmessaging the data), but there is still some security risk there
 - We're particularly concerned about preventing interesting future use cases.  We suspect we could copy Safari's behavior without breaking too much existing content, but preventing new forms of content (like spherical video) is a serious risk.
Oh and we'd love to know if there's a safe rate we could throttle down to that might still be useful (eg. is 5hz still at all exploitable, what about 10hz)?

Or perhaps we could introduce some entropy / reduced spacial precision into the data which wouldn't seriously affect common use cases but would still mitigate the attack.
Hi, As I discussed it earlier, we also think that relying on user prompts is not a usable approach. We are currently conducting experiments on this, and will share the results with the community in the near future.  
A bunch of history (this has been actively discussed since 2011):

FWIW I think we should hold out changing anything here until we have either:
1) some indication this is actually being attacked (pinpad entry on the web for sensitive information is quite rare)
2) indication that this attack can also be used to detect keystrokes on a full on-screen keyboard (in which case passwords could be at risk), or
3) A mitigation that doesn't completely break legitimate use cases like embedded spherical video (eg. introduction of entropy, reduce sampling rate, etc).
Given that this attack has been discussed in the community for awhile, I think we should open this bug up (as the mozilla bug was several years ago: (  Any objections to removing the restriction?

My understanding is that both Safari and Firefox now block the cross-origin situation ( There is a more recent mozilla bug:
which implements the fix in Firefox 46.

Comment 27 by, Apr 11 2016

rbyers, what's concerning about opt-in to delegate cross-origin iframe access?

Comment 28 by, Apr 11 2016

Labels: -Untriaged-3 -Restrict-View-SecurityTeam
I agree with rbyers... bug is now public.
IMHO opt-in is a pretty poor tradeoff:

1) It doesn't address a lot of the scenarios.  Eg. say Youtube wants to add spherical video support, they can't change all the existing iframe code out there (though they can suggest using it for new embed).

2) If the risk of attack is real, then an opt-in to insecure mode may (in the long run) lead to users still being subject to most of the risk.  Eg. if a few ads wants to show a perspective effect on device motion (especially if they're willing to pay slightly more for such ads) then all ad networks will eventually opt-in by default, without really knowing if the code they're running could be stealing keystrokes.  Perhaps this is no worse than existing malvertising scenarios (which already have robust mitigations), but it's still a risk.

That said, if there's new reason to believe the risk here is substantial, an opt-in (at least while we try to figure out the right long-term strategy) seems like a reasonably pragmatic step to me.
Labels: Hotlist-Input-Dev
Components: -Security>UX Internals>Permissions>Model
Components: -Security>UX Internals>Permissions>Model

Comment 33 by, Apr 10 2017

Weird, how did the SecurityTeam view restriction get added back on? I don't see the label but nonetheless it's view restricted.

Comment 34 by, Apr 10 2017

Labels: allpublic

Comment 35 by, Aug 21 2017

Components: Privacy

Comment 38 by, Sep 9 2017

See also my proposal in as a middle-ground alternative.
Labels: Hotlist-EnamelAndFriendsFixIt
Mergedinto: 598674
Status: Duplicate (was: Assigned)

Sign in to add a comment