Apple prepares fix for Safari’s data-leaking IndexedDB bug • The Register


Apple is preparing to fix a bug in its WebKit browser engineer that has been leaking data from its Safari 15 browser at least since the problem was reported last November.

Updates made available to Apple developers on Thursday — iOS 15.3 RC and macOS 12.2 RC — reportedly fix the bug, an improper implementation of the IndexedDB API that allows websites to track users and potentially identify them.

The bug affects Apple’s Safari 15 browser on macOS and all browsers on iOS and iPadOS 15 – because Apple requires all browsers on iOS to be based on its WebKit engine, rather than alternatives like Chromium’s Blink or Mozilla’s Gecko.

Fingerprint.js, a maker of fraud and bot detection libraries, disclosed the privacy issue to Apple on November 28 last year and publicly reported the issue on January 14 because Apple failed to respond in a timely manner.

The flaw is that Apple’s WebKit implemented IndexedDB in a way that violates the same-origin policy (SOP), which is the foundation of browser security.

In a blog post, when a website interacts with an IndexedDB database, Fingerprint.js engineer Martin Bajanik, the browser creates a new empty database with the same name in other active frames, tabs, and windows that are part of the same browser session.

Since these frames, tabs and windows can be associated with different origins – e.g. B. Websites – availability of the database name for these websites violates the SOP.

“The fact that database names have been leaked across different origins is a blatant invasion of privacy,” Bajanik said. “This allows any website to know which websites the user visits in different tabs or windows.”

That would be bad enough, but the privacy issue is compounded by the fact that many websites use unique identifiers in their IndexedDB names. For example, Google appends its Google user ID to IndexedDB database names on sites like This identifier can be used, for example, to query Google’s People API to retrieve the user’s picture and possibly other information, depending on permissions.

“This is a huge mistake,” noted Chrome developer Jake Archibald, via twitter when the problem first appeared. “On OSX, Safari users can (temporarily) switch to a different browser to avoid leaking their data across origins. iOS users have no such choice as Apple bans other browser engines.”

Apple’s stubborn refusal to allow other browser engines in iOS has been a sore point for competing browser makers for years. It has led people to argue that Safari is the new Internet Explorer – a browser holding everyone else back – and that Apple’s platform rules are anti-competitive, a claim UK regulators, if not others, have been taking seriously of late to have.

At a more fundamental level, the problem is that Apple’s insistence on control is not matched by responsiveness to its customers. Apple doesn’t have to keep up with the release cadence of faster-moving competitors since there is no competition between the iOS browsers. It’s WebKit or nothing if you’re using an iPhone or iPad.

Almost two months after the IndexedDB bug was reported, there is no publicly available fix. The situation was similar last year when a localStorage bug surfaced in May. Although Apple’s WebKit engineers, to their credit, responded immediately, this fix wasn’t available until July, when Apple released Safari 14.1.2. And meanwhile, the company’s programmers managed to corrupt IndexedDB – a separate bug, now fixed, that prevented databases from opening.

At least Apple seems to be responding to public pressure. According to Bajanik, Apple engineers began fixing the IndexDB bug on Sunday, January 16, two days after Fingerprint.js publicly announced the issue. ®


Comments are closed.