Apple is preparing to repair 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 on Thursday to Apple developers – iOS 15.3 RC and macOS 12.2 RC – reportedly fix the flaw, an improper implementation of 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 upon its WebKit engine, instead of 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 then posted publicly about the problem on January 14 because Apple failed to respond in a timely manner.
The bug is that Apple’s WebKit has implemented IndexedDB in a way that violates the Same-origin policy (SOP), which forms the basis of browser security.
When a website interacts with an IndexedDB database, explains Fingerprint.js engineer Martin Bajanik in a blog post, 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.
Because these frames, tabs, and windows may be associated with different origins – e.g. websites – the availability of the database name to these sites violates the SOP.
“The fact that database names leak across different origins is an obvious privacy violation,” said Bajanik. “It lets arbitrary websites learn what websites the user visits in different tabs or windows.”
That would be bad enough but the privacy problem is compounded by the fact that many websites use unique identifiers within their IndexedDB names. Google, for example, appends its Google User ID to IndexedDB database names at websites like YouTube.com. This identifier can be used to query Google’s People API, for example, to fetch the user’s picture and possibly other information, depending on permissions.
“This is a huge bug,” observed Chrome developer advocate Jake Archibald, via Twitter when the issue first emerged. “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.”
Apple’s obdurate refusal to allow other browser engines in iOS has been a sore spot 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 anticompetitive, a claim UK regulators, if not others, have lately begun to take seriously.
On a more basic level, the problem is that Apple’s insistence on control isn’t accompanied by responsiveness to its customers. Apple doesn’t have to match the release cadence of faster moving competitors because there is no competition among iOS browsers. It’s WebKit or nothing if you use an iPhone or iPad.
Almost two months after the IndexedDB bug was reported, there’s no publicly available fix. The situation was similar last year when a localStorage bug surfaced in May. Though Apple’s WebKit engineers, to their credit, responded immediately, that repair wasn’t available until July when Apple released Safari 14.1.2. And in the interim, the company’s coders managed to break IndexedDB – a separate bug, now resolved, that prevented databases from being opened.
At least Apple appears to be responsive to public pressure. According to Bajanik, Apple engineers began working to remediate the IndexDB bug on Sunday, January 16, two days after Fingerprint.js publicly disclosed the issue. ®