{"id":2318,"date":"2022-01-16T14:09:18","date_gmt":"2022-01-16T14:09:18","guid":{"rendered":"https:\/\/mailinvest.blog\/index.php\/2022\/01\/16\/safari-api-bug-leaks-browsing-data-that-can-reveal-a-users-identity\/"},"modified":"2022-01-16T14:09:18","modified_gmt":"2022-01-16T14:09:18","slug":"safari-api-bug-leaks-browsing-data-that-can-reveal-a-users-identity","status":"publish","type":"post","link":"https:\/\/mailinvest.blog\/index.php\/2022\/01\/16\/safari-api-bug-leaks-browsing-data-that-can-reveal-a-users-identity\/","title":{"rendered":"Safari API bug leaks browsing data that can reveal a user’s identity"},"content":{"rendered":"

<\/a>\n<\/p>\n

\n


\n
\n AppleInsider is supported by its audience and may earn commission as an Amazon Associate and affiliate partner on qualifying purchases. These affiliate partnerships do not influence our editorial content.
\n <\/em> \n <\/p>\n<\/div>\n

\n

A bug in Safari<\/a> in how it handles the IndexedDB API is potentially leaking information about a user’s browsing habits, an issue that could be used to reveal the user’s identity. <\/p>\n

\n

Apple has continuously attempted to make Safari privacy-focused, with the introduction of initiatives<\/a> to prevent cross-site tracking and the Safari Privacy Report<\/a> meant to help protect users. However, a bug in how Safari functions may have undone all of that work. <\/p>\n<\/div>\n

\n

A blog post<\/a> by browser fingerprinting service FingerprintJS points out that there’s a problem with the way Apple implemented IndexedDB API in Safari 15. According to the researchers, the bug can allow any website to track a browser’s internet activity, and potentially determine their identity. <\/p>\n<\/div>\n

\n

IndexedDB is a browser API used by major web browsers as client-side storage, holding data such as databases. Normally, the use of a “same-origin policy” will limit what data can be accessed by which website, and typically makes it so that a site can only access data that it generated, not those of other sites. <\/p>\n<\/div>\n

\n

In the case of Safari 15 for macOS<\/a>, iOS<\/a>, and iPadOS<\/a>, it was found that IndexedDB is violating the same-origin policy. The researchers claim that whenever a website interacts with its database, a new empty database using the same name is created “in all other active frames, tabs, and windows within the same browser session.” <\/p>\n<\/div>\n

\n

The leak is an issue as it can allow websites to learn what other websites a user visits in different tabs or windows within the same session. In part, this is due to databases having generally unique and website-specific names. <\/p>\n<\/div>\n

\n

The problem is worsened as some websites use database names that include unique identifiers specific to a user. For websites that can share the same authentication credentials, such as Gmail and YouTube, the database name can include the same authenticated Google User ID. <\/p>\n<\/div>\n

\n

That Google User ID is used as an internal identifier within Google, and relates to a single account. It is also possible to pull personal information from Google’s APIs using this identifier, which could help sites fully identify the user. <\/p>\n<\/div>\n

\n

In testing, it was found that indexed databases with universally unique identifiers were created by ad networks. However, Safari’s tracking prevention features prevented those database names from being leaked in this manner. <\/p>\n<\/div>\n

\n

Using a private window doesn’t protect users from the phenomena, however, browsing sessions are limited to a single tab, limiting its effect. <\/p>\n<\/div>\n

\n
\"A<\/a>\n<\/div>\n<\/div>\n
\n

A webpage demonstrating<\/a> the leak has been created by FingerprintJS, with it able to display the Google User ID as well as websites loaded from the same browsing session from after the point the demo was accessed. <\/p>\n<\/div>\n

\n

The list of affected browsers consists of Safari 15 on macOS, and effectively all browsers on iOS 15 and iPadOS 15, due to the requirement that they all use WebKit. <\/p>\n<\/div>\n

Protecting Yourself<\/h2>\n

<\/p>\n

\n

Due to the way the problem manifests, there’s little that Safari users can actually do about the problem. It is possible to block JavaScript by default but enable it only on trusted sites, but that may harm the browsing experience. <\/p>\n<\/div>\n

\n

Another alternative on macOS is to use a different browser as a temporary measure. This option is not available to iOS and iPadOS users. <\/p>\n<\/div>\n

\n

Ultimately, the researchers admit, “the only real protection is to update your browser or OS once the issue is resolved by Apple.” A bug report has been submitted to the WebKit maintainers to try and get it fixed as soon as possible. <\/p>\n<\/div>\n<\/div>\n