91–100 of 266 posts
Does disabling web audio beat this fingerprinting?
I always assume that any difficult/annoying anti-fingerprint techniques make you more identifiable instead of less, since very few people do them.
Or so they say.
I expected this article to be published by some hackers or defenders of privacy like EFF, not by a company whose goal is to fingerprint people. Such dystopian times.
These predatory practices are getting out of hand. Props for them to expose this, even though they're the "bad actors" from my point of view.
Putting a node graph audio API in the browser was silly. It should have been just audio worklets.
Wasn't Mozilla's proposed audio API simpler? AFAIK it was beaten out by Google's because people wanted a richer API and lower latencies. https://web.archive.org/web/20120505042746/https://developer...
"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. :)
Earlier quoted context omitted.
Audacity's an awesome piece of software that I've used many times. Never once have I thought "by golly this thing should be a website, and my web browser should be made to expose an audio graph API to every website I visit to that it can be so!"
I'm the opposite. I think website = sanboxed, native = pownage so whenever I can use a website version I often prefer it over a native app. 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.
But all iPhones of the same model have the same processor. Every iPhone 15 Pro Max, of which Apple sells hundreds of millions, all have the same processor. Why do they have different results?