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.

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...

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.

But I would also accept all those multimedia APIs (canvas, WebGL, WebGPU, everything audio and video, including the ) 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.

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.

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.

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.

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.

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.

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.

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.)

https://news.ycombinator.com/context?id=39633730

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.

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...

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.

Please refrain from violating the HN Guidelines. And I'm not sure which emotion you're talking about, other than my use of the word "funny".

> doesn’t make something security theater. The term has a specific meaning

I didn't use the term "security theater". I said "privacy theater".

Now if we want to talk about guidelines, consider that the broad claim you originally made would have to be widely accepted in the industry not to need supporting evidence, at which point it wouldn’t be contributing anything; since the opposite is true, the guidelines about flame bait cover it. It could have gone in a potentially useful direction if you’d been willing to define your terms and support them with evidence, and that would have helped suggest less hyperbolic terms. For example, if you said that Apple could do better at vetting and implementing their features I doubt many people would disagree with you.

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://news.ycombinator.com/item?id=39658880

https://news.ycombinator.com/item?id=39660167

Have you considered that I'm not delusional, and my point may be more subtle than your straw man?

> It is not how the software world works at large.

Have you considered that I'm a software developer myself?

Why are you letting Apple off the hook for shipping a feature that had a massive flaw from the start? It was advertised as being private, but it wasn't.

> I'm curious why iCloud Private Relay is theatre at the moment.

It's still true that iCloud Private Relay covers only a limited amount of traffic on your device from a limited number of apps. It's leaky by design, not a full VPN.

iCloud Private Relay is used for all network activity from Safari which does not seem like a “limited amount of activity.”

A VPN isn't designed to keep your IP address hidden from the operator. iCloud Private Relay doesn't hide your IP address from Apple either. That's not the point, and everyone knows this in advance. The point is to keep your IP address hidden from the request destination servers.

I didn't say that. It's a straw man.

I'll spell out my views below, but I want to start by noting that I don't agree with the way you've characterized them. Going all the way back to your initial reply, I don't like the way this leading question was phrased:

> What specific features do you allege exist just to mislead the general public?

I think Hanlon's razor is a false dilemma. With a big company like Apple, there's typically a combination of bureaucratic incompetence and marketing exaggeration. Clearly, Apple leadership has decided to make privacy a consumer differentiator for their products, so they have a financial incentive to hype privacy features as much as possible. As a consequence, Apple management would be eager to be pitched any and all privacy features from engineering; these may even lead to bonuses and promotions, though that's purely speculation on my part. Regardless of the personal motivations of employees, the company is pursuing privacy features in earnest and isn't intending for them to be fake. Nonetheless, the company also has the unfortunate habit of shipping half-baked features and implementations. This is driven largely by the artificial, forced march of the annual release schedule, which demands that great new features be continually announced at a certain time, whether they're ready or not. The situation is not unique to privacy features either; Apple's entire software product line is suffering in quality. Engineering simply doesn't have enough time to do things right, which results in new features that are superficial and/or flawed. You could say it's marketing-driven incompetence.

Several commenters have mentioned that all software has bugs, as if that were somehow profound, or as if I were somehow ignorant of software development as a software developer. (I actually had to spend some time fixing a bug before I wrote this reply.) But not all bugs are created equal. From my perspective, a bug that's discovered relatively quickly by someone else is worse than a bug that's discovered only years later, in the sense that it suggests insufficient QA on the part of the developers, who themselves should have noticed the bug before it shipped. And a bug in the primary functionality of a product or feature is worse than a bug in a more obscure part of the software. This is why I'm not impressed by the length of time since a bug was fixed; if a feature or product was shipped with an obvious, fundamental flaw in its main functionality, that's a stain on the reputation of the developers. And if they keep making such mistakes, why should you ever trust them to be competent? No bug fix can fix the bug writers.

I don't want to focus too much on iCloud Private Relay, though. It wasn't what I had in mind when I was writing my original comment, and I don't even use iCloud Private Relay myself. I mostly don't use a VPN, except on rare occasions. I've discussed iCloud Private Relay here only because you asked me about it.

It's been a busy afternoon/evening for me, so I've kind of run out of steam now on this comment, but I promised I would reply.

Signal had a bug once. Herego, it’s a scam?

Are you referring to this?

https://www.forbes.com/sites/daveywinder/2019/10/05/signal-m...

It was a bad bug in the Android client, to be sure, but it didn't bypass Signal encryption.

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.

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.

"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.

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.

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.

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.

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.

Fixing this would require removing the information leak entirely, not just masking it under a layer of random deviations.

But, yeah, these guys can get on Golgafrinchan Ark B with the rest of the adtech industry as far as I am concerned.

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.

As the internet gets more and more hostile, this will become more and more correct.

I believe there are (or were, hopefully) similar techniques using that exposed differences between the underlying graphics devices.

Or so they say.

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.

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!

There's value here. Other people are allowed to want more than you want.

Most regulators would also likely consider fingerprinting for certain use cases as acceptable. E.g., detecting abuse, fraud, CP, etc.

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.

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).

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.

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 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.