Bypassing Safari 17's advanced audio fingerprinting protection
fingerprint.com
fingerprint.com
Codenamed 'DrawnApart', the technique relies on WebGL to count the number and speed of the execution units in the GPU, measure the time needed to complete vertex renders, handle stall functions, and more stuff
________________
1. https://www.bleepingcomputer.com/news/security/researchers-u...
If you want a unit of energy you need power multiplied by time not divided, so “gigawatt days” not “gigawatts per day”.
Try to decode mpeg video at HD resolution in software sometime.
If a website that has no obvious case for using the GPU, but is instead using it to fingerprint, then the user won't experience any slow downs from a software renderer (as it is usually done relatively quickly).
If a website needs the GPU for their videos/graphics, but also incidentally wants to fingerprint you, you're shit out of luck in that case. But this is no worse than what we have current day.
It would still be way less than what large companies are burning on training proprietary LLMs. Do you think the ChatGPT model you use daily was the success at first go? And in that same world, consumers should not even try to protect themselves from GPU fingerprinting?
> The same people who have spent the past 40 years getting confused and worked up about cookies?
Stop with the condescension. It's not about being confused; it's about mitigating genuine privacy concerns. We're not idiots, and dismissing genuine worries won't make the issues disappear.
And most websites most users visit will need the GPU to be remotely usable. For them enabling specific permissions for every website they visit is very inconvenient.
But you can probably also use those to fingerprint, but probably not as precise.
Firefox has only started to ship hardware accelerated video decode a few versions ago. Until very recently, all my video playback was software decoded.
They have complete freedom on their servers. On my computer, I make the rules. They are lucky if I allow their code to run at all.
a somewhat bigger problem is that to a very significant extent the actual owners of the machines are microsoft, google, and apple, not the users; they make the rules, and the users are lucky if the owners allow their code to run at all. under those circumstances, blocking fingerprinting is practically quite difficult, because the 'they' who want to fingerprint you and the 'they' who make the rules about what code run on your machine are the same people, not two opposing groups
an additional problem is that an increasing part of the web is run by criminal elements like harvey weinstein and the rest of the mpaa, who will block you if they can detect you attempting to protect your privacy from them by blocking fingerprinting, even if apple decides it would be a good idea; cloudflare and google are perhaps the most prominent enforcers here, perhaps somewhat reluctantly
But I would also accept all those multimedia APIs (canvas, WebGL, WebGPU, everything audio and video, including the <video> tag) and some others (e.g. service workers and everything else app-like) requiring a permission. Again, most websites don't need them, so given the abuse potential, there's no reason why they should be openly available.
But most of it is bullshit tracking, anti-scraping and similar stuff.
Safari still has show stopping perf bugs in WebGL 2 (a 2017 finalized spec): https://forums.developer.apple.com/forums/thread/696821 https://forum.unity.com/threads/unity-webgl-poor-rendering-p... so Mac/iOS users wouldn't notice a difference probably.
Privacy in browsers is a lost cause. It's a 30+ year old technology that has become ridiculously bloated in scope, with privacy and security only considered as an afterthought.
A bit like Ad Nauseam that loads ads in an invisible sandbox and clicks on all of them to mess up their reporting.
A lot of Apple's "privacy" features nowadays are marketing. It's privacy theater. What matters is whether they can tell a plausible story to the public, not whether is technically effective.
https://fingerprint.com/blog/ios15-icloud-private-relay-vuln...
> 3rd party cookie blocking?
It's very funny that you should ask this question in response to an article about fingerprinting without cookies.
But yes, there are various workaround to use 1st party cookies or other storage to take the place of 3rd party cookies.
Perhaps the worst is the Safari "Privacy Report", which has always been misleading: https://www.simoahava.com/privacy/intelligent-tracking-preve...
I’d say the privacy report is the only real false security feature, but Apple was a laggard in that market. For all we know, they could have been trying to match features with Ghostery or Brave that teach consumers this is a feature you should expect from your browser. Users may also have been needed education about that behavior in order to justify the compatibility regressions cookie blocking incurs. It’s impossible to know from the outside, but your body of evidence to support a really strong accusation is quite weak.
If Safari behaved the same as Chrome, then Apple couldn't market Safari as more private than Chrome.
I don't know what you're talking about. What are X, Y, and Z specifically?
All software has bugs. I think it is more interesting to see how companies respond to reported issues. And how they improve things.
Is OpenSSL "theatre" because it had (bad!) bugs in the past?
https://www.schneier.com/blog/archives/2009/11/beyond_securi...
Public Relay is obviously not accurately described by that term and any rule which classifies it as such would be useless because it would classify all browser security as theater because everyone has had bugs, and everyone has had to adopt more sophisticated defenses to counter more sophisticated attackers.
It doesn't even apply in this instance, since Apple's work on fingerprint resistance still results in real privacy improvements even when later shown to be imperfect. It means Apple has to improve what they've already done, not that what they've done so far is mere "marketing" or "theatre".
Shall I cite my list of CVE? Or perhaps it would be more interesting to cite my list of unfixed 0days.
> It doesn't even apply in this instance, since Apple's work on fingerprint resistance still results in real privacy improvements even when later shown to be imperfect. It means Apple has to improve what they've already done, not that what they've done so far is mere "marketing" or "theatre".
What does it say about Apple engineering that that they keep shipping features with very obvious and/or predictable flaws?
As for your point about the pattern of vulnerabilities: I'd attribute this to being closed source. They keep shipping security features with limited auditing, and only discover flaws in production.
Apple announces powerful new privacy and security features: https://www.apple.com/newsroom/2023/06/apple-announces-power...
WebKit Features in Safari 17.0: https://webkit.org/blog/14445/webkit-features-in-safari-17-0...
In general, Apple is trying to market itself as the privacy company. "What happens on iPhone stays on iPhone", yadda yadda.
> Maybe Hanlon's applies here.
I think my view is in alignment with Hanlon's razor. I don't think it's necessarily malicious deception. Rather, Apple has a habit of shipping the laziest implementations and slapping a "privacy" label on them, but the public doesn't know that these are lazy half-measures.
> As for your point about the pattern of vulnerabilities: I'd attribute this to being closed source.
WebKit is open source.
> They keep shipping security features with limited auditing, and only discover flaws in production.
I don't think this is a closed/open source issue. It's just bad engineering.
In the game of tracking, minor hurdles are great at stymying many actors.
And finally, your citation in response to someone saying they haven’t seen Apple market web audio fingerprinting protections has no references to said feature. Are you saying all the privacy features in that press release are a smokescreen? It’s quite unclear.
I'm not aware of any. But they aren't advertising fingerprinting resistance either.
> In the game of tracking, minor hurdles are great at stymying many actors.
That's questionable.
> And finally, your citation in response to someone saying they haven’t seen Apple market web audio fingerprinting protections has no references to said feature.
There were multiple antifingerprinting methods in Safari 17. The linked articles referred to them collectively.
>
> That's questionable.
It's basically indisputable. Ask any online advertising buyer about the effectiveness of audience targeting for Safari users versus the competition. Or consider the ability of the average website operator to adopt Fingerprint.js instead of whatever half-broken tool their usual audience measurement provider offers them.
https://blog.google/products/chrome/privacy-sandbox-tracking...
> Chrome is testing Tracking Protection, a new feature that limits cross-site tracking.
And I haven't heard any argument suggesting that the marketing is deceptive. Apple implemented numerous fingerprinting protections and nobody has demonstrated any of them to be "theatre" or mere "marketing", only that a security researcher was able to defeat one protection among many (and then published their work so Apple can solve for it in the next release). In reality, ALL such work is an ongoing battle between developers and security researchers.
In each subsequent reply you are shifting your stance in order to deflect away from this original claim, essentially by holding Apple to an impossible standard where anything less than perfection on the first try is equivalent to scamming the public with lies. Do you want to defend your original claim that "a lot of Apple's privacy features nowadays are marketing" and "privacy theater"?
> Shall I cite my list of CVE? Or perhaps it would be more interesting to cite my list of unfixed 0days.
The list of vulnerabilities is not very informative for the same reason a trackers blocked statistic is not. It doesn’t give any baseline for comparison and may just be a reflection of how important and interesting to security researchers the target is.
That's a rather bold claim, unless you're a mind-reader.
> The number of reports is not helpful data without a lot of other context, but you offered it as if it would be convincing or definitive.
I didn't give a number. I only said I have a list. It seems that you're still missing my point, which was simply that my knowledge of and experience with these specific technologies means that my original comment was not a "wild accusation". That's it, that's the whole point.
> How many CVEs and 0-days have you filed against Audacity?
I don't use Audacity, and I have no idea how it's relevant here.
It seems like you have me confused with someone else in the thread who used the phrase "wild accusation" and are responding rudely. I think your original comment was needlessly exaggerated and inflammatory and defending it, instead of clarifying it, is a bad look. Clearly you have an axe to grind with Apple, and my advice to you is you should put a little more effort into hiding it if you want others to take you seriously.
No, I'm not confused. But that comment was the context for my mentioning CVE and 0days, which you decided to discuss yourself.
simondotau: "That's an wild accusation to make without citations."
me: "Shall I cite my list of CVE? Or perhaps it would be more interesting to cite my list of unfixed 0days."
you: "The list of vulnerabilities is not very informative for the same reason a trackers blocked statistic is not."
If you don't want to discuss my previous quoted comment, that's fine, but you have in fact mentioned it and continue to mention it. Thus, the context is very relevant.
> and are responding rudely.
Where exactly was I rude?
> I think your original comment was needlessly exaggerated and inflammatory and defending it, instead of clarifying it, is a bad look.
I would be happy to clarify it, but the first time you asked for clarification was here: https://news.ycombinator.com/item?id=39661492
I'll respond to that comment, though it may take some time.
> Clearly you have an axe to grind with Apple
I've been a Mac user for more than 20 years, a professional Mac developer for more than 15, and I currently sell apps in the Mac App Store and iOS App Store. Do I have critiques of Apple? Yes, of course. However, they are the critiques of an insider who has no intention to leave the ecosystem.
You're throwing around your ego and responding with alleged claims of personal expertise when this discussion has nothing to do with that. You're deflecting with puffery; which is irrelevant with respect to your original claim which I questioned. I don't care that you have a list and I don't care how long it is. You accused Apple of engaging in privacy theatre, and that "many" privacy features where mere "marketing". Defend that claim or move on.
TL;DR different codepaths even within the same codebase (e.g. SIMD variants) can result in subtly different floating point results (iiuc, likely related to to the fact that floating point math is unexpectedly sensitive to order of operations etc.)
Edit: I found this pretty great article on the subject https://randomascii.wordpress.com/2013/07/16/floating-point-...
We're both right, depending on how you frame the question.
Then add resolution, IP address location (which VPN they use is also a datapoint), which time they are active at, etc. and you can get a good almost-unique identifier.
it's a shame that browser people have to add noise to audio buffer handling to try and thwart it.
"There are several practical approaches that an implementation may take to avoid this aliasing. Regardless of approach, the idealized discrete-time digital audio signal is well defined mathematically. The trade-off for the implementation is a matter of implementation cost (in terms of CPU usage) versus fidelity to achieving this ideal.
It is expected that an implementation will take some care in achieving this ideal, but it is reasonable to consider lower-quality, less-costly approaches on lower-end hardware."
AFAICT this means that the OscillatorNode output they are exploiting here is almost guaranteed to not be deterministic across browsers (or even in the same browser on different hardware). The non-determinism is based on whatever anti-aliasing method is chosen by the browser (or, possibly, multiple paths within the same browser which could get chosen based on the underlying hardware). This includes changes/fixes to the same anti-aliasing algos.
I don't really understand this choice of relegating anti-aliasing to the browser given that:
a) any high-quality audio app/library will want full control over how the signals they generate avoid aliasing and will not use these stock oscillators anyway, or
b) the kinds of web applications that would accept arbitrary anti-aliasing algos (and the consequent browser-dependent discrepancies therein) probably wouldn't care whether the aliasing algo is hardcoded SIMD instructions or some 20MB javascript web audio helper framework
1: https://webaudio.github.io/web-audio-api/#OscillatorNode
Edit: clarification
Edit 2: more clarifications. :)
Edit 3: I wonder if the same kind of solution could be used here as was used by Hixie to standardize the HTML5 parser. Namely, just have some domain expert specify an exact, deterministic algo for anti-aliasing that works well enough, then have all the browsers use that going forward. I'd bet the only measurable perf hit would be to tutorials that show how to use the web audio api to generate signals from the stock anti-aliased oscillators. :)
So you want to allow the implementation to decide how much to spend on it depending on available compute, battery and so on.
https://web.archive.org/web/20120505042746/https://developer...
I wonder if we might well have had more traction with Mozilla's approach and ASM.js if V8 had had similar features.
Oh well. Is what it is, and Mozilla (and Microsoft and Apple) did at least manage to get WASM which has been super useful even outside of browsers.
On the other hand, I did clear my browser cache and switched on the VPN, and they mis-identified me as a new visitor.
Still, despicable business model.
I wonder why audio API's are even available without giving a website permission? It feels like this could easily be fixed with a simple "This site would like to use your sound devices"-dialog.
Even if that’s wishful thinking, there’s still immense virtue in publishing this research and getting it out in the open. If an article gets published explaining how a particular brand of green backpack helps with shoplifting do we worry that everyone’s going to shoplift more? I’d err more on the side of knowing shops are more likely to catch on to the tactic.
Of course not. We should be able to intercept every request, filter them, even modify them to send fake data instead if we wish it.
Fixing this would require removing the information leak entirely, not just masking it under a layer of random deviations.
As the internet gets more and more hostile, this will become more and more correct.
It's not even just cloudflare and similar DDOS checks, but now even things that should just be in the HTML of the page are loaded with JS.
But, yeah, these guys can get on Golgafrinchan Ark B with the rest of the adtech industry as far as I am concerned.
I believe there are (or were, hopefully) similar techniques using <canvas> that exposed differences between the underlying graphics devices.
Or so they say.
> "With the adoption of Fingerprint, we can now recognize and personalize approximately 23% of total visits to NeimanMarcus.com, up from the previous baseline of 8-10%."
Of course, these companies have always been around. But this post reads like it threads the line between "our product defeats Apple's futile defenses" and "we care so much about user privacy we're white-hat cracking Apple's defenses".
And another "between-the-lines" joke is that this site doesn't throw up a cookie dialog when you load it. What a joke! "We don't need cookies to track you, haha!"
On their front page they tell me how often I have visited and that my incognito mode does not prevent their tracking.
Isn’t that “other use”?
> Does Fingerprint Pro require consent?
> Our technology is intended to be used for fraud detection only; for this case, no user consent is required. However, any use outside of fraud detection must comply with GDPR user consent rules.
There's value here. Other people are allowed to want more than you want.
I use photopea all the time now. it's available on every machine, even machines I don't have permission to install software on
I wouldn't trust a browser sandbox all that much given the high interest in subverting it.
Sorry, I’d prefer to stick with my operating system, not install QubesOS.
So when you make a meme or whatever and repost it somewhere else, guess what, they know who did that!
It really isn't it's extremely janky and buggy, only use it as an absolute last resort.
I would prefer websites just be websites and that we don’t have every single damned API available to whatever trashy site I accidentally click on, but I guess you and me are outliers here. Most people on HN seem to welcome every single JS API because web development is the only platform anyone seems to care about any more.
Things like this make for a more annoying web all around, because now it’s just one more tool sites can use to track me and increase engagement. (Edit: sibling poster chuckles said it way better than I can.)
If I had my way, JavaScript on the web would be limited to XMLHttpRequest and basic DOM manipulation and couldn’t do anything else. A totally separate “rich” JavaScript engine could be opted into by the user for any website that presents itself as an “application” like ones that legitimately want audio API’s like these. All these half-baked web app “standards” that google is forcing down our throats can be confined to that leper colony.
Then the most important bit: browsers could let me completely disable the “rich” engine, and I can go back to having a sane web experience again.
It also means you can tell the browser to outright deny every request, thus avoiding even getting prompted. If a website detects the request was denied and still prompts you any other way, that’s an undeniable signal to close the tab and never return.
The result is that the web just keeps getting incrementally worse and worse. It’s all good intentions in creating these API’s but the result is that everything just gets more terrible.
That’d let users turn support for all the fancy bits off by default and enable them in the tiny handful of cases that they’re actually desired. This way as far as sites are concerned your browser simply doesn’t support those features and thus can’t nag you.
And I'm all for focusing on technical security, but it's worth mentioning that the biggest most concentrated win would be making commercial digital surveillance illegal (ie the path the GDPR tries to head in). Imagine if large public companies had to make their revenue by honest means instead of working as advanced persistent threats.
Most regulators would also likely consider fingerprinting for certain use cases as acceptable. E.g., detecting abuse, fraud, CP, etc.
Remember Me On This Device: Not today Satan!
Use code LINUS for immediate jail-time.
Find My iPhone — You mean find my digital privacy regulator.
I think the only way you're gonna swing it legally is by intention.
If you knowingly opt into being identified (like ticking an unticked "remember me" box that clearly explains the precise purpose of the identification) then it is okay.
If some asshat decides to do it without your informed, clear, and uncompelled consent, throw the fucker in the slammer.
It's not that complicated.
Again, it's really hard to define what we all "mean" in legal terms.
So as a user my preference not to be fingerprinted or tracked takes a back seat in the name of fraud detection?
So we should allow police to wiretap in the name of crime prevention?
Admittedly, that was the first time I read about fingerprinting in this manner and bypassing explicit privacy protections is definitely not something I would want for my future self ( or that my of my family ).
In other words, I think you are right. Privacy probably needs to be codified. It may seem hard to do given existing entrenched interests, but you have to start somewhere. Not that long ago people thought buying people is 'just the way world works'. Things can change. Slowly, but they do.
I'd love to see a successful prosecution as something like a US CFAA violation, setting a precedent that puts the fear of god into the widespread slimy side of our field.
But I suspect it will have to be a non-US country leading that, because a lot of the US economy and power is now tied up in widespread slimy behavior of our field.
the issue is murky for certain use cases. take payments for example. fingerprinting is used at scale in that field, and for good measure. you want to be able to know the risk associated with a user (chargebacks, fraud, etc).
There was previously a site which could indicate how globally unique your environment was (some combination of screen size, user-agent, fonts?, etc). Locking down to a specific hardware+browser configuration probably does a lot to remove anonymity.
Just being Linux + Firefox is terrible for blending into the herd. Let alone everything else that leaks (having a desktop + GPU + good monitor basically destroys all remaining hope).
The about page has some history https://coveryourtracks.eff.org/about
This is particularly a problem with big advertiser networks because they can track you across many sites you visit, even if you disable third-party cookies.
It has positive uses too, like preventing click fraud and concert ticket arbitrage.
I don't think that's what stockhorn said. stockhorn said it can only identify a what browser and OS and laptop model you're using. Someone else with the same browser, OS, and laptop model would have the same fingerprint. So audio fingerprinting couldn't precisely recognize you again when you come back again.
the collision rate of their ids is stated to be 0.05%
what they do is basically collect a lot of signals from the browser (audio processing stuff being only a part of it) and then compute an id on the server.
These practices and their repercussions aren't self contained.
This doesn't seem to acknowledge the use of fingerprinting in intentional violation of the privacy of ordinary people, for marketing profiling and just selling them out because someone is willing to pay.
On https://demo.fingerprint.com/ , they do start to hint at non-anti-fraud purposes, but the use case seems to be full of poo. (Logins or cookies are the way to do this. Anything else is trying to circumvent privacy mechanisms. And if they don't distinguish users perfectly, they're doubly violating privacy by then leaking private information between people.)
> Personalization -- Improve user experience and boost sales by personalizing your website with Fingerprint device intelligence. Provide your visitors with their search history, interface customization, or a persistent shopping cart without having to rely on cookies or logins.
Popup warning on "https://demo.fingerprint.com/personalization":
> Heads up! -- Fingerprint Pro technology cannot be used to circumvent GDPR and other regulations and must fully comply with the laws in the jurisdiction. You should not implement personalization elements across incognito mode and normal mode because it violates the users expectations and will lead to a bad experience. -- This technical demo only uses incognito mode to demonstrate cookie expiration for non-technical folks.
Sounds a bit like a disingenuous bad actor doing CYA while demonstrating their capabilities, nudge, nudge, wink, wink.
Kind of a naive design but easily fixed.
Funny how no one seems to notice that, and they're all praising the article.
Why do they have different results?
They sell ~200M iPhones per year, but I doubt most are the most expensive model.
So, if you visit Google, your hash would be something like "h38kflak". If you're visiting twitter, the API would generate something different, so you won't be tracked across websites.
That way, even if you clean your cookies, you can still be identified as the same user.
The use case? Fraud detection and that kinda stuff. For example, you may create a web game where you allow users to play instantly without "creating" an account. So, an anonymous account would be created in the background, in order to log in. Any bad actor can just clear their cookies/storage to bypass a ban. IP banning isn't reliable, as multiple users may share an adress.
It's a shame that we have to rely on web api hacks in order to fingerprint users for legitimate reasons, and that ends up in an eternal cat and mouse game, because anything you try today may be broken tomorrow.