9 ms·
There is no way to escape fingerprinting. Just one example: A script which runs many different types of computations. Each computation will take a certain amou
by Timja 3y ago
There is no way to escape fingerprinting.
Just one example: A script which runs many different types of computations. Each computation will take a certain amount of time depending on your hardware and software. So you will get a fingerprint like this:
computation 1: **
computation 2: ****
computation 3: **********
computation 4: **
computation 5: **************
computation 6: ************
computation 7: *********
etc
There is no way to avoid this. You can make the fingerprint more noisy by doing random waits. But thats all.
- fulafel 3y agoIt's possible to have the runtime execute the computations in fixed time across platforms.
- foldr 3y agoCould you explain what techniques would make this possible? I can see how it's possible in principle, if you, say, compile JS down to bytecode and then have the interpreter time the execution of every instruction. I don't immediately see a way to do it that's compatible with any kind of efficient execution model.
- fulafel 3y agoThe rest would be optimization while keeping the timing sidechannel constraint in mind, hard to say what the performance possibilities are. For example not all computations have externally observable side effects, so those parts could be executed conventionally if the runtime could guarantee it. Or the program-visible clock APIs might be keeping virtual time that makes it seem from timing POV that operations are slower than they are, combined with network API checkpoints that halt execution until virtual time catches up with real time. Etc. Seems like a interesting research area.
- foldr 3y ago>not all computations have externally observable side effects You can time any computation. So they all have that side effect. Also, from Javascript you can execute tons of C++ code (e.g. via DOM manipulation). There's no way all of that native code can be guaranteed to run with consistent timing across platforms.
- fulafel 3y agoDepends on who you mean by "you". In context of fingerprinting resistance the timing would have to be done by code in certain limited ways using browser APIs or side channels that transmit information outside the JS runtime. Computations that call into native APIs can be put in the "has observable side effects" category (but in more fine grained treatment, some could have more specific handling).
- foldr 3y agoI'm not sure what you mean. All you need to do is this: function computation() { ... } before = performance.now(); computation(); t = performance.now() - before; (Obviously there will be noise, and you need to average a bunch of runs to get reliable results.)
- fulafel 3y agoIn this case the runtime would not be able to guarantee that the timing has no externally observable side effects (at least if you do something with t). It would then run in the fixed execution speed mode.
- hexo 3y agoRuntime doesnt have full controll but could introduce a lot of noise in timing and performance. Could it help?
- fulafel 3y agoIt's hard to reason about how much noise is guaranteed to be enough, because it depends on how much measurement the adversary has a chance to do, there could be collusion beween several sites, etc. To allow timing API usage I'd be more inclined toward the virtual time thing I mentioned upthread.
- jeffparsons 3y agoSure. And nobody actually wants that, because it would be so restrictive in practice that you might as well just limit yourself to plain text. The horse bolted long ago; there's little sense in trying to prevent future web platform features from enabling fingerprinting, because the existing surface that enables it is way too big to do anything meaningful about it. Here are a couple of more constructive things to do: - Campaign to make fingerprinting illegal in as many jurisdictions as possible. This addresses the big "legitimate" companies. - Use some combination of allow-listing, deny-listing, and "grey-listing" to lock down what untrusted websites can do with your browser. I'm sure I've seen extensions and Pi-hole type products for this. You could even stop your browser from sending anything to untrusted sites except simple GET requests to pages that show up on Google. (I.e. make it harder for them to smuggle information back to the server.) - Support projects like the Internet Archive that enable viewing large parts of the web without ever making a request to the original server.
- paulgb 3y agoThis would essentially mean that every computation would have to run as slow as the slowest supported hardware. It would completely undermine the entire point of supporting hardware acceleration. I’m sympathetic to the privacy concerns but this isn’t a solution worth considering.
- codedokode 3y agoThe solution is to put unncesessary features like WebGL, programmatic Audio API, reading bits from canvas and WebRTC behind a permission.
- azangru 3y agoWho decides what's unnecessary?
- codedokode 3y agoEverything that can be used for fingerprinting should be behind a permission. Almost all sites I use (like Google, Hacker News or Youtube) need none of those technologies.
- mastax 3y agoSo CSS should be behind a permission?
- codedokode 3y agoCSS should not leak fingerprinting information. After all this is just a set of rules to lay out blocks on the page.
- remexre 3y agohttps://css-tricks.com/css-based-fingerprinting/ https://css-tricks.com/css-based-fingerprinting/
- kevingadd 3y agoNo video driver is actually going to implement fixed-time rendering. So you'd have to implement it in user-space, and it would be even slower than WebGL. Nobody wants that. You're basically just saying the feature shouldn't ship in an indirect way (which is a valid opinion you should just express directly.)
- fulafel 3y agoI don't mean to prescribe the way to stop fingerprinting, just throwing out a trivial existence proof, and maybe a starting point of thinking, that it's not impossible like was suggested. Also, WebGPU seems to conceptually support software rendering ("fallback adapter"), where fixed time rendering would seem to be possible even without getting cooperation from HW drivers. Being slower than WebGL might still be an acceptable tradeoff at least if the alternative WebGL API avenue of fingerprinting could be plugged.
- littlestymaar 3y agoYou only get fingerprinting from your method if the variation of the “fingerprint“ between two different runs by the same user is lower than the difference you get between two different users. This is far from obvious since it depends a lot on the workload running on the machine at the time. I'm not aware of a single fingerprinting tool that primarily use this king of timing attack rather than more traditional fingerprinting methods.
- Timja 3y agoNot sure if the workload makes a difference. We would have to make examples of what Computation1 is and what Computation2 is to make a prediction if certain types of workloads will impact the ratio of their performance. Example: s=performance.now(); r=0; for (i=0; i<1000000; i++) r+=1; t1=performance.now()-s; s=performance.now(); r=0; for (i=0; i<1000000; i++) r+="bladibla".match(/bla/)[0].length; t2=performance.now()-s; console.log("Ratio: " + t2/t1); For me, the ratio is consistently larger in Chrome than in Firefox. Which workload would reverse that?
- littlestymaar 3y agoFingerprinting in the usual sense the term isn't about distinguishing Chrome from Firefox, it's about distinguishing user A from user B, … user X reliably in order to be able to track the user across website and navigation sessions. Your example is unlikely to get you far. Edit: in a quick test, I got a range between 8 and 49 in Chrome, and between 1.27 and 51 (!) on Firefox, on the same computer, the results are very noisy.
- Timja 3y agoChrome and Firefox here are an example for "Two users who use exactly the same hardware but different software". To distinguish between users between of a larger set, you do more such tests and add them all together. Each test adding a few bits of information. To make the above code more reliable, you can measure the ratio multiple times: https://jsfiddle.net/dov1zqtL/ https://jsfiddle.net/dov1zqtL/ I get 9-10 in Firefox and 3-4 in Chrome very reliably when measuring it 10 times.
- codedokode 3y agoJust put WebGL/WebGPU behind permission and the problem is solved. I don't understand why highly paid Google and Firefox developers cannot understand such a simple idea.
- miohtama 3y agoJust don’t use Chrome. There are plenty of alternative web browsers you can choose that are more privacy oriented. You are not Chrome’s customer unless you pay for it - or you have 100% money back guarantee. Demanding features on free product is never going to go anywhere.
- merlish 3y agoFor a user to correctly answer a permissions dialog, they need to learn programming and read all the source code of the application. To say nothing of the negative effects of permission dialog fatigue. In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer. Asking the user a question they realistically can't answer correctly is not a solution. It's giving up on the problem.
- codedokode 3y agoThey don't need to learn programming. Just write that this technology can be used for displaying 3D graphics and fingerprinting and let user decide whether they take the risk.
- pmontra 3y agoMost of them will say, "I need to see this site, who cares about fingerprints." Some will notice that they're on their screen anyway, a few will know what it's all about. Maybe "it can be used to display 3D graphics and to track you", but I expect that most people will shrug and go on.
- bcrosby95 3y agoYou could maybe display the request in the canvas instead of a popup. If the user can't see it, they'll never say yes.
- mike_hock 3y agoYou can reduce clock precision, which has already been done to mitigate speculative execution attacks. You can delay network requests to prevent the JS from using the server as a more precise clock. In addition to random delays, you can quantize execution times by only responding in 100ms increments, for example. You can do lots of things to mitigate fingerprinting, if not completely prevent it. But then you could also just omit features that have no reason to exist in the first place.
- amelius 3y agoOr everybody can just buy the same (i)Phone :)