8 ms·
In case you confused this with webgl as I did: > WebGPU is a new API for the web, which exposes modern hardware capabilities and allows rendering and computati
by teruakohatu 4y ago
In case you confused this with webgl as I did:
> WebGPU is a new API for the web, which exposes modern hardware capabilities and allows rendering and computation operations on a GPU, similar to Direct3D 12, Metal, and Vulkan. Unlike the WebGL family of APIs, WebGPU offers access to more advanced GPU features and provides first-class support for general computations on the GPU.
- mike_hock 4y agoAnd to prevent device fingerprinting, all the operations are specified to deterministically produce the same bit-exact results on all hardware, and the feature set is fixed without any support for extensions, right? Or is this yet another information leak anti-feature that we need to disable?
- Timja 4y agoThere 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 4y agoIt's possible to have the runtime execute the computations in fixed time across platforms.
- foldr 4y 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 4y 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 4y 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 4y 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).
- jeffparsons 4y 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 4y 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 4y agoThe solution is to put unncesessary features like WebGL, programmatic Audio API, reading bits from canvas and WebRTC behind a permission.
- azangru 4y agoWho decides what's unnecessary?
- codedokode 4y 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 4y agoSo CSS should be behind a permission?
- codedokode 4y agoCSS should not leak fingerprinting information. After all this is just a set of rules to lay out blocks on the page.
- remexre 4y agohttps://css-tricks.com/css-based-fingerprinting/ https://css-tricks.com/css-based-fingerprinting/
- kevingadd 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.
- merlish 4y 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 4y 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 4y 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 4y 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.
- kevingadd 4y agoThey're going to be confused if you say "display 3D graphics", because canvas and WebGL will still work. The website will just be laggier and burn their battery faster. That's not going to make sense to them. "Fingerprinting" is a better approach to the messaging, but is also going to be confusing since if you take that approach, almost all modern permissions are fingerprinting permissions, so now you have the problem of "okay, this website requires fingerprinting class A but not fingerprinting class B" and we expect an ordinary user to understand that somehow?
- mike_hock 4y 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 4y agoOr everybody can just buy the same (i)Phone :)
- NiekvdMaas 4y agoI'm afraid it's the latter: https://gpuweb.github.io/gpuweb/#privacy-considerations https://gpuweb.github.io/gpuweb/#privacy-considerations
- phh 4y agoSomeone mean would say that this is not a bug, but a feature for the people who are paying for Chrome.
- sebzim4500 4y agoGoogle are the people paying for Chrome, they do not benefit in any way from this kind of fingerprinting. To the contrary, it decreases the value of their browser monopoly.
- illiarian 4y ago> Google are the people paying for Chrome, they do not benefit in any way from this kind of fingerprinting. The largest ad company in the world 80% of whose money comes from online advertising does not benefit from tracking...
- foldr 4y agoEven supposing that Google do benefit from it in that manner, there would be far simpler ways for them to make fingerprinting easier. It's extremely unlikely that this is a significant motivation for adding WebGPU. Not to mention that a lot of the fingerprinting you can potentially do with WebGPU can already be done with WebGL.
- pl90087 4y agoI wish all information-leaky browser features were turned off by default and I could easily turn them on on demand when needed. Like, the browser could detect that a webpage accesses one of them and tells me that I am currently experiencing a degraded experience which I could improve by turning this slider on.
- tormeh 4y agoI believe the LibreWolf browser does this. It's basically Firefox with all the fingerprintable features turned off.
- jeroenhd 4y agoI've set up my Firefox with resistFingerprinting but without an auto deny on canvas access. It's sickening to see how often web pages still profile you, but the setting seems to work. Similarly, on Android there's a Chromium fork called Bromite that shows JIT, WebRTC, and WebGL as separate permissions, denied by default. I only use it for when broken websites don't work right on Firefox, but websites seem to function fine without all those permissions being enabled by default. Competent websites will tell you the necessary settings ("WebGL is not available") so making the websites work isn't much trouble. I'd much rather see those error messages than getting a "turn on canvas fingerprinting for a better experience" popup from my browser every time I try to visit blogs or news websites.
- pl90087 4y agoRight. But I don't want to have to dig into settings hierarchies for those knobs. The threashold for that is too high and almost nobody will bother and do that. Something easier with simple sliders would be much better.
- indy 4y agoThe trade-off for extracting maximum performance from a user's hardware is that it becomes much easier to fingerprint. Judging by the history of the web this is a trade-off that probably isn't worth making.
- nextaccountic 4y ago> all the operations are specified to deterministically produce the same bit-exact results on all hardware, I want this so badly. A compiler flag perhaps, that enables running the same program with the exact output bit for bit on any platform, perhaps by doing the same thing as a reference platform (any will do), even if it has a performance penalty.
- pjc50 4y agoI'm surprised people accept non-bit-identical output. Intel did a lot of damage here with their wacky 80-bit floating point implementation, but really it should be the norm for all languages.
- geysersam 4y agoWhy would I want bit-identical output? Genuinely curious. I see there's some increase in confidence perhaps, although the result can still be deterministically wrong...
- pjc50 4y agoIt's very hard to do tests of the form assert(result == expected) if they're not identical every time. And it can waste a horrendous amount of time if something is non-bit-identical only on a customer machine and not when you try to reproduce it ...
- dahart 4y agoTrying to reproduce is a good point, but at the same time it’s usually a pretty bad idea to do tests of the form assert(result == expected) with a floating point result though. You’re just asking for trouble in all but the simplest of cases. Tests with floating point should typically allow for LSB rounding differences, or use an epsilon or explicit tolerance knob. There’s absolutely no guarantee that a computation will be bit-identical even if the hardware primitives are, unless you use exactly the same instructions in exactly the same order. Order of operations matters, therefore valid code optimizations can change your results. Plus you’ll rule out hardware that can produce more accurate results than other hardware if we demand everything be bit-identical always, it will hold us back or even regress. Hardware with FMA units are an example that produce different results than using MUL and ADD instructions, and the FMA is preferred, but hardware without FMA cannot match it. There are more options for similar kinds of hardware improvements in the future.
- bhouston 4y agoI track population frequency of WebGPU extensions/limits here: https://web3dsurvey.com https://web3dsurvey.com. The situation currently is much better when WebGL1/WebGL2 but there is still a lot of surface area.
- codedokode 4y agoInteresting. The data shows that WEBGL_debug_rendered_info [1] which allows sites to know the name of your graphic card, is supported almost in 100% of browsers. Seems that better fingerprinting support is really a priority among all browser vendors. [1] https://web3dsurvey.com/webgl/extensions/WEBGL_debug_renderer_info https://web3dsurvey.com/webgl/extensions/WEBGL_debug_rendere...
- kevingadd 4y agoThis is sadly a requirement for the time-honored game development tradition of "work around all the bugs in end user drivers", which also applied to WebGL while it was still immature. At this point there's probably no excuse for continuing to expose that info though, since everyone* just uses ANGLE or intentionally offers a bad experience anyway.
- simion314 4y agoAs long you can keep it off or turn it off then I think this is a good option to have. I too would prefer to have the Web split into 2 parts, documents and apps , then I could have a browser that optimizes for JS , GPU speed and a simple safe browser for reading Wikipedia and articles. I am sure there will be browsers that will not support this or keep it off so at worst you need to give up on Chrome and use a privacy friendly browser.
- miohtama 4y agoThe easiest option to prevent fingerprinting is to disable WebGPU. Or even better, which is already the option for many today, use one of privacy focused web browsers instead of Chrome. Meanwhile there is a large audience who will benefit from WebGPU features e.g. gamers and this audience is in the numbers of hundreds of millions.
- nashashmi 4y agoFingerprinting is a very difficult and unreliable way of identifying users. You would not bank on fingerprinting to protect your money. You cannot bank on it to protect user info. You can just wish that you are targeting the right person.
- fsloth 4y ago"..all the operations are specified to deterministically produce the same bit-exact results on all hardware..." You have to block floating point calculations as well if that is your intent.
- kevingadd 4y agoThe animals already fled the barn on that one, WebAssembly floating point is not specified to be bit-exact, so you can use WASM FP as a fingerprinting measure (theoretically - I don't know under which configurations it would actually vary.)
- yazzku 4y agoIt's the latter.
- marktangotango 4y agoSo someone can put javascript in a page to compute equihash, autolykos, cuckoo cycle, etc? Is there a way to limit this?
- dagmx 4y agoThey could already do that though?
- marktangotango 4y agoBut not using the client side gpu!
- JayStavis 4y agoI believe webGL "cryptojacking" as it's called, indeed is a thing. Not sure on prevalence though or to what extent this introduction makes it more viable for malicious actors. I'm not sure if lots of hashing algos are gpu-ready or optimized either.
- hinell 4y agoSadly all of this comes at cost of necessaty to lear new webgl and new API whic isn't good. I would expect to have something similar to a Vulkan one. This is not good.