Repository navigation
Move fingerprintable APIs behind permissions #85
Description
According to the authors of this paper, the standard includes functionality that allows users to be fingerprinted with high fidelity. (quote: “the DeviceMotionEvent APIs, particularly DeviceMotionEvent.acceleration and DeviceMotionEvent.rotationRate”) don’t require permissions to access. The standard needs to be updated so that users cannot be passively fingerpritined.
Migrated from w3c/sensors#398
Activity
anssiko commentedon Oct 25, 2019
@snyderp thanks for bringing this paper to the group's attention.
Since the paper was published, the group has done a number of privacy enhancements to the spec that I believe addressed the issue.
To summarize:
requestPermission()operation toDeviceMotionEventandDeviceOrientationEvent, specifiedrequestPermission()related algorithms in detail, and added a permission model section.Further implementation experience is being gathered for the permission model and specification clarifications informed by this experience are being discussed in GitHub issue #74.
Please review the latest spec and let us know of any further changes you think are required to mitigate the identified vector adequately.
pes10k commentedon Oct 26, 2019
@anssiko thanks for the follow up! A couple of notes:
re the
requestPermission()update, i see your point that it seems to address the attack. I will follow up with the paper authors and see if they agree / have away of carrying out the attack otherwise and report back here.re: Making the security and privacy considerations mandatory, i think this is a great first step, but two remaining concerns:
pes10k commentedon Oct 30, 2019
re 1. I just heard back from the paper authors. They think the permission dialog is sufficient to handle the majority of the problem (e.g. they don't see any un-permissioned access to the information) but they still think the sensors could be used to uniquely identify devices w/ high quality sensors / accelerometers.
To address the second problem, what do you think of limiting the precision of the relevant sensors? The authors suggest adding noise, but that would see to be difficult both implementation and useability wise. Simply caping the returned values to some max # of values / decimal points might be an easier-to-standardize, easier to reason-about option. WDYT?
reillyeon commentedon Oct 30, 2019
I think it depends on how much precision needs to be removed. If the fingerprintable identifier is just above the noise floor for these sensors then we should be able to remove it without measurably impacting applications. In contrast, mitigating concerns in the Ambient Light Sensor API required reducing precision significantly and thus required a deeper understanding of the use cases and how they would be affected.
pes10k commentedon Oct 31, 2019
@reillyeon Sounds good, i've gone back to the paper authors to see if they can give guidance on how much precision would need to be reduced to reduce identifiability. I expect it'll just be precision / bits-of-identification trade off, but there might be some sig threshold they can point to where the attack becomes infeasible, or more likely, as precision increases linearly, identification should (might?) increase exponentially, so there should be a useful / beneficial tradeoff to be made.
Either way, I'm speculating; i'll circle back in a few days or when i hear back from the researchers. Thanks!
pes10k commentedon Nov 7, 2019
@reillyeon I have heard back from the researchers, and they said they will not have time to do this analysis, though they expect it would be possible.
Given that they've already done the difficult work of documenting the issue, and believe it would be possible to prevent the attack through sensor accuracy reductions, I'd like to ask the WG to reach out to a domain expert and / or statistician to figure out how much accuracy reduction / limiting would be needed to address the problem, and to come up with a proposal to address the problem through accuracy reduction.
I will also ask in the next PING meeting and see if anyone there has expertise they can share too
anssiko commentedon Nov 19, 2019
@snyderp thanks for your help. It seems the next PING call will be 5 Dec 2019. It would be much appreciated if you could put this topic on the agenda, discuss within PING and report back.
All - if you feel like making a data-driven privacy-enhancing contribution, this is your opportunity to make a positive impact in this space, and get prominently acknowledged in relevant specifications for your contribution.
pes10k commentedon Nov 19, 2019
Hi @anssiko! This topic was on the agenda for our last call. We have a member seeing if someone on their team internally can work on this. I've reached out to them for an update.
That being said, I think it would still be good for the WG to also pursue researchers / statisticians as well, for their guidance too (internally or through outreach), as we'll need to find someone who can assist, and I expect we can reach out to non-overlapping groups
pes10k commentedon Nov 19, 2019
@anssiko it looks like the team I've contacted will not be able to complete the review by Dec 5, though possibly by a follow up call. I'm reaching out to other contacts, but in the meantime…
What does the WB think about formalizing the mitigation in the paper (noise injection) instead? To my mind it seems more complex, and so harder to standardize, but if the WG thinks that'd be viable, that'd also be a fine way forward. I still think its worth looking into capping resolution as a simpler possible mitigation, but curious on your thoughts for the above as a fallback option
reillyeon commentedon Nov 19, 2019
My reading of the paper is that both noise injection and resolution reduction require some knowledge about the underlying hardware sensor. Before this WG recommends a particular solution an investigation needs to be made into whether it is practical to implement across the most common platforms they target. In addition, implementations should likely consider whether or not the platform itself implements similar mitigations.
pes10k commentedon Nov 19, 2019
@reillyeon my understanding of the paper and from discussions with the authors is that the only connection to the hardware is that it requires hardware of high enough quality to fix. The expectation of the authors, and their findings in the paper, is that has hardware gets better, the problem will only get worse. Are you saying an investigation needs to be done about whether the attack is practical across common platforms (in which case, the paper seems to find "yes, and increasingly so") or whether the mitigation is practical?
I dont think the authors find any platforms that have intentional mitigations, only those with low-quality sensors that are "accidentally" protected.
scheib commentedon Dec 4, 2019
I agree we should mitigate privacy concerns.
From a specification point of view, I think we need to call out the concern and risk and note that user agents may mitigate concerns. I don't think the particular mitigations should be normative, as they may need to be adjusted over time and or different user agents may make different determinations over utility vs privacy.
From an implementation point of view, I think user agents need to develop practical model and implementation of the threat to have criteria to know if mitigations are effective. [edit: adding for clarity: That is, I think we need to develop a test that can validate there is a fingerprint concern. Then, mitigations can be tested against it.]
We must also determine if the threat should be mitigated at the user agent or operating system level.
pes10k commentedon Dec 4, 2019
@reillyeon @anssiko has your group had any success in finding an expert to look into accuracy-reduction defenses against the FP attack
@scheib punting privacy concerns as "implementation details" has been (to put it mildly) not successful privacy strategy on the web. If a group is saying "functionality should be included" (e.g. a standard) its beholden on them to say how it can be done so in a privacy preserving manner.
If things change, and protections need adjusting, then the standard would need to be updated, just as standards are updated for many other reasons.
If I understand this right, the idea is "ship it and we'll fix it after it ships"? Also, has not been a super successful privacy strategy on the web so far ;) Privacy focused vendors spend a nightmare amount of time trying to figure out how privacy protections can be bolted onto shipped functionality w/o breaking websites, and… its a loosing game. Get the privacy right from the start
anssiko commentedon Dec 5, 2019
Not yet. This is a multidimensional problem. We need someone who can look into implementation feasibility across all major platforms, evaluate the platform-level mitigations already in place, as well as understand whether and how the key use cases would be affected by these mitigations. Please feel free to recommend us people from privacy community with relevant expertise we could work with.
pes10k commentedon Dec 5, 2019
@anssiko as an update, it looks like a PING member from Berkeley, and a member of the Blink team, will both be looking into this a bit over the next two weeks. I believe they will specifically be looking into whether-and-how-much is needed for the accuracy reduction techniques to be successful. I will let you know what i hear back. If it would be useful too, i would be happy to try and put you all in touch too
20 remaining items
reillyeon commentedon Aug 10, 2020
Chromium has implemented the mitigation described in #86.
pes10k commentedon Aug 10, 2020
Absolute best possible answer :) Thanks @reillyeon for the update (and thanks @shartoo for the question!)
shartoo commentedon Aug 11, 2020
@pes10k I've tested on Google Pixel 4 and Huawei P30 pro which were recently published devices.Here are some sample results
shartoo commentedon Aug 11, 2020
But i could't got stable estimated gain matrix for every sample file(sample one device for 50 times and get one file every time,every sample file contains about 100 records of x,y,z),some of my estimated gain matrix :
file 1: [[ 0. 0. 0. ]
[ 0. 0. 0. ]
[ 0. 0. 156.762112]]
file2 : [[52.2719942 52.2719942 52.2719942 ]
[52.27195051 52.27195051 52.27195051]
[52.25403733 52.25403733 52.25403733]]
i can't figure out which step i've done wrong.
shartoo commentedon Aug 11, 2020
All of my sample data are sampled when the devie stay absolute still on the desk,thus the basic approach(not the improved approach) should work.
According to the description in the paper,the computation steps should be
pes10k commentedon Aug 11, 2020
@shartoo thats fantastic that you're digging into this problem, though i think at this point you might have more luck reaching out to the paper authors, who might have more insight into if there is an issue in your implementation, or their approach, or if changes in browser behavior explain the difference. If you reach an answer though, i'd be very interested to know what you find out!
shartoo commentedon Aug 11, 2020
I've tried to email two authors both but no response,so i wondered if the approach was really credible . But the result showed in the paper mainly on IOS,while mine are on Android ,i'm not sure . The data and result i got were from android app rather than brower . There is a fingerprintjs2 which can be embed into a brower,whose author is Peter too.
anssiko commentedon Aug 11, 2020
@shartoo, thank you for your data-driven contribution that seems to validate the attack described in the paper has been mitigated on Android for devices you used in your experiment.
@pes10k, related, I think we should acknowledge people who make positive contributions in the important area of privacy-enhancement for this specification. Feel free to think of people who we should thank in https://w3c.github.io/deviceorientation/#acknowledgments I would like to acknowledge your contributions, so you don’t need to self-promote.
shartoo commentedon Aug 11, 2020
According to the paper, if any mitigatation had been made ,the output of ADC should be unstable .But as you seen above ,at least the ADC output of Google Pixel are very stable.I'm afraid the attack has not been mitigated yet.
anssiko commentedon Aug 11, 2020
@shartoo, to get a more complete picture, it would be helpful if you could publish the results from all the 20 devices you tested along with details on the OS and browser version(s). Thank you for your contribution.
shartoo commentedon Aug 11, 2020
Here is the detail of some test device,not all data are include.
anssiko commentedon Aug 11, 2020
@shartoo, thank you. IIUC, your results are from an Android app. As for the web specification, this issue has been addressed in b95751e to advise web engine implementers on the mitigation, and I'm aware at least Chromium has implemented it: https://crbug.com/1018180
@reillyeon may know whether there's an open bug for Android where @shartoo could report these findings.
maryammjd commentedon Aug 12, 2020
Hi Everyone,
We have been running experiments on Android devices as well as some gyro on some sensor kits via native apps to fingerprint them according to SensorID paper and got similar unstable results. These attacks work on the sensors that are factory-calibrated. According to the project webpage:
"Can we conduct the same attack to fingerprint other Android devices?
We have found that the accelerometer in Google Pixel 2 and Pixel 3 can be fingerprinted by our calibration fingerprinting attack. It is possible that some other Android devices are also factory calibrated and thus can be fingerprinted. However, we only have data from a few Android device models; the Android device models we have tested, apart from Google Pixel 2 and 3, cannot be fingerprinted using our approach."
shartoo commentedon Aug 12, 2020
Hi @maryammjd i got relative stable result on OnePlusONEPLUS A6000 on accelerometer sensor data,some example result may looks like:
[[313.97989797 -0.00022042 -0.00079312]
[ 0.00005471 313.98001487 -0.00009762]
[ 0.00196805 -0.02164853 313.95306167]]
[[313.97999159 0.00022686 0.00109395]
[ -0.00001855 313.98011056 -0.00008026]
[ 0.00544453 0.01461957 313.97803559]]
[[313.97990616 -0.00003449 0.00024145]
[ -0.00002185 313.98007057 0.00002185]
[ 0.01494681 0.00114975 313.97492772]]
[[313.97998885 -0.00024576 0.00068462]
[ 0.00000731 313.98014976 0.00006495]
[ 0.0016579 -0.00273067 313.97497905]]
But this did not work on Huawei P30 pro at present and i have not yet done further test if this could distinguish two device of same hardware.
maryammjd commentedon Aug 14, 2020
I found a new paper and was not sure if everyone has seen it:
The Seven Deadly Sins of the HTML5 WebAPI: A Large-scale Study on the Risks of Mobile Sensor-based Attacks.
I hope it is not behind a pay-wall for others.