What's a charitable reason that stops even a supposedly privacy-concerned niche browser like Brave from implementing opt-ins for these things?
I suppose one reason is that you would immediately unleash opt-in spam on your users that don't know what these pop-ups mean since so many major websites use these hacks, so the average user is just going to be conditioned to mindlessly click "Allow All" every time they pop up like UAC on Windows Vista, punishing the average person while doing nothing to enhance their security.
Doesn't help that legislators are absolutely clueless here. For example, demonizing cookies when cookies are the most fair and transparent way to implement tracking, and leading to the first wave of pointless opt-in spam that plagues the internet. I'd rather they leave the internet alone and for browser vendors to step up for us.
Of course, the problem also includes native apps like in TFA. I'm just more optimistic about clients that run in web browsers.
It would be nice if the settings inside resistFingerprinting were configurable. I understand that the point of it is to make every browser look the same to analytics engine, but having timezones and zoom levels reset is not the best thing.
Not sure about the status of AudioContext tracking, though.
- for web, stop using chrome, install firefox (or firefox mobile) and in about:config set privacy.resistFingerprinting on true then add following addons:
https://addons.mozilla.org/en-US/android/addon/canvas-finger...
https://addons.mozilla.org/en-US/android/addon/audioctx-fing...
https://addons.mozilla.org/en-US/android/addon/webgl-fingerp...
https://addons.mozilla.org/en-US/android/addon/font-fingerpr...
They will not only prevent fingerprints but also screw with the data (add random noise to audio/webgl sample, return random fonts,...).
- the most important rule, don't use applications like tiktok, fb,.. if your phone is not rooted, with xprivacylua (https://github.com/M66B/XPrivacyLua, for added kicks https://github.com/M66B/NetGuard) installed and you have basic understanding what you allow there (disallow everything for new apps and work permissions one by one). The sole purpose of those apps and their bussiness model is to steal your data. This is most sane advice I can give, sorry :(
Voila. Solved.
Those methods of fingerprinting are few years old and well known.
In my experience, blocking these everywhere globally as a default will result in being banned from websites, trigger bullshit "fraud" invasive analytics, and all sorts of obnoxious fail-closed problems by invasive trackers.
You will also be banned from most Distil-hosted sites for refusing to enable WebGL or return a canvas fingerprint. Ticketmaster, etc.
Be the change you want to see. Do it. I'm always amazed at how people will complain but then let themselves be pushed around. I wonder how many people reading this article will change their or their browser's behaviour afterwards. Very few I guess.
The EU (via GDPR) made a collective decision to disallow invasive privacy, if TickTock's response to that is to ban everyone in the EU and entirely lose the market that sounds good to me - teenagers will complain and people will shrug.
I personally have EasyPrivacy enabled on uBlock (because these tracking scripts using canvas, webgl, etc spin up my GPU and absolutely shit all over my battery life) but they are getting more and more aggressive with first-party CNAMEs, shipping a list of dozens or hundreds of hostnames to try progressively if any are blocked (and probably honestly risk score you higher for "trying to evade them" even though it's a default uBlock list).
I think it's honestly rather stupid, and I am not a fan of hearing my fans spin up for no reason accessing an otherwise plain website while it tries to open media players, try video elements, draw to canvas, download several megabytes of obfuscated garbage to evaluate.
You missed it, this doesn't require an Allow, because it's not actually accessing the microphone. It's using the audio APIs to generate a waveform, and depending on your computer/DSP, the waveform will be slightly different. It's not using any of your computers sensors
Presumably, without an allow the API doesn't function at all, so it works perfectly well. When denied access, the API should either not exist, or (more appropriately) just return errors.
An incorrect presumption. The API works perfectly fine without the need for permissions.
This is not a new technique. There's a decent write up here [0].
Permissions are only required to play to the actual device, or record from the actual device. Recording from nothing and not playing is allowed.
"This website has asked for permission to use the Audio API. If they aren't actively doing audio processing, this may be an attempt to identify and track you. If you haven't been presented by the site with a good reason why to allow this access, and it's not immediately obvious (such as for a music service), consider whether you want them to have access."
This accomplishes a few things. First, it's very clear about the implications and when it's obvious it should be allowed. Second, it gently suggests the default behavior for people should be to deny unless needed. Thirdly, it communicates to sites (through users the appropriate way to ask for permissions if hey have a legitimate reason, which is to let users know why they need access. Lastly, if sites lie to users about why they need access, they can be called out on that. People don't like being lied to.
That'd require rewriting the API itself.
If you visit a random internet site and get a prompt for the audio API are you going to allow it? Probably not, especially if you think it's just so the site can be obnoxious with sounds or listen to you.
The canvas api might be a little more likely to be allowed by the average person, but enough might disallow or ask about it that sites that have a valid use for it will put up a banner noting why it's important, making sites using it for tracking stand out all the more.
The bottom line is that we're coming to an understanding (well, it's been known for years) that each additional browser feature has downsides, so making them enabled by default has repercussions.
Those dialogs and settings are controlled by the Permissions API today.
> If you visit a random internet site and get a prompt for the audio API are you going to allow it? Probably not, especially if you think it's just so the site can be obnoxious with sounds or listen to you.
You and I might disable it. Overwhelmingly, the majority of the public click "enable" or "yes" on permission pop-ups. And tend to make sure "enable forever" is ticked.
> The bottom line is that we're coming to an understanding (well, it's been known for years) that each additional browser feature has downsides, so making them enabled by default has repercussions.
I don't disagree. The problem here is that the permission model itself has been broken, and won't be repaired because of backwards compatibility, and a lack of incentive.
You're a world-leading computerist and you had no clue either (nor I), how in the world are legislators supposed to do this. It's a fundamental problem. And once it's finally legislated the sme's are already on the next thing.
If you want that stuff you use Firefox and enable resistFingerprinting its the only possible way
The problem is that it used to be good enough to block "known-bad" IPs but now with AWS and cloud services it's very easy for cybercriminals to get around IP blocks.
For normal users, tracking can be done with cookies, so fingerprinting isn't really needed for normal users anyways (not entirely true if you're a totally bad actor, which is why browsers have been trying to block some of the more common ways to fingerprint).
But for a script that spawns a thousand AWS instances to sign up 1000 bot accounts that can then be used to sell likes for example, it's pretty easy to tell that it's a script instance because all of them will behave in almost exactly the same way (processor performance, installed plugins, reported screen size, etc. etc.).
An "alternative" to using fingerprints would be to use captchas instead, but bots have gotten much much better at solving captchas. So in fact, ReCaptcha will also use a number of fingerprinting techniques, which is why in many cases you can just click the check box instead of solving a captcha.
Processor performance is variable based on the particular instance you are running on and how much load it is handling. At least at the level the remote side can see.
Screen size is easily configured and/or randomized to some degree, or shifted between 10-20 common values.
Plugins reported or actually allowed to run can be changed per instance.
All this stuff is trivial with headless chrome and puppeteer, and even abstracted away using the stealth plugin for puppeteer[1]. And headless firefox through puppeteer is experimental
All this fingerprinting is ridiculous and trivial for someone with any incentive to do so to defeat.
1: https://www.npmjs.com/package/puppeteer-extra-plugin-stealth
I don't want my browser to keep changing its screen size.
> All this fingerprinting is ridiculous and trivial for someone with any incentive to do so to defeat.
I disagree. There are a number of efforts to defeat fingerprinting underway already and I think the fact that they haven't been able to eliminate it says volumes about how difficult of a problem this is.
Neither do I. I'm taking about how useless it is to use these metrics to identify bots, sine any bot can easily circumvent them, and with far more less hassle than a user.
The fingerprinting is "for" fraud, but is not very useful in that context. The fallout is that all our privacy is worse though.
> I disagree ... the fact that they haven't been able to eliminate it
They haven't eliminated it because it still works well enough on end users, even though the narrative is that it's to prevent fraud.
Fingerprinting works for users, but for any halfway competent adversary it's close to useless. Just keep that in mind when it's brought up as a solution to fraud and that's why it's worth allowing.
They do prevent manually resizing the window because the exact width could be used to rack you across sites in the same windows.
We all, as end users, pay for this because as an end user it's much more onerous to work around because site specific tweaks to make a site work require a lot of effort.
AFAIK browser fingerprinting (eg: Fingerprintjs2[0]) at least is nothing like fingerprints at all. It's not accurate and cannot identify a specific person. For websites like TikTok, the same fingerprint might points to 10k different people, instead of an individual. A most common use case is like 'Remember me' option when logging in if they haven't switched their device, but they actually can find other devices that have the same fingerprint.
For example, the most widely used library Fingerprintjs2 uses all the factors that can be grab from the browser (Browser agent, CPU, OS, resolution, etc), and generate a hash from those factors. Even their 'pro' version can only claim 99.5% accuracy, though I doubt the number is actually even lower. For 1M people userbase, it's 5000 people for 0.5% of the population.
Seems obvious once you read how it works. I suppose once you get your mind around how browsers leak and/or persist info, not much of it is surprising anymore.
if (navigator.mediaDevices) navigator.mediaDevices.enumerateDevices = undefined;
userscript will kill audio fingerprinting, and in many cases just crash fingerprinting scriptEven with CanvasBlocker the "check your fingerprint" sites still show a unique fingerprint (but canvasblocker has a ton of really obscure options that I don't understand)
It always be unique, because it's randomly generated. But every visit will have a completely different unique value, which means that the fingerprint from the canvas is a useless value.
Edit: Perhaps overloading the toDataURL() function to add random noise. https://browserleaks.com/canvas#how-does-it-work
window.HTMLCanvasElement.prototype.toDataURL = undefined;
window.CanvasRenderingContext2D.prototype.getImageData = undefined;
kills canvas fingerprintingI don't understand. Can anyone unpack this concept for me? How does one generate a sound without a speaker or record without a mic.
https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_A...
Sleezy sleezy crap.
I still remember the news articles refering a patent Facebook filed about audio fingerprinting as the evidence of Facebook eavesdropping on the people.
Also technologically with some encryption argorithms, a company can claim that they are not capable to identify user with the fingerprint. But in theory given enough data they still can.
Legally, yes. Practically, I’m not sure the EU could block a major Chinese app from its market for fear of retaliation.
> They also use audio fingerprinting to identify visitors. This doesn’t mean they actually use your microphone or speaker. Instead they generate a sound internally and record the bitstream, which also differs from device to device.
This really blew my mind. Correct me if almost all of them are doing this. If it is so, the congress hearing last year, all those privacy suits, all went into vain didn't they. (PS. bad english)
:/