Source: I'm an author of the research in question (but unaffiliated with this blog).
Note to mods: article title is "Audio Fingerprinting using the AudioContext API". Submitter title is "Sites are using audio (no permissions needed) to track users", which may violate the site guidelines.
Some users on Stack Exchange/Stack Overflow saw that ads were messing with audio APIs and thought the ads were trying to play audio. It turns out the ads were actually doing audio fingerprinting.
It's funny how they try to make us look like the bad guys for using blockers and then they always try and pull a fast one on us. I'd have no sympathy if internet ads became impossible one day.
The entire advertising/sales/PR industry is all about engineering compliance. Trying to guilt trip people is just one manifestation of that general theme.
It reminds me a bit of the spanish conquistadores, who after entering a new island declare the new law (in spanish) and punish every (non-spanish speaking) inhabitant who fails to comply.
It is just so obviously wrong to treat your users like this, the only way to cope with it is literally to take on a mindset that devalues the users (”If they are stupid enough, they deserve it”) or to downplay the impact assymetrical information practices have on the society (Post-Privacy: “You have nothing to hide anyways”).
What it all boils down to is, that you make someone consent to something they don’t understand and that they might not consent to if you put it to them in clear understandable terms. Add nudging and other dark patterns on top and you are going into evil territory.
But no one wants to be evil, so they try to paint an utopia that fits their behaviour, rather than making their behaviour fit an utopia. This is a problem because as the russian writer puts it:
“Above all, don't lie to yourself. The man who lies to himself and listens to his own lie comes to a point that he cannot distinguish the truth within him, or around him, and so loses all respect for himself and for others. And having no respect he ceases to love.”
We can block them but what is needed is laws. They'll always find a way. I mean just using your IP enough ad retargeting can be done, their hostility has no consequence.
Even if they were legally forbidden from tracking people, ad blocking would still be necessary. Untargeted ads are only marginally less unethical than targeted ads. Even untargetted ads exploit peoples insecurities to sell them things they're better off without. (e.g. cola advertisements that depict young attractive socially active people drinking their product.) That's no less manipulative on a billboard on the side of the road than it is on your personalized facebook feed.
Even if there were no ethical problems with ads, they should still be blocked anyway simply because they're a waste of people's time, bandwidth and attention span.
> Even untargetted ads exploit peoples insecurities to sell them things they're better off without.
Eg I assume you do not want to demonize bakers selling bread to hungry people? Or more generally, anyone selling any product you do not agree with to someone who has a need you don't like?
It's not tracking your voice. It's tracking how your browser plays the audio files. Essentially fingerprinting your hardware. Honestly, i hope there are joker like villains out there fucking with all these fingerprinting companies by feeding them bad data.
Filtering out bad data is a part of the job when analyzing the data for information...There are tons of ways people try to mess with these to the point where in a way it's trivial to filter it out-since basically you're trying to extract value in a way that is not real.
For a contrived eg, serving an ad for a niche product instead of the targeted ad and the ad still getting tons of clicks signals pretty highly that the data coming in is being gamed in some way.
It's called click fraud and it's pretty heavily researched
The web audio APIs allow you to generate an audio waveform, process that waveform, and then read the waveform. The article covers how to do this. I'm still a bit confused about why it provides such a good fingerprint, I would have thought it would only vary by browser and version, and then only if the browser updates its audio algorithms. But I'm guessing the APIs interact with the OS in some way to do the processing.
“This process doesn't require access to the device permissions like microphone or speakers. No audio is recorded, collected or played by any means. It gathers the audio signature of a user's device and uses it to create an identifier to track that user. It simply relies on the difference in the way these generated signals are processed on each device.”
Everything is different for every version of firmware, hardware, driver revision, etc. it’s like enumerating fonts, it combined with other fingerprinting techniques provides a very unique snapshot of you.
Eff’s panapticlick provides an audio fingerprinting example. There exist plugins which will provide some entropy to your fingerprint which also changes over time. That helps a little, but any changes you make really makes you stick out like a sore thumb (your audioprofile becomes even more unique)
Details like knowing how much latency to expect can be important for some use-cases, such as if you're trying to time things to occur at the same moment to the user.
I would propose an addition for when permission is granted: if (as in the example given) there's a need to time things to occur at the same time then the app can pass that on to the APIs and the browser makes it happen, but the app gets no feedback about how it was done or even if it needed to be done at all - why does it need it? The browser made sure it synced up!
In other words, make it more declarative and less verbose.
I don’t know all the details for this particular issue, but, in general, knowing the latency can be important. Imagine you’re displaying frames and playing sound together and you want them synchronized. You need some way to submit graphics frames and audio so that they arrive at the same time.
The browser could always increase the apparent audio latency by buffering, but that reduces the ability of music apps to perform well.
What I'm suggesting is the code in the app doesn't work out how to submit graphics frames and audio so that they arrive at the same time in the browser, but that the app's code tells the browser how to sync up the graphics frames and audio that it receives.
Move responsibility for the syncing to the browser and then the app doesn't need to know anything. In short, I can put it together and send it to you, or I can send you the bits and tell you how they should be put together.
A graphics frame appears on the screen at a specific time. (For VR, it is a definite time, and this is critical. For normal video or games, a little bit of slop, maybe a few ms, is probably okay.)
For audio, humans are sensitive to 10 ms deviations or even less.
Any API that works decently will need to synchronize audio and video, so there needs to be a way for a program to say “this audio sample should play are the same time as this video frame is shown”. But an API should also allow programs to react as quickly as possible to user input. And Bluetooth headphones, in particular, have very, very high latency.
So designing an API that performs well without revealing the latency is hard.
I do think it would be good to cleanly separate normal web pages and games, though. For pure content, none of this matters except that video needs to maintain synchronization. But normal content does not need clicks to translate quickly to video changes.
I don't know about you but I find everything about computers is hard, that doesn't mean there aren't better or worse solutions.
The browser is the presentation layer, it needs to know the latency of your headphones (or the system does). Why does the content provider need it? What's wrong with "here is frame A, please play audio A at the same time (while taking into account the latency that only you know about)" as a request?
It's simply moving responsibility from one entity to another, there's no technical reason that the content provide would be better at syncing the two, just as with any other network communication.
And then the site totally fails. I'm no fan of JS either but the amount of sites that use JS is now close to 100%. So you either stay paranoid and the web breaks or you eat the shit sandwich. Pure lunacy.
That's ok. Then I have the option to weigh whether the risk is worth it or rather not. 9 out of 10 times it is not, in rare cases I will allow the js to execute.
How do you explain to one of these "I'm not good with computers haha" types what a CDN is and why Taboola CDN shouldn't be allowed but Akamai should be otherwise things Won't Work Right. Even if they're capable of learning [1] why should they care, when all these security measures actively make their life harder?
Blocking audio and other fingerprintable surfaces by default, with a "click here to enable audio / video" and a "remember my choice on this site in future" is the only way it can possibly work, because 99% of users will only ever go for the laziest option. We need to have protections for them that work regardless of (or in spite of) their skill level.
I thought that then looked at OscillatorNode and it allows you to essentially load a waveform into memory and/or generate your own. This means you can run a legit multitrack recorder or a synth from your web browser. I had a requirement for this 10 years ago, but Requires java extensions on the users browser
Not to be overly negative but thats lunacy. What you described is best served as a native application. Web browsers were supposed to be information viewing programs. Not virtual machines. I know it makes portable applications easy but the smash a VM into a text viewer is such a horribly broken idea and is why we have this security nightmare.
Nothing about this is a virtual machine. It is an API that exposes a lower-level Audio interface. I don't need to spawn a virtual machine or mess with any DLLs or figure out libraries because I can simply load a browser. Nothing is saying this needs to be on a remote server, it can be a local .html file for all it matters.
But hey some of us still run around with MS-DOS 5.22 on that new Spectre-ridden, rowhammer-ready i7 because DOS/4GW is hella stable.
> Web browsers were supposed to be information viewing programs.
True if we stopped thinking at 1996. I don't know how to tell you but browsers become application platforms not document delivery vehicles in the last 20 years.
I think this is mistaken. The device API supposedly provides this, but the info you get is always generic due to fingerprinting protection. Also, AudioContext is expected to be active only when created within a user action like a button click. Otherwise it doesn't run (implemented in Safari).
This is a pain - on the one hand, the browser vendors and w3c are locking down API capabilities to prevent fingerprinting and timing based security hacks, but these are interfering with genuine needs to provide audio functionality. For example, you can't determine whether the user has 3 audio devices connected and prompt them to select one for output. So you really can't build desktop quality audio systems with webaudio and siblings.
> Also, AudioContext is expected to be active only when created within a user action like a button click.
I really hate the user-action restriction as a security measure, because it's ridiculously easy to bypass[0], particularly on Chrome. It's privacy theater -- annoying for legitimate developers, but easy for malicious actors to get around.
Putting this stuff behind a permission or sandboxing it somehow would be better for both end-users and developers. As it stands, we just get fewer webaudio applications online from legitimate developers, and they all move to native platforms where it's even easier to fingerprint users. And the malicious sites that don't move to native just fingerprint anyway because we're using bad, opaque metrics for consent.
I have no problem with sites being able to do this, after I’ve given them permission to access the audio stack in the first place, and limited to first-party scripts on the page.
That's reasonable for just output selection. So shouldnt be able to send audio to all the devices? .. and different audio streams? .. which is all commonplace in the desktop world.
Sure, but the browser should handle that logic. Even if the website prompts a user to select an audio device it should be handled on the browser's side without feedback to the website.
It's been a little while since I used this, but navigator.mediaDevices.enumerateDevices
will give you that list, allowing you to have a menu for a user to choose one and then the client code must use setSinkId to assign the chosen device id. https://developer.mozilla.org/en-US/docs
The IDs you get (both deviceID and groupID) are not user displayable. They're like random numbers. In normal browsing mode, you keep getting the same deviceIDs for the same domain, but random groupIDs for every refresh. You get different deviceIDs for different sites. In private browsing mode, you get both random every time.
Is there sufficient information in this to identify individual machines? E.g., consider a family acquiring notebooks of the same type for each family member and operating them over the same LAN (outward IP address). There may be differences depending on components picked from a supply pool, but in general, there isn't much variety in a specific make and model running on the same OS revision (and the same generation of drivers, according to automatic updates).
Further, is there sufficient isolation in the audio stack so that fingerprints are independent of the software currently running on the machine? (Another comment regarding DACs and insufficient isolation from the north bridge and induced harmonics indicates otherwise.)
I guess, while this may provide some indications, on its own, it provides insufficient information for identification of a specific hardware device. (Edit: Which is, of course, bad enough.)
There doesn't have to be. All it takes is to extract a few more bits. When combined with all the other bits it isn't all that long before you have 33 of them an that is enough to uniquely identify you.
I don't know how well this would stand up in court, but the obvious difference here seems to be using "an exploit to read your local files" vs an intentionally designed API.
Neither the canvas API, nor the audio API was designed with the idea of providing funtionalities for user tracking. To me it is a clear misuse and I find the comparision to an exploit fair. I really would like to see somebody sue.
Unless it's flipping bits via radiation, every exploit is (ab)using "an intentionally designed API". In this case, audio API may be intentionally designed, but the intention wasn't to allow fingerprinting.
You have proposed a social solution to a technical problem. Why does JavaScript offer a way to enumerate things about the client cat the server has no need to know?
I think tracking is pretty much a social problem. The fact that it is technologically possible is a necessary but not sufficient to make the problem technical.
As a comparison, think about speeding. It is technologically possible because there are cars that can pass most speed limits. I’m sure we can find a technological solution that eliminates speeding. But for the most part, regulations and enforcement is a sufficiently good measure.
You can absolutely govern a car's speed electronically.
You can also make JavaScript able to figure out how to play sound without letting it disclose what it knows about your sound system to a remote machine.
Because it is extraordinary difficult to have a useful programming language that can not be used for tracking.
A social solution and technical solutions are needed. Firefox has put in a huge effort to prevent tracking but many useful features can also be used for tracking so a browser will not be able to determine useful and non useful code.
We have to make it less useful then. They were given the audio/canvas/whatever APIs and instead of using it to make great web applications they abused it by turning it into personal information to track us and exploit us for profit. We gave them this power and now we have to take it away.
The site shouldn't be able to do anything without user's permission.
I don't want a browser that comes up with 10000 popups asking if it has permission to render an image or permission to add 2 numbers together.
I want a browser that can get the task done with the least friction possible and a legal system that prevents abuse. The website should be the one to inform me that they are actually using the audio api for tracking and not just playing audio. With a large penalty for lying.
If we were talking about the issue of people being stabbed you don't suggest "Why should the stabber be penalized? The victim should have been wearing a Kevlar vest that doesn't allow them to be stabbed. If they weren't then they should simply expect that people will stab them."
>The website should be the one to inform me that they are actually using the audio api for tracking and not just playing audio. With a large penalty for lying.
The website can't do anything without your browser cooperating. The website can request the audio API as much as it wants but if your browser had a same configuration then it would just ignore it.
You're asking for legislation on a problem with a global scope. Countries that ignore your laws will still do all of this as long as your browser lets them.
>If we were talking about the issue of people being stabbed you don't suggest "Why should the stabber be penalized? The victim should have been wearing a Kevlar vest that doesn't allow them to be stabbed.
This is such a poor analogy. The server doesn't do anything without a client asking for something. In your case the victim went to the stabber and started the interaction. Then the victim's electric scooter (browser) malfunctioned or was poorly configured and drove into the stabber's knife.
Of course the server isn't blameless, because they are most likely knowingly exploiting this. But to suggest that the user has no control over this is foolish. It implies that the user can't be blamed for anything their computer does.
> 10000 popups asking if it has permission to render an image
We need an automated approach. We need the ability to not only disable browser APIs but also make them return fake data to fool the website. We need the ability to inspect the data websites are sending back and redact data we don't want them to have just like corporations perform deep packet inspection to prevent data exfiltration.
> If we were talking about the issue of people being stabbed
In this case we handed them the knife. We thought they'd use it to cut something for us and they stabbed us instead. They even made the ability to stab us part of their terms of service. This cannot go on.
>We need the ability to not only disable browser APIs but also make them return fake data to fool the website.
Browsers have been trying this for a long time but its not simple. Chrome has had multiple attempts at making it impossible to detect incognito mode but people keep finding ways. The old way was checking if the API to store data was available so chrome made it so that there is an emulated data store for incognito mode and then websites just check how fast the local data store is to check if it is on disk or in memory.
It would be an extraordinary effort to remove all of these issues since many of them are outside of the browser like what exact gpu and driver is in use could slightly change how the page is rendered or how long certain things take.
> Browsers have been trying this for a long time but its not simple.
I didn't say it was gonna be easy. I said it was necessary. This is a perpetual arms race. If content blockers can maintain their huge blocklists, browsers should also be able to maintain their own counter-measures to abusive websites. Browser vendors created and standardized the APIs that websites are now exploiting. I expect them to clean it up.
> then websites just check how fast the local data store is to check if it is on disk or in memory.
Making both calls equally slow should prevent this particular side channel attack.
What is very simple is just creating a law stating that you may only use exactly the data needed for the purpose of providing the service and any extra data must be requested from the user with the easy ability to decline. Now rather than years of cat and mouse where advertisers always have the upper hand, the advertisers suffer massive fines for misuse.
They'll just say the tracking is part of the business model and therefore needed to provide the service. The law's purpose is to allow users to negotiate the terms so it is worthless if it doesn't force websites to provide a "give me access to the service without any tracking" option. Imposing laws on the internet contributes to the regionalization of the network: what was once a completely free international network will be divided into many regulated national networks. Not all countries will have these laws so evading sanctions will be as simple as hosting something in a country like Russia.
>They'll just say the tracking is part of the business model and therefore needed to provide the service.
This is unacceptable under the GDPR. You must allow users to opt out. If this affects your business model than the legal option is to remove the free plan and charge a fee for the service.
The issue is that JavaScript and the DOM are not 100% specified. There is no technical solution for that. Removing obvious ways to enumerate differences can help but can never be a complete solution and many differences can not be removed at all.
Might have been reasonable at some point. Unfortunately, even if you don't own a computer, power it on or use it, you're still under computer-based surveillance.
Why phone cameras? Credit cards. Mobile phones. Street cameras with face recognition. Security cameras. Do you know that many private-owned cameras are connected to a "cloud" (to save money on buying a video server) and cloud owners could see streams from all of them?
Because your friends are likely to take a picture of you and other friends with good angle/exposure etc, and upload them to some network. There is no escaping that, unlike credit cards.
I don’t know if security / street cams actually record anything for more than a day, and I don’t know anyone with home security camera, but friends are always there!
There is no avenue to escape the rich from creating profit at the expense of the masses. Digital privacy serves neither the government nor the wealthy executives helming these corporations so it will never happen. The public is apathetic and preoccupied with rising food and housing costs. The merits of digital privacy won’t fix any of this.
How? The US regulates that websites in the US can't do this. But Chinese website can, Russian websites can.
I don't see how you solve this with regulation without breaking the internet. As far as I can tell, the solution ultimately is to consider privacy first as a user and a developer. Browsers and their users need to start providing less information to websites by default and prompt the user to share information.
If you try doing this through regulation then you end up with GDPR pop ups. What we need is for the browsers (and OS!) to stop leaking all of our information.
Is this why Firefox for Android will occasionally have non-dimissable media control notifications load on web sites which don't have audio? The amount of times I've had to force-close after opening a NY Times link is infuriating
I forgot to say: you can always check if a website is playing audio, as there should be a loudspeaker icon on its tab (Firefox and Chrome on desktop, Firefox at least on mobile).
Hmm, I suppose a good test might be to disable javascript and see if you still get clicks.
For me, when my iphone is connected to my car's bluetooth, the kind of ad/tracking-infested websites make it beep like crazy, same sound as turning my volume up and down, closing the tab stops the beeping. I assumed it was some ad or video being glitchy about auto-play, but it happens even without a visible media player...
No that is because your computer and all parts within must accept interference. And your motherboard’s $0.07 embedded DAC really wasn’t designed with isolation in mind. So you “hear” your north bridge bus because as your processor speed changes its harmonics induce interfere with the DAC.
If this is a laptop, you could disconnect all external power sources (such as charger, external HD’s etc) and those clicks and noise will be lowered (but probably still noticeable at high gain). If you purchased a power conditioner and used a high quality USB3 audio interface (read: isolated DAC) you wouldn’t hear any clicks.
You think your brain magically decodes digital signals? No, the DAC in your AirPods do that. Your AirPods are isolated since they are battery driven, but I’m sure it’s at the mercy of whatever noise is in your atmosphere.
Also you should lower your audio expectations with AirPods, they are hardly audiophile quality
I don't think you wish to hear that your airpods suck because of the price you paid. However Apple is well known for taking products and charging a premium for. I assume you have this problem on all headphone types (bluetooth or hardwired) and across multiple USB audio devices? Or is it limited simply to the airpods which should work noise-free like other headphones of its class including Sennheiser, Bose, and Dr. Dre Beats.
They are constructing a simple audio synthesis graph and rendering it for a few seconds.
But since all the audio processing happens in the browser, without OS involvement, how can the fingerprints be different between say 64 bit Firefox browsers running on 64 bit Windows?
I can understand differences between different browser binaries, since optimizations can slightly change the output due to floating point order of operation, but can a particular browser binary generate different fingerprints?
Example: On Windows, a sin() call usually goes into msvcrt.dll, and can thus return different results on different machines for the same binary. To name one possible reason: Different vectorization (due to different SSE support).
Corollary: Don't link to the CRT sin/cos/etc. if you want your binary to give the same result on different machines.
This also happens on TV, and you probably have no idea. There are applications on iPads and phones that work with ratings firms, like Nielsen and so forth. These firms work with content producers, and they embed inaudible tones into TV shows and even advertisements. The phones and iPads pick up this tone and report back that the user is, indeed, watching said TV show or ad. It's a way of confirmed tracking of views.
While not this exact claim, years ago I wrote an app for a TV show to detect ultrasonic tones embedded in episodes of the show. While not solely for tracking (it was to sync a clock to the episode you're watching), there were special tones to trigger ads.
I could easily see this being expanded upon and included in a tracking SDK.
The technology is called ultrasound cross-device tracking (uXDT) and companies like SilverPush are doing it. There is an ever-growing amount of android apps that contain this tech. DDG'ing should yield quite a bit of interesting articles about this practice.
PilferShush is an experimental F-droid app that is supposed to prevent this kind of tracking by blocking your phone's microphone and jamming the Audio frequencies used for tracking. F-droid page:
I did some further research and I'm stumped, but I thought I'd share my findings. It looks like your question doesn't have an easy answer and requires more research.
I couldn't find much new information on Ultrasound Cross-Device Tracking (uXDT). This could be good, meaning that it's not being widely used, or it could be bad and mean that simply not much is publicly known about the extent to which it is used. (or my google-fu is weak)
To clarify my post form earlier. The "list" only has the SDKs used for uXDT, not the apps that make use of them.
This is the list of SDKs possibly used for uXDT:
acrcloud, actv8, alphonso, axwave, beatgridmedia, bitsound (soundlly), chirp, cifrasoft, copsonic, cueaudio, digimarc, dv (dov-e), fidzup, fluzo, gracenote, hotstar(zapr), hound, inscape, instreamatic (VIA), lisnr, moodmedia, mufin , prontoly (now sonarax), redbricklane(zapr), shopkick, signal360, silverpush, sonarax, soniccode, sonicnotify (now Signal360), soundpays, tonetag, trillbit, zapr
I got it from PilferShush's project page which is an experimental F-droid app researching uXDT. It's worth a look, but a bit messy:
Only a few specific apps were mentioned in the research paper. It probably only scratches the tip of the ice berg. The researchers looked for SilverPush in an 8 TB dataset of 1,320,822 apps submitted to VirusTotal.
---
These were the only apps that were mentioned:
(Apps with 1,000,000 – 5,000,000 downloads)
100000+ SMS Messages, developed by Moziberg
Pinoy Henyo, developed by Jayson Tamayo
(100,000 – 500,000 downloads)
McDo Philippines, developed by Golden Arches Dev. Corp.
Krispy Kreme Philippines, developed by Mobext
(50,000 – 100,000)
Civil Service Reviewer Free, developed by Jayson Tamayo
The Addon Detector only seems to be able to find three uXDT app SDKs from the whole bunch mentioned by PilferShush:
lisnr, signal360 and silverpush
---
SoniControl is also an interesting project worth looking at.
It's goal is to detect acoustic tracking information.
https://github.com/fhstp/SoniControl
I’ve read that financial companies use it for fraud detection. If a known fingerprinted client tries a bunch of different logins, they can flag that.
That said, I’m not convinced full on fingerprinting is necessary here. I suspect you could do the same thing using IP addresses and it would work at least 80% as well.
I work on fraud prevention for a web company that provides financial services. My last job was the same thing. From the more technical side, not only there's a need to understand business, but to think about hard problems like these.
An IP address is not a good indicator and wouldn't replace fingerprinting. IPs may change over time, there bay me non-static IP addresses from residential connections (so, not only data centers) and today, in our mobile world, change much more frequently than in the past.
IP is just another marker that can be useful, sometimes. Even the subnet may be useful. But unfortunately, for fighting fraud we have to rely on techniques such as a device fingerprinting with the canvas exploit. There's a much simpler approach, though, but it works only on some occasions: a cookie.
So, you just check if the cookie is present and it matches the previous cookie from the same user. Done, the device matches and you're good to go (keep in mind that if someone owns your device and credentials, there's not that much we can currently do - although the behavioural biometrics proponents would have you believe otherwise).
But what if there's no cookie be cause the user logged out or opened their browser using incognito mode, or just changed browsers. In that case, we would have a false positive for the user having and using a new device. Which, from our point of view, highly correlates with fraud. This is industry-wide, from the fraud prev POV and not just some specific business (like, for example, an ecommerce website), at least most of people I have spoken with over the years have mentioned why fingerprinting is really important, and I've seen it first-hand.
So, we don't sell your data. We're not looking to match you with... whatever you can come up with in terms of a fingerprinting-data-matching-nightmare. In most cases, the only people that have the fingerprinted data are from the fraud prevention team. And we generally hate bad players, both from outisde and the inside of the company.
What we wanna do (and, again, this is generally) is try to create a better user experience for our good users. So we may relax some rules if your device is known. Or we may give you access to some features that other users don't have (let's say, a beta for a new service that we start offering).
This works by collecting as much data as possible from the device and then trying to differentiate small changes (let's say, your internal storage free memory in MBs) from big changes that could in fact mean that the user is using a new device.
So, for example, we could force you to go to account verification to login to a new device vs relaxing some rules about login from a good, trusted device for that user.
I'm sure there are exceptions, and that there may be some bad players abusing their fingerprinting capabilities. But at the same time, I'm pretty sure that most people are not OK with using that data with another purposes - even the execs. And even if we did, let's say, track our ads in a way that when you sign up we get an ID related to a particular ad that we ran - we can see that although you're a new user and by extension you have a new device, you still came to our business because we placed an ad. Which we couldn't do another way, and then the UX suffers because of decisions made to deal with that.
What I'm trying to get across with all of this is: fingerprinting is, in fact, very useful for fraud prevention, and I would argue that disabling the Canvas API exploit would affect most, if not all, machine learning models for fraud prev running on production.
EDIT: and, BTW, most companies that are trying to buy data from other companies are trying to get user behavior. What your users are doing in your app, maybe involving their product in some way (i.e. you're Spotify and are trying to get data from Shazam in order to understand user behavior with regards to the type of songs they've shazamed in the past). Again, I'm NOT saying that there may be companies tying data from outside sources that are iffy at best. And at least the more modern companies I've work at, they're not cool with merrily sending data over to another company, even if they pay. It seems like everyone is starting to understand that their data is as important as their intellectual property.
What if you just use a remote device and change it each time (eg. get a VPS)? If someone really doesn't want to get detected, they will always find ways around it. It's a never-ending race.
Yeah, they have to setup a completely different environment every time, or delete all cookies and then change the environment so as to fool the "feature change / new device" model. This can have different consequences depending on the company and how they model user behavior. One could be that the user is treated as a risky user - always having new devices. Another could be that the user is treated as an outlier and nothing more than that - not risky, not safe. And then, maybe if the user has a good previous history, you let them do their thing and see what happens. Maybe you're uncovering new fraudulent behavior or maybe you have new false positive example.
Nevertheless, the amount of users that go to these lenghts to mask themselves in the general population (i.e., all users of a 50m monthly active users app) is so miniscule that's not even a discussion, the opportunity cost is huge vs just focusing on your 99.998% (number I just came up with, not a real metric) of users and understanding their behavior and how to model a "good user". New users have stable device behavior? Well, then that VPS customer is probably gonna be traced frequently. This is how some banks do things as well (not fingerprinting, but transaction monitoring in general).
EDIT: as an aside, I think the most important point to understand about how companies and spaces like the ones I have experience in use fingerprinting is - it gives you outliers and only works as long as you have a nice mass of good users. These users are not trying to game you, so they don't tamper with our fingerprinting. The ones that do tamper are either tech savvy or fraudsters. But if everyone tampered with it... You see where I'm going with that.
By fingerprinting you tie people's actions and violate their privacy. Eg user A does action 1 and 2. He doesnt want counterparty to action 1 to know that he is doing action 2.
> What's the harm of making fingerprinting illegal?
imagine if you were able to put a camera outside the entrance of the bathroom, and record who is going in and out.
This is recording a public space (the entrance), but it reveals who is in there, and for how long.
I m sure you can guess why people won't like being known to have gone to the bathroom for X minutes (vs X seconds). It's the same online, just slightly less obvious.
I was just wondering about this the other day after reading comments on here about the Web Audio APIs having very high resolution (or accurate is probably a better word) timing available. Probably just some kind of fingerprint using them, I was going to go dig around through the MDN to figure out if I could... but just haven't had the time yet.
That's definitely a useful privacy feature - however, unrelated to the concerns from the article. It doesn't listen in to you or anything - just the type of API that's exposed can be use as some bits for fingerprinting.
Laptop manufacturers are starting to build in camera kill switches, see HP Spectre x360. Not sure how necessary it really is given you could just put a simple slide cover [1] on.
As the article fails to load at the current time from my location I suppose all I can put in is my thought on how many times I've seen my mobile phone browser asking for microphone permissions on news sites and wonder if some mobile browsers have wised up to this already and defer to the operating system?
Whilst I'd be the first to cheer for the end of ads and targeting, what monetisation model(s) are planned to replace advertising and fund free email, messagingz photo sharing and social media platforms?
If someone is interested in blocking this, the firefox addon CanvasBlocker has an option to spoof this. Although it's not enabled by default, it doesn't seem to brake anything.
More and more the only thing that makes sense is blocking all resource loads not from the primary site or directly affiliated servers, which unfortunately breaks a lot of things.
This already happens. On one of our web fingerprinting solutions we provided our certificate to the vendor so they could use our domain when we loaded their resource (the fingerprinting code) on our app running on the user's browser (sorry - more of a data, slightly backend dude over here, so maybe networking doesn't even work like I'm describing) and the ad blockers wouldn't block the script execution - even thought the script is NOT an ad
So you work for a financial institution and you provided your private key to a third party company so they can impersonate your server to host fingerprinting code?! That sounds really irresponsible.
I wasn't working in a financial institution, no. We did provide some services, but it isn't qualified as a bank. And maybe it wasn't they impersonating our server, but yeah, it was fishy.
I think Instart Logic does some sort of ad proxying to bypass uBlock Origin. Normal solution is to install uBlock Origin Extra, easy solution is to disable JavaScript for evil sites.
You can get better fingerprints from WebGL because it provides information about your video card. Within a year I think I saw the site that really needed WebGL only once. It is almost useless feature that is suited only for fingerprinting. You better go to your Firefox settings and disable it right now to prevent tracking.
To prevent tracking using Canvas it would be good if there was a single drawing library for all browsers or at least they used only internal code and didn't rely on OS or hardware acceleration.
Regarding Audio API, it also would be nice if it provided less details about audio hardware or OS audio stack.
Disabling WebGL just gives the fingerprinting code a different data point to fingerprint you with, kind of like “do not track.” I’m not convinced it would make any difference.
Not necessarily. Because disabling WebGL is probably relatively rare, while the API itself is fairly ubiquitous, that one bit probably has a high surprisal value, so it carries more information than it would seem to.
AudioContext fingerprinting is not new. Libraries like Fingerprintjs use it, among other device fingerprinting techniques. It's in there since 10 Jun 2018 (https://github.com/Valve/fingerprintjs2/commit/caf14daa9e2de...).
Combined with other methods, you can get very good accuracy.
If there is an OSS lib to do it, you can bet the adtech companies are doing it even longer.
Also, IANAL but I think it's legal under GDPR, Recital 29:
> In order to create incentives to apply pseudonymisation when processing personal data, measures of pseudonymisation should, whilst allowing general analysis, be possible within the same controller when that controller has taken technical and organisational measures necessary to ensure, for the processing concerned, that this Regulation is implemented, and that additional information for attributing the personal data to a specific data subject is kept separately. The controller processing the personal data should indicate the authorised persons within the same controller.
The fingerprint value is not PI because it can't identify one specific person, but only a device at best (if accurate enough between runs).
With enough smart people and good incentive (=adtech), I bet this can be abused to identify the person.
Note that this fingerprinting technique exploits differences in the behavior of the AudioContext API, but does not (and cannot) actually record audio.
Paper: https://webtransparency.cs.princeton.edu/webcensus/index.htm...
Demonstration (test your own audio fingerprint): https://audiofingerprint.openwpm.com
Discussion from 2016: https://news.ycombinator.com/item?id=11729438
Full list of websites where audio fingerprinting scripts were found (in March 2016): https://webtransparency.cs.princeton.edu/webcensus/audio_fp_...
Source: I'm an author of the research in question (but unaffiliated with this blog).
Note to mods: article title is "Audio Fingerprinting using the AudioContext API". Submitter title is "Sites are using audio (no permissions needed) to track users", which may violate the site guidelines.