[HN Gopher] Bypassing Safari 17's advanced audio fingerprinting ...
___________________________________________________________________
Bypassing Safari 17's advanced audio fingerprinting protection
Author : valventin
Score : 57 points
Date : 2024-03-09 17:54 UTC (5 hours ago)
(HTM) web link (fingerprint.com)
(TXT) w3m dump (fingerprint.com)
| balls187 wrote:
| Fingerprint states that this service is for fraud detection, but
| they are actively discussing how they are circumventing browser
| privacy protections.
|
| 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?
| mostlysimilar wrote:
| Tale as old as time. Think of all of the legislative attacks on
| encryption in the name of protecting people.
| A4ET8a8uTh0 wrote:
| My charitable take is that it does take both ends of the
| spectrum to arrive at a solution that does not exactly
| satisfy everyone, but is an acceptable place to stop the
| impossible arms race. The unfortunate reality is that we are
| nowhere the end of that race.
|
| 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.
| neilv wrote:
| > _they are actively discussing how they are circumventing
| browser privacy protections._
|
| 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.
| brookst wrote:
| Tl;dr: Apple's implementation adds random, uniformly distributed
| noise, so running many samples one can back out the noise.
|
| Kind of a naive design but easily fixed.
| modeless wrote:
| Putting a node graph audio API in the browser was silly. It
| should have been just audio worklets.
| capitainenemo wrote:
| 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...
| docEdub wrote:
| Why's that?
| pdntspa wrote:
| The author's casual dismissal of privacy concerns for _activating
| your microphone_ , for a method that they admit lacks accuracy,
| is concerning if not offensive.
| travisd wrote:
| Based on the article, it sounds like this doesn't activate a
| device's microphone at all. If it did, most (all?) browsers
| would give a pop-up requesting permission for that.
| marcellus23 wrote:
| This has nothing to do with the microphone...
| pdntspa wrote:
| Then where are these audio samples coming from?
| echoangle wrote:
| This is using differences in the audio processing pipeline
| of the browser, they just use some input sound which could
| be taken from a file. The fingerprint is the slightly
| different output signal when applying filters to the input
| signal.
| pdntspa wrote:
| How is it possible that this produces enough variations
| to be usable without sampling some sort of audio source?
| The entire pipeline is digital, there is not any room for
| interference.
| echoangle wrote:
| It's doing signal processing using floats, that can lead
| to differences in the result even if the implemented
| algorithm is identical. Float addition is not commutative
| so reordering some calculations, either in different
| implementations or with different compiler options, can
| lead to slightly different results. This just detects
| browser version and maybe OS/Architecture, the same
| browser binary should still give the same results between
| different devices with same hardware.
| dmazzoni wrote:
| They just generate a sine wave and do some processing on
| it. The results are very similar but because the
| processing depends on functions like fast fourier
| transform, plus the exact algorithm in the browser code,
| tiny differences emerge.
| saurik wrote:
| Please stop wasting everyone's time with your random
| assumptions as to why this does or doesn't work and just
| click on the link in the article to the detailed
| explanation of exactly how this works.
|
| > The technique is called audio fingerprinting, and you
| can learn how it works in our [previous article].
|
| https://fingerprint.com/blog/audio-fingerprinting/
| rpdillon wrote:
| It's about variations in the implementation of the
| digital pipeline that are traceable to the output. It has
| nothing to do with analog processing or interference.
| tempodox wrote:
| The browser's Audio API.
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Audio_A...
| SloopJon wrote:
| From the article: "In a nutshell, audio fingerprinting uses
| the browser's Audio API to render an audio signal with
| OfflineAudioContext interface." It links to a previous
| article with more details:
|
| https://fingerprint.com/blog/audio-fingerprinting/
|
| Here's an example from that article of a sound source:
| const oscillator = context.createOscillator()
| oscillator.type = "triangle"
| oscillator.frequency.value = 1000
| Saris wrote:
| I missed where the microphone is used, it looks like it's only
| using the output pipeline?
| h4x0rr wrote:
| Can anyone explain why the results are different to begin with?
| E.g. why is this audio fingerprinting even possible in the first
| place?
| echoangle wrote:
| Probably implementation details and compiler optimizations,
| float addition is not commutative for example. Implementing the
| same algorithm with the same formulas correctly can still lead
| to slightly different results
| Retr0id wrote:
| This was my first thought too, and they cover it in more detail
| here https://fingerprint.com/blog/audio-fingerprinting/#why-
| the-a...
|
| 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.)
| dmazzoni wrote:
| The essence seems to be that the web audio API has a lot of
| algorithms that do a lot of math, and every browser has a
| slightly different implementation, and the exact results depend
| on the operating system and cpu too. So if you use the web
| audio API to generate a small signal all browsers will generate
| something that's really close, but the tiny differences can be
| used to help tell them apart.
| nox101 wrote:
| that wouldn't help. you already know the browser and os
| through easier means
| unglaublich wrote:
| Like what? The voluntarily provided User-Agent? The browser
| is in control of that.
| a-dub wrote:
| i think it comes from similar tricks that are played with webgl
| where there is a lot of entropy that comes from pc videocard
| drivers and the hardware itself.
|
| it's a shame that browser people have to add noise to audio
| buffer handling to try and thwart it.
| gary_0 wrote:
| Does this technique fingerprint based on hardware/driver/OS
| differences with audio processing, or just the browser software?
|
| I believe there are (or were, hopefully) similar techniques using
| <canvas> that exposed differences between the underlying graphics
| devices.
| dmazzoni wrote:
| This is similar. Audio algorithms often call OS functions and
| make use of CPU optimizations. One example they mentioned is
| the fast-fourier transform (FFT). All OS's include a version of
| that function but it tends to be optimized over time, and tends
| to behave differently on different CPUs depending on what SIMD
| instructions are available.
| stockhorn wrote:
| Did I read this correctly and audio fingerprinting is mainly
| about identifiying the used browser version and OS or laptop, but
| it cant identify end-users in a stable way?
| mikepavone wrote:
| My phone running Firefox for Android produced the same results
| as the sample data for Firefox on Windows which does seem to
| fit with this largely being a browser identification scheme
| fbdab103 wrote:
| I think that is correct, but it still seems like an amount of
| leakage that could be further correlated with other another
| trick.
|
| 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.
| Crespyl wrote:
| You may be thinking of https://www.amiunique.org/fingerprint
| fbdab103 wrote:
| Not the one I used, but this one actually looks better.
|
| 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).
| dmazzoni wrote:
| Yeah, it doesn't tell a website who you are. Instead, it allows
| them to recognize you again when you come back to visit again,
| even if you clear cookies.
|
| 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.
| omnicognate wrote:
| Why am I supposed to want any website I visit to be able to
| render audio offline anyway?
| nox101 wrote:
| https://wavacity.com/ ?
| omnicognate wrote:
| 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!"
| jauntywundrkind wrote:
| We'll make sure we stop building software you could imagine
| then. /s
|
| There's value here. Other people are allowed to want more
| than you want.
| goodSteveramos wrote:
| Get with the times. Your privacy must be sacrificed so some
| random web app you have never heard of can do something no
| website should be able to do at all. Or maybe that's just a
| pretense and not the real reason Google keeps adding all
| these APIs. People seem to forget that ChromeOS is
| literally Google trying to turn every computer into a thin
| client for their services.
| ninkendo wrote:
| There's a push to make every single last thing a normal
| application can do, available to web apps through some half-
| standardized JavaScript API or another. Generally google comes
| up with use cases, implements it in chrome, and tries to call
| it a standard. Then everyone complains when Apple doesn't
| implement these standards fast enough, and that Safari is
| "holding back the web" or "the new IE" because it's not keeping
| up with every last feature Chrome implements.
|
| 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.
| jwells89 wrote:
| Things like this seem niche enough to safely put behind a
| permission dialog. 99.9% of sites/web apps have no legitimate
| need for this functionality.
| shuckles wrote:
| Permissions dialogs solve for a problem product creators
| have and create more problems for users.
| ninkendo wrote:
| That's how location services and notifications work today,
| and all it means is that websites just constantly nag me to
| enable them.
|
| 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.
| latexr wrote:
| > That's how location services and notifications work
| today, and all it means is that websites just constantly
| nag me to enable them.
|
| 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.
| jwells89 wrote:
| I'm kinda surprised that no fork of Firefox has added
| both global and domain-scoped toggles for web feature
| support. I know there's flags in about:config but that
| only covers some things and isn't very user friendly.
|
| 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.
| mindslight wrote:
| When a surveillance company (in this case Google) is
| leading the push, security against surveillance isn't on
| their list of requirements. In fact it's more of an anti-
| requirement, which escapes human judgement via design by
| committee or other anti-scrutiny technique. So then we end
| up with yet another insecure API that we've got to suffer
| for years as the browser makers who actually care about
| security painstakingly figure out how to mitigate the
| vulnerabilities in the original standard.
|
| 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.
| knodi wrote:
| Does disabling web audio beat this fingerprinting?
| arijun wrote:
| I always assume that any difficult/annoying anti-fingerprint
| techniques make you more identifiable instead of less, since
| very few people do them.
| neilv wrote:
| > _Fingerprinting is used to identify bad actors when they want
| to remain anonymous. For example, when they want to sign in to
| your account or use stolen credit card credentials.
| Fingerprinting can identify repeat bad actors, allowing you to
| prevent them from committing fraud. However, many people see it
| as a privacy violation and therefore don't like it._
|
| 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.
| austinpena wrote:
| Their tool is priced too expensive to be used for marketing
| purposes in most cases.
| diebeforei485 wrote:
| 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?
| Asmod4n wrote:
| Buy the same CPU 10 times and benchmark them, they all score
| differently.
___________________________________________________________________
(page generated 2024-03-09 23:00 UTC)