/
Navigation
Chronicles
Browse all articles
Explore
Semantic exploration
Research
Entity momentum
Nexus
Correlations & relationships
Story Arc
Topic evolution
Drift Map
Semantic trajectory animation
Posts
Analysis & commentary
Pulse API
Tech news intelligence API
Browse
Entities
Companies, people, products, technologies
Domains
Browse by publication source
Handles
Browse by social media handle
Detection
Concept Search
Semantic similarity search
High Impact Stories
Top coverage by position
Sentiment Analysis
Positive/negative coverage
Anomaly Detection
Unusual coverage patterns
Analysis
Rivalry Report
Compare two entities head-to-head
Semantic Pivots
Narrative discontinuities
Crisis Response
Event recovery patterns
Connected
Search: /
Command: ⌘K
Embeddings: large
TEXXR

Chronicles

The story behind the story

days · browse · Enter similar · o open

A flaw in Safari 15's IndexedDB API can leak browser activity and user identifiers, like Google ID, to other sites; Apple was alerted of the flaw on November 28

DISCLAIMER: FingerprintJS does not use this vulnerability in our products and does not provide cross-site tracking services. Source: The Verge .

FingerprintJS Blog

Context & Ripple Effects

Safari’s anti-tracking posture had already faced scrutiny after Google identified five flaws in Intelligent Tracking Prevention. The IndexedDB issue matters because it exposes a lower-level browser mechanism through which sites can infer activity and retrieve identifiers, bypassing the privacy outcome Safari is meant to provide.

Apple had been notified in November, and related coverage records a release-candidate fix for the IndexedDB leak days after this report. That makes the disclosure a test of how quickly Safari’s platform updates can close tracking-relevant implementation gaps.

First-order effects

  • Safari 15 users’ browsing activity and identifiers including Google ID are exposed to other sites through IndexedDB until Apple’s corrected browser software is deployed.
  • Apple must remediate a privacy failure in a core web API after being alerted to the issue, with the iOS 15.3 and macOS 12.2 release candidates carrying the reported fix.

Second-order effects

  • Sites that used IndexedDB database names to correlate Safari visitors lose that signal as patched versions replace the vulnerable behavior.
  • The fix reinforces that Safari web developers must treat storage-API behavior as a moving compatibility target when browser privacy protections are updated.

Third-order effects

  • Repeated weaknesses in Safari’s tracking protections point to browser privacy becoming an implementation-level assurance problem: policy features such as Intelligent Tracking Prevention are only as durable as the APIs beneath them.
  • If disclosures continue to uncover cross-site leakage paths in WebKit browsers, Apple’s privacy differentiation will depend increasingly on rapid patching and broader API-level review rather than standalone anti-tracking controls.

The trend: Browser privacy is shifting from blocking overt trackers to continuously hardening ordinary web APIs that can be repurposed for cross-site identification.

Discussion

  • @jaffathecake Jake Archibald on x
    This is a huge bug. On OSX, Safari users can (temporarily) switch to another browser to avoid their data leaking across origins. iOS users have no such choice, because Apple imposes a ban on other browser engines. https://safarileaks.com/
  • @cramforce Malte Ubl on x
    @scottjenson Bug was filed in November. Not patched. It does impact all browsers on iOS
  • @jaffathecake Jake Archibald on x
    This comes after other huge site-breaking bugs in IndexedDB https://bugs.webkit.org/... and localStorage https://twitter.com/... that took months to fix. It's so frustrating that iOS users just have to put up with this, and web developers have to jump through hoops to work around…
  • @cramforce Malte Ubl on x
    Safari is slowly and reliably exploring even the last category of bugs one could possibly have in a database in a web browser https://twitter.com/...
  • @tailosivetech @tailosivetech on x
    So could this mean while iPhone 14 Max won't be as great as I thought, it may have better battery life than the Pro Max? https://twitter.com/...
  • @quinnypig Corey Quinn on x
    “All browsers on iOS must use our WebKit implementation” is incompatible with “we patch security bugs slower than old people fuck.” Pick one, ⁦@Apple⁩. https://www.macrumors.com/...
  • @slightlylate Alex Russell on x
    iOS's cadence of showstopping web bugs (with no recourse because of the #AppleBrowserBan) is becoming indistinguishable from what an adversary hellbent on rubbishing the web's reputation might plan. One imagines a villian muttering “they can always install apps...muhahahaha!!!” h…
  • @brucel Bruce Lawson on x
    Bad luck for iOS users, because of the #AppleBrowserBan. But not-Steve knows best. https://twitter.com/...
  • @maxart2501 Massimo Artizzu on x
    This is the result of Apple's browser engine monopoly: every security bug in WebKit leaves users with no way to avoid the problem (except not using the browser at all). And Apple isn't particularly keen to invest in the web, so these bugs plague the ecosystems *for months* 😩 http…
  • @slightlylate Alex Russell on x
    Now, obviously, this isn't how I expect managers in Cupertino would want this play out. They'd want a high-quality subset of the legacy platform to continue to simply not expand, stifling the web by simply taking away its ability to meet modern needs.
  • @slightlylate Alex Russell on x
    Good to see coverage of this: https://www.theverge.com/... ...but it isn't even the first time (pdf): https://storage.googleapis.com/ ... https://twitter.com/...
  • @slightlylate Alex Russell on x
    When it isn't silent, pervasive undermining of privacy without recourse, it's a constant stream of showstopper bugs. This was 7 months ago: https://www.theregister.com/ ...
  • @slightlylate Alex Russell on x
    This wouldn't be a crisis of users could choose competent browsers. Why won't Apple allow it? No good reason: https://infrequently.org/...
  • @slightlylate Alex Russell on x
    So this stuff is doubly embarrassing as it also makes a mockery of the titular reasons Apple cites when justifying it's anti-competitive tactics. But underfunding is always going to create quality issues, too: https://infrequently.org/...
  • @wehackpurple We Hack Purple on x
    Incase Java wasn't your favorite of all time. “A bug in WebKit's implementation of a JavaScript API called IndexedDB can reveal your recent browsing history and even your identity” https://www.macrumors.com/...
  • @jaffathecake Jake Archibald on x
    @Arlen According to https://fingerprintjs.com/... it impacts all “active frames, tabs, and windows within the same browser session”
  • @adam_unchained Adam on x
    Bug in Safari allows a site to access IndexedDB of other sites. Same-origin policy is ignored. NEVER use any online service that stores your private key in browser's session. Even if it's created for you to provide “seamless” experience. #IOTA #Crypto https://www.youtube.com/...
  • @slightlylate Alex Russell on x
    Is it intentional? In each instance, and about each bug, of course not. These are good engineers under impossible pressure. But the structural under-funding of the Safari/WebKit teams? And the ban on competition? Absolutely intentional, with predictable consequences.
  • @slightlylate Alex Russell on x
    TFW you tell regulators you need to prevent real competition “because privacy and security” without actually improving privacy and security for users: https://infrequently.org/... https://twitter.com/...
  • @slightlylate Alex Russell on x
    Some of us are salty about this because: a.) our engines don't have this problem b.) our products on iOS *do* have this problem c.) Apple won't let us keep our users safe Of course we're angry. https://twitter.com/...
  • @slightlylate Alex Russell on x
    Who needs third party cookies when you have WebKit?
  • @somegadgetguy Juan Carlos Bagnell on x
    Apple doesn't sell your data, they give it away for free! It just works! https://fingerprintjs.com/... But seriously, keep an eye on browser activity. Safari is leaking.
  • @cos_theta Kaustubha Govind on x
    This is terrifying 😱 https://fingerprintjs.com/... https://twitter.com/...
  • @tomayac Thomas Steiner on x
    Exploiting IndexedDB API information leaks in Safari 15. Just played with the demo (https://safarileaks.com/) and the leak still reproduces on iOS 15.3 (19D5040e). It was reported to the WebKit Bug Tracker on Nov 28, '21 as bug 233548. Hoping for a fix! https://fingerprintjs.com/…
  • @aarontoponce @aarontoponce on x
    A software bug introduced in Safari 15's implementation of the IndexedDB API lets any website track your internet activity and even reveal your identity. https://fingerprintjs.com/...
  • @dchest Dmitry Chestnykh on x
    Oops, indexedDb.databases() in Safari 15 returns database names of all opened tabs/frames https://fingerprintjs.com/...
  • @tanvihacks Tanvi on x
    Looks like an IndexedDB bug can be used to leak browser history and user identifiers in iOS and iPadOS 15 browsers. As a temporary work around, you can try using Safari in private browsing mode and avoid reusing a tab for more than 1 site. https://fingerprintjs.com/...
  • @alexachenowith Alexa Chenowith on x
    IndexedDB in Safari 15 leaks your browsing activity in real time https://fingerprintjs.com/...
  • @craigmorten Craig Morten on x
    Gosh this ain't good... Safari 15 IndexedDB has a bug where it's violating SOP and leaking other page database names, which for Google includes your user ID 😬 Check out the demo https://safarileaks.com/ and blog https://fingerprintjs.com/... to learn more.