Are top websites using WebGL for fingerprinting?
jonatron.github.io
jonatron.github.io
"player-core-variant-....js" is the Javascript video player and it uses WebGL as a way to guess what video format the browser can handle. A lot of the times mobile android devices will say "I can play video X, Y, Z" but when sent a bitstream of Y it fails to decode it. WebGL allows you to get a good indication of the supported hardware features which you can use to guess what the actual underlying hardware decoder is.
This is sadly the state of a lot of "lower end" mobile SoCs. They will pretend to do anything but in reality it just... doesn't.
Consider that virtually all physical locks are trivial to pick by someone who knows how (see youtube.com/lockpickinglawyer), and yet we still use locks. Pickable locks improve security because they increase the cost to the attacker enough that it deters most attacks.
The implementation might be to have your plugin content script wrap the DOM XHR/fetch in a proxy. The proxy runs a predicate on the payload, and if true, lets it go through. The predicate would be something like "No PII", which would also imply that the traffic be unencrypted.
An app could remove the proxy. But it seems to me that most people wouldn't bother. It's also possible that there are other mechanisms, for example a special Plugin IO API that cannot be changed by content scripts.
I’d imagine most people in this thread do or have. Myself included. It’s a pretty massive industry :)
What you’re missing is that whatever you do to remove fingerprints does itself add a unique metric to fingerprint. This is also compounded by how easy, cheap and legal it is to add fingerprinting tech to ones site. Literally the only way to break fingerprinting is if the majority of the web browsing population ran systems that randomised fake responses. But as it stands at the moment, it’s possible to:
1. Identify when a plug-in it overloading a builtin function
2. Identify which users are consistently doing so because so few are and there’s methods of fingerprinting that exist outside of your JS VM.
I don’t have the link to hand but there’s a website that you can visit and it tells you how identifiable you are. I used to think it was possible to hide until I visited that site and then I realised just how many different metrics they collect and how a great many of them are literally impossible to block or rewrite without breaking the website entirely.
It goes into more detail than the EFF link where it breaks down your uniqueness per each metric (and how much entropy each metric adds) as well as giving you an overall uniqueness.
It's a fantastic but also scary resource :)
They are nice resources, but don't get too scared!
Frankly, both are exaggerating a little - e.g. including stuff like browser version numbers which only appear as unique as they do because the time-span they cover is long enough to overlap update cycles (AmIUnique even seems to have it cover the entire history by default??? That's just noise), yet not stable for more than a short period of time. AmIUnique includes the exact referer, which is likely not nearly as useful as that would make it seem.
Then there's stuff like "Upgrade Insecure Requests" and "Do not track", which is likely extremely highly correlated with browser version choice.
Both sites can't really tell you how reliable the identification is, only how unique you are at this moment. And that matters a lot, because if identification is unreliable (i.e. the same person in some metric has multiple distinct fingerprints) the end result is that for reliable overall identification a fingerprinter may need many times as many bits of entropy as a naive estimate might assume, especially if visits are occasionally sparse and thus changes to fingerprints may frequently come all at once.
Clearly over the very short term you are likely uniquely identifiable as a visitor. However, it's less clear how stable that is.
But the solution isn't good per se.
It provides a high level of granularity and it could theoretically provide even more granularity. But its already an advanced tool that an average user will never use.
let UNMASKED_RENDERER_WEBGL = ["ANGLE (AMD Radeon HD 7900 Series Direct3D11 vs_5_0 ps_5_0)",
"ANGLE (Intel(R) HD Graphics 4000 Direct3D11 vs_5_0 ps_5_0)",
"ANGLE (Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0)",
"ANGLE (Intel(R) HD Graphics 520 Direct3D11 vs_5_0 ps_5_0)",
"ANGLE (Intel(R) HD Graphics 530 Direct3D11 vs_5_0 ps_5_0)",
"ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0)",
"ANGLE (NVIDIA GeForce GTX 960 Direct3D11 vs_5_0 ps_5_0)",
"ANGLE (NVIDIA GeForce GTX 1070 Direct3D11 vs_5_0 ps_5_0)",
"ANGLE (NVIDIA GeForce GTX 760 Direct3D11 vs_5_0 ps_5_0)"]
I can imagine that having several typical configs and switching between them at random would help blend in.
You have to be careful with that too. An anti-anti-fingerprinting implementation can record the values and compare them across visits to see whether they stay the same. If they change every few months that's reasonable (eg. changing hardware), but if they change every day or every week there's most certainly spoofing involved.
Maybe an explicit sign of spoofing is even better, it sends a message in a gentle way.
Unspoofing on the server side, if at all possible, would likely be too expensive for whatever gain it might bring.
I feel like going there and telling them to stop following me around.
gl.getParameter = () => "test"
gl.getParameter.toString()
"() => "test""
"function getParameter() { [native code] }"
[1] https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug...
[2] https://palant.info/2020/12/10/how-anti-fingerprinting-exten...
await navigator.storage.estimate() -> gl.getParameter.toString.toString()
<- "() => 'function getParameter() { [native code] }'"
gl.getParameter.toString() = () => 'function getParameter() { [native code] }'
gl.getParameter.toString()
"function getParameter() { [native code] }"
gl.getParameter.toString().toString()
"function getParameter() { [native code] }"
gl.getParameter.toString().toString().toString()
"function getParameter() { [native code] }"
gl.getParameter.toString().toString()
gl.getParameter.toString.toString()
Several others on this list are also not used for fingerprinting, and are instead detecting robots/spam/abuse. Unfortunately, there isn't any technical way for the public to verify that, because client-side all it looks like is collecting a bunch of high-entropy signals.
All the major browsers have said they intend to remove identifying bits to where fingerprinting is not possible, which will also make these other uses stop working.
However that being said it's like fingerprinting to sort out what their system really has. Still an abuse of the system.
If you're interested why this data was exposed in the first place, the MDN docs has good info https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug... . "Generally, the graphics driver information should only be used in edge cases to optimize your WebGL content or to debug GPU problems."
Sadly that's the reality of some of these tools. The intent was good and in many cases they are a necessity to create a web experience that works on every device. On the flip side this allows people to use this data to fingerprint.
This can only be solved with legislation, IMO. There is no way for an industry to self-regulate something like this, the candy bowl too big and the candy too sweet.
Also, ads without personal targeting, much like dead-trees newspaper / magazine ads, could still work and prop up certain web publishers.
That's the only way service providers will see a cent from me going forward. Ads present not only a privacy risk but they're increasingly becoming a security risk too. I will not allow them on any of the devices I own or that connect to my home WiFi.
Blocking scripts and requests by third-party ad networks makes complete sense from security perspective, though.
Affiliate links going directly to relevant item pages in a store are fine by me, too. They have to be relevant for anyone to click on them, they don't play video or make sound, etc. They do give some tracking opportunity, but without third-party cookies and third-party requests, it's hard to achieve anything resembling the privacy-invading precise tracking which current ad networks routinely do.
In any case, I much more prefer the absence of AWS and an honest donation button.
FWIW while I'm playing hardball here I really appreciate your answer and expertise.
There is always a likelihood that data gets used for reasons beyond the original purpose. In the best of world the hardware that runs on consumers devices would do the right thing which would allow the web to be a perfect sandbox. I think we're slowly getting there, in terms of video it's slowly getting to a point where H.264 support is "universally true" rather than a minefield although VP9 and AV1 is a bit of being back to square one.
I think the spirit of my original comment was not to say "I promise that X company isn't doing Y" more to explain why this code existed in the first place. A search engine doesn't need to know what WebGL capabilities a device has as it doesn't deal with rendering whereas a site that has to work with hardware decoders most likely does need to know.
You’re actually just outright accusing them of lying.
It's good to ask the hard questions and even though I'm not able to answer it in detail I still think that 'tmpz22' brought up a good point in that data can be used for both good and bad at the same time.
You need to be able to tell the good from the bad and IMO you're wearing these trousers the wrong way round.
Edit: this is the typical example of a loaded question, not an actual accusation against the parent comment https://en.m.wikipedia.org/wiki/Loaded_question
So when did you stop beating your wife?
So the problem here is a bit different. It's not that devices will say "I can play Format X" and then not play it. It's that devices say "I can play Format X at Resolution A, B, C". When you give the device resolution A and B it succeeds but at resolution C it fails to decode it.
In H.264 this would be the "Level" https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels . A device may say that it can decode Level 4.2 but in reality it can only do 4.1. That means it can play back 1080p30 but not 1080p60. The only way to know is to actually try and observe the failure (which often btw is a silent failure fro m the browsers point of view, meaning you need to rely on user reports).
The issue here is the architectural difference between the hardware decoder and the GPU. What happens under the hood with MSE ( https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...) is that you are responsible for handing off a buffer to the hardware decoder as a bitstream. Underneath, the GPU sets up a texture and sends the bitstream to the hardware decoder that's responsible for painting the decoded video into that texture.
What often ends up happening is that the GPU driver says "yes the hardware decoder can do this", it accepts the bitstream, sets up the texture for you which is bound against your canvas in HTML. Starts playing the video, moves the timeline playhead but the actual buffer is just an empty black texture. From the software's point of view, the pipeline is doing what it's supposed, due to the hardware decoder being a black box from the Javascript perspective it's impossible to know if it "actually" worked. Good decoders will throw errors or refuse to advance the PTS, bad decoders won't.
Knowing this, your second suggestion was to read back the canvas and detect video. That would work but the problem here is "what constitutes working video". We can detect if the video is just a black box but what if the video plays back but at 1 frame per second, or plays back with the wrong colors. It's impossible to know without knowing the exact source content, a luxury that a UGC platform like Twitch does not have.
For this reason just doing heuristics with WebGL is often the "best" path to detecting bad actors when it comes to decoders.
At worst it seems like you'd need to do this once per format per user per device but only if that user hasn't already had the test for that video size/format. (save a cookie/indexed-db/local-storage that their device supports that format) so after that only new sizes and formats need to be checked.
Just an idea. No idea if what problems would crop up
I think it's a beautiful, legitimate use — but I can't fault the author for labeling fingerprinting.
My view is that fingerprinting is a set of tools which can be used for "good or evil" if that makes sense. If you are gathering meta-data to determine the capabilities of the device, then this is part of the wider framework of data points which can, in principle, be used for fingerprinting a user. This data can be imported into a completely different system by a sophisticated adversary, so it needs to be treated as a security vector, imho
Pedantic point, so forgive me, but 100% uniquely identifying a device does not imply 100% uniquely identifying the user of the device. We call them User-Agents for a reason. Anyone could be using it.
It's critical people not fall into the habit of conflating users and user-agents. Two completely different things, and increasingly, law enforcement has gotten more and more gung-ho about surreptitiously forgetting the difference.
Ad networks and device/User-Agent based surveillance only makes it worse.
There are several initiatives to implement UUID's for devices. There is the Android Advertising ID, systemD's machine-id file, Intel burns in a unique identifier into every CPU.
IPv6 (without address randomization) would also work as a poor man's UUID.
It's frighteningly easy, and you'll be surprised how unintentionally one can be implementing something seemingly innocent and end up furthering the purposes of those seeking to surveil.
- look at the statistical behavior of how they operate the mouse
- estimate their reading speed based on their scrolling
- for mobile devices, use the IMU to fingerprint their walking gait and angle at which they hold the phone (IMU needs no permissions)
- measure how the IMU responds at the exact moment a touch event occurs. this tells you a quite a bit about how they hold their phone
- if they ever accidentally drop their phone, use the IMU to detect that and measure the fall time, which tells you the distance from the ground to the height they held the phone. then assuming the phone is held normal to the eyes, you can use the angle they held the phone to extrapolate the location of the eyes and estimate the user's approximate height
The level of noise is incredibly problematic. My leading cause of dropped phone, for instance is forgetting I have it in my shirt pocket, on my lap, off my desk, or from my back pocket if I don't put it in just right. Am I a different person in each of those circumstances? The statistical answer would be no, but only cones from widening the scope of collected data. Suppose I fiddle with it? Dance with it? Have a habit of leaving it in a car? Without a control, you have a different set of relative patterns. At best you know there is a user with X. Yes you can make some statistical assumptions, but at best, when it really counts, it still needs to line up with a hell of a lot of other circumstantial datapoints to hold water.
Furthermore, I guarantee not a single person would dare make any high impact assumption based on that metadata given that once it gets out, it's so adversarially exploitable it isn't even funny. Imagine a phone unlock you could do just by changing your gait. Or worse, a phone that locks the moment you get a cramp or blister. Madness. Getting different ads because you started walking like someone else for a bit. Do I become a different person because I try to read something without my glasses, or dwell on a passage to re-read it several times? Or blaze through a section because I already know where it is going? These are not slam dunk "fingerprints" by a long shot. More like corraborating data than anything else, and in that sense, even more dangerous, because people are not at all naturally inclined to look at these things with a sense of perspective. It can lead a group of non-data-savvy folks to thinking there is a much cleaner tighter case than there necessarily is, and on top of that, mandates that people be okay with the gathering of that data in the first place, which has only been acceptable up until now because there was no social imperative to disclose that collection.
Going off on a tangent here, so I'll close with the following.
There is the argument to be made that that exact kind of practice is why defensive software analysis should be taught as a matter of basic existence nowadays. If I find symbols that line up with libraries or namespaces that access those resources, why should I be running that software in the first place?
I can't overstate how over 90% of software I come across I won't even recommend anymore without digging into it anymore. There's just too much willingness to spread data around and repurpose it for revenue extraction. It does more harm than good. What people don't know can most certainly hurt them, and software is a goldmine for creating profitable information asymmetries.
Oh, but all of these can be added to your statistical model and learned over time! If we figure out that you suddenly walk with a limp, and all the other metrics match, we can recommend painkillers! Or if the other metrics match and you start dancing, we start recommending dance instructors! Hell, we can even figure out how well you dance using the IMU and recommend classes of the appropriate skill level.
For a recommendation system, like ads, the consequences of mis-indentification wouldn't be that high either. You'd still target much better than random, which is the alternative in the absence of fingerprinting.
The same is true of humans, by the way. Even something as innocuous as surname, gender, and county of residence could be enough.
There is zero evidence any of these are being used for fingerprinting, which is defined as building up an entire set of capabilities to uniquely identify a user.
Essentially all of these seem to be attempting to identify the graphics card, and all of these could be related to feature detection for an embedded video player, for example. Feature detection is not fingerprinting.
Fingerprinting is pretty easy to confirm, because it collects a large combination of data points (fonts installed, canvas rendering quirks, etc.) and either reports or hashes them all together. (That doesn't mean it's easy to find the code that does the fingerprinting, but once you've found it it's quite obvious what it's doing.)
It is deeply irresponsible and misleading of the author to claim fingerprinting without looking for that type of combination. And slapping "No claims made about accuracy" at the top of the page isn't an excuse.
I agree the OP's analysis itself is a bit shallow, but I don't see how that can be related. If you embed a video and do not do anything with its output then WebGL is simply unrelated. In fact most of websites in question do not seem to use WebGL visibly. That fact combined with a direct check for WEBGL_debug_renderer_info and so on should flag a suspicion. Explicit alternative explanations would be needed to prove innocence.
So that's how they're related.
And let's not assume guilt and then require proving innocence? It works the other way around. It's the burden of the person making the accusation to form a strong case. Which is not done here at all.
I still believe that the presumption of innocence should not apply in this case, because fingerprinting is already close to guilty (if you don't agree to this premise there is no point for further discussion, so please refrain from arguing against this specific point). You are right that feature detection is not fingerprinting but they are virtually indistinguishable; given how widespread fingerprinting has been, it was enough to suspect so.
You could take literally any line of code and make an unfounded claim. "It calculates a hash, and fingerprints use hashes!" "It stores a variable, and analytics uses variables!"
It's on the burden of the person making an accusation of bad behavior to actually demonstrate that. Otherwise it's no different from me declaring you're an evil hacker because you comment on Hacker News, guilty until proven innocent.
The null hypothesis determines the "unfounded claim". For example, judicially, the null hypothesis is, "You are innocent until proven guilty in a court of law." Similarly, commercially, the null hypothesis is, "If it's profitable and mostly legal, corporations will compete to do it better."
Fingerprinting is both profitable and legal. It is so profitable and so legal that today's most dominant corporations, entities representing trillions of dollars of value, are founded on its premise.
The "unfounded claim", therefore, is yours. Or do you have any evidence that you are not being surveilled?
I worked on finding ways around fingerprinting at a previous job. The problem is that sites go out of their way to hide fingerprinting like performing it in an arbitrary redirect and then never do it again or only after using the site for a bit, and prefer doing it before an important operation like making a payment.
I've seen a script that performed two canvas fingerprints - a complex, and a simpler one. The latter being so simple always returned the same value regardless of the browser, so it was there to see if you have altered the canvas value. That's why changing your fingerprint might still leave you trackable.
Not sure if I exactly understand what you're trying to say here, but the Tor Browser itself certainly focuses on making its users' fingerprints identical. At least it's the only browser I know of that passes fingerprint tests (Panopticlick and friends) with JavaScript enabled.
Privacy does only exist if you seem to look exactly like any other person visiting the website.
That is why user agent, web apis, asset loading order and behaviours, http stack behaviours, tcp fingerprints all have to look like they came from the Browser Engine you're trying to identify with.
If you don't, you're watched. It's as simple as that. Don't kid yourself into safety if you think that the Content-Security-Policy hack of adblockers work to prevent tracking and fingerprinting. Sure, you send less data, but less data means more obvious than the norm.
As there was not a single concept that could fix this (in regards to looking like another Browser) I started to build my own "web filtering browser" [1] that is able to emulate fingerprinting, and sticks them to specific domains and their originating uncached CDN requests so that if you have the same IP for the same website, they cannot correlate it to ptevious visits.
The most effective way to not get tracked is to not visit the website. And I think that there's a huge potential in offloading traffic to peers that have the same URL already in their caches. Peer-to-peer Browser Caches would fix so many issues on their own, I don't understand why nobody is doing that. To the end user it doesn't matter where the assets come from, as long as the website is rendered in the same way afterwards.
Almost none of the web breaks simply because you're using a (very well known, very old) VPN IP. Purchases using a credit card are pretty much the only thing that is likely to get blocked. And you face a few more captchas sometimes.
Do algorithmic traders need to use something on the web that blocks VPN IPs more aggressively than this? They must, because juggling all those SIM cards sounds like a huge headache, and cell phone data has awful latency. I'm wondering what they're scraping that the average person doesn't use, and why they want to look like an average person if that's the case.
The issue that arises is mostly cloudflare-related, due to them having a huge influence on hosting, and the forced recaptchas when they detect anomalies in traffic behaviour makes a web scraping workflow real shitty.
From an algotrader's point of view it's a fix to make their web scrapers work again. I'm not sure how Chrome/ium headless could fix this (if it could). I'm a bit sceptical as it's just yet another cat and mouse game.
But as of late I've seen a huge scene start to develop around extension-building for headless Chrome specifically, so that they can run headless and still get the data as they want it to by integrating a content script that sends the data to another service.
FWIW, it takes very little effort to completely conceal the fact that firefox is running headless under marionette/webdriver/geckodriver. Chrom(ium) takes more effort, but these guys have solved it (and built a business around it):
https://intoli.com/blog/making-chrome-headless-undetectable/
https://github.com/intoli/remote-browser
Of course neither of these address fingerprinting -- all your scrape requests will have the same or similar fingerprint, which will lead to captchas pretty quickly. This might help (and might even be part of the reason for buying piles of cellphones):
In my case I'm using existing TLS infrastructure so that each peer can use their own certificates to communicate with other peers directly.
So far, the only things which haven't reported my graphics card to me are the Tor browser (good), KHTML (good, but probably because it doesn't support WebGL), and Lynx (of course, no js). Firefox reported much less info than Chrome did.
[1] https://www.ghacks.net/2017/10/28/firefox-58-warns-you-if-si...
Most not technical users have no basis for action here.
Also Google runs the browser standards by way of their Chrome market share, and they would surely never implement something like this until they were confident that they didn't need WebGL for fingerprinting, at which point they'd just stop supporting WebGL entirely in favor of something that they invented.
It's not Embrace Extend Extinguish with Google; it's more like Embrace Replace Extinguish.
Test your browser here FIRST, then disable and test again: https://testdrive-archive.azurewebsites.net/graphics/webglst...
I've had webgl disabled for almost two years now because I don't find that webgl provides no benefit that I care about, yet lets websites slow down my laptop and drain my battery.
I disabled wasm a few months ago for the same reason.
You are welcome to join my cohort!
It's frequently included in "secure yourself" tuning guides: Firefox -> about:config -> webgl.disabled: true
The privacy policy of the website doesn't mention this technique, which effectively is a replacement for cookies, nor the use of any of Akamai's services. It even CNAMEs Akamai.
So basically Akamai's service is left out of this list for no reason at all.
I stumbled upon this while trying to automate the querying for available slots to get notified via email, and one of the POST calls was sending my graphics card model to the server.
EDIT: Safari and Chrome got the same prints on both machines, FireFox got two different prints. Huh?
edit - addon faq says it injects fake values
You can test its effectiveness here — https://coveryourtracks.eff.org/
It might work for simple fingerprinting scripts, but not for anti-anti-fingerprinting scripts. See: https://palant.info/2020/12/10/how-anti-fingerprinting-exten.... Since you're already on firefox, you're probably better off enabling resistfingerprinting instead.
gl.getParameter.toString()
"function () {
window.top.postMessage(\"webgl-fingerprint-defender-alert\", '*');
//
if (arguments[0] === 3415) return 0;
else if (arguments[0] === 3414) return 24;
else if (arguments[0] === 36348) return 30;
else if (arguments[0] === 7936) return \"WebKit\";
else if (arguments[0] === 37445) return \"Google Inc.\";
else if (arguments[0] === 7937) return \"WebKit WebGL\";
else if (arguments[0] === 3379) return config.random.number([14, 15]);
else if (arguments[0] === 36347) return config.random.number([12, 13]);
else if (arguments[0] === 34076) return config.random.number([14, 15]);
else if (arguments[0] === 34024) return config.random.number([14, 15]);
else if (arguments[0] === 3386) return config.random.int([13, 14, 15]);
else if (arguments[0] === 3413) return config.random.number([1, 2, 3, 4]);
else if (arguments[0] === 3412) return config.random.number([1, 2, 3, 4]);
else if (arguments[0] === 3411) return config.random.number([1, 2, 3, 4]);
else if (arguments[0] === 3410) return config.random.number([1, 2, 3, 4]);
else if (arguments[0] === 34047) return config.random.number([1, 2, 3, 4]);
else if (arguments[0] === 34930) return config.random.number([1, 2, 3, 4]);
else if (arguments[0] === 34921) return config.random.number([1, 2, 3, 4]);
else if (arguments[0] === 35660) return config.random.number([1, 2, 3, 4]);
else if (arguments[0] === 35661) return config.random.number([4, 5, 6, 7, 8]);
else if (arguments[0] === 36349) return config.random.number([10, 11, 12, 13]);
else if (arguments[0] === 33902) return config.random.float([0, 10, 11, 12, 13]);
else if (arguments[0] === 33901) return config.random.float([0, 10, 11, 12, 13]);
else if (arguments[0] === 37446) return config.random.item([\"Graphics\", \"HD Graphics\", \"Intel(R) HD Graphics\"]);
else if (arguments[0] === 7938) return config.random.item([\"WebGL 1.0\", \"WebGL 1.0 (OpenGL)\", \"WebGL 1.0 (OpenGL Chromium)\"]);
else if (arguments[0] === 35724) return config.random.item([\"WebGL\", \"WebGL GLSL\", \"WebGL GLSL ES\", \"WebGL GLSL ES (OpenGL Chromium\"]);
//
return getParameter.apply(this, arguments);
}"
"function getParameter() {
[native code]
}"This will probably help with security as well, there has been a fair share of webgl exploits as well.
Also from a "user privacy" point of view, this is still OK. Right now, disabling webgl is so rare it makes the user stand out a lot, and can be used as a tracking signal. Also, websites do not expect this to be disabled, and can break.
But if a non-trivial fraction of the users (say 10%) start refusing WebGL, then websites have to keep working without it; and the fact that it is disabled can no longer be used as tracking indicator.
1. Pend the request 2. Notify the user "This site wants access to the WebGL graphics API to display complex graphics. This is disabled by default to prevent browser fingerprinting. If the site fails to work properly, click the lock icon and allow it." 3. Deny access until the user explicitly enables it on a temporary or permanent basis
More granular browser API permissions would be fantastic, but the current interface for grant/deny in all the major browsers is annoying enough as is. The prompts need to be moved to a less in-your-face place, or at least have the option to be. I almost always find myself clicking "deny" because no, I don't want to give your recipe site permission to show notifications.
Somewhat related is the new "sign in with Google" prompt I've been seeing on lots of websites. I accidentally clicked it when visiting the Seattle Times website and have been working inundated with spam emails even after clicking unsubscribe.
One example I know well is AudioContext fingerprinting with a demo available here: https://audiofingerprint.openwpm.com/
There are also worse fingerprinting methods that work cross-browsers.
https://github.com/WebAudio/web-audio-api/issues/1500#issuec...
https://github.com/w3cping/tracking-issues/issues/53#issueco...
WebGL fingerprinting usually works by rendering something off-screen that exposes GPU differences, then captures the rendered image as the fingerprint.
Browser fingerprinting is the ability of the website you are accessing to differentiate between you and other people because of a "fingerprint": A hash string that uniquely identifies your current browser, and since its using WebGL, your computer, because of its configuration and graphical capabilities.
See e.g.https://webkit.org/tracking-prevention/#anti-fingerprinting (Mozilla's positions are more spread out over various issues, see e.g. https://webapicontroversy.com )
And this is a huge problem.
> and Apple naturally would rather developers to use iOS APIs
You're missing the point where Firefox agrees with Apple on these APIs.
But sure. "Apple bad" and all that.
My point was that contrary to Mozilla, they do have an agenda regarding how much Web Safari should support on iOS.
What does it mean to sandbox shaders in this context ? GL ES shaders are sent down in a high level language and can't really do much besides do computation on input parameters to generate output in a pipeline. I wish they were more general purpose and worthy of sandboxing but the web GL shaders are really limited.
Second one is about running a bitcoin miner on the GPU, hypothetical memory breaches, and GPU DoS. You can stall the graphics pipeline without shaders, run a miner on CPU, and I'm going to need a demonstration of a usefull GPU memory breach with WebGL. On top of that any such breach is likely driver dependent and will only work on some specific driver/HW combination - that's such a low attack surface I doubt anyone will bother developing exploits targeting that.
I didn't bother going through third because I wasted enough time on first and second, I don't see how anything here suggest you need to sandbox shaders.
https://chromium.googlesource.com/angle/angle/+/master/READM...
[Source: I worked on the original spec and spent a lot of time trying to prevent the more egregious security and privacy problems]
https://news.softpedia.com/news/The-PS4-UI-Is-Built-Using-We...
The only effort to do any GL like stuff was on the PS2, with GL ES 1.0 + Cg, an effort that was dropped when almost no dev cared to use it.
Other than that there was the PSGL library for PS2 Linux.
Anyway, I did a bit more research and Chrome was actually only used for development purposes, they created their own WebGL engine on top of PhyreEngine for the console OS.
What would those be?
In the UK, gambling companies use fingerprinting to enforce exclusion lists (i.e. gambling addicts who self-exclude from gambling websites), and stop people from outside the UK gambling illegally (the latter is used generally, although desktop apps are generally more secure).
I believe it is also used in online retail to combat bots (self-evidently, not everyone is doing this).
I think it is a concern when websites use this kind of thing indiscriminately. I have worked in web development roles, and I have had devs tell me point blank (once, a lead dev) that fingerprinting is impossible whilst using products that expose their customers to fingerprinting...so it is important to be aware of it. But there are legitimate uses to fingerprinting specifically, exclusive of the APIs that some apps rely on certain features (i.e. WebGL). It is sometimes important to know who someone is.
I actually rarely have to enable JS on pages now. Most JS-only sites can be find in places like https://news.ycombinator.com/show where people showcase JS-only sites / apps. Most are innocuous enough and are not trying to track you though, so I sometimes turn on JS just to test them out. I have a dedicated laptop for Youtube, Reddit etc. I'm well aware that sites like Reddit track you via JS, so I compartment / silo sites like that with a dedicated machine.
Which can be addressed with a VPN. By insulating an IP away from other IPs you can stop IP correlation.
But VPN do migrate the problem.
https://www.researchgate.net/figure/Network-level-DNS-Finger...
https://securitytrails.com/blog/cybersecurity-fingerprinting
Is this the kind of tactic you mean?
Maybe I haven't thought of every situation but don't you want to be able to prevent odd behavior to an account?
"WebGL is used for fingerprinting on most major websites"
But if we wanted to create click bait:
"Most major website implement browser fingerprinting that completely disregard VPNs and the Browser's Incognito Mode"
But I bet VPN companies wouldn't like that.
since when the hell did Google an American corporation become the arbitrator of morality and truths?
This fingerprinting is closely tied to this. The sad part is that the web scraping technology that I've been invited access to easily bypasses this.