Does Safari on OS X Mavericks Ignore Browsing History Preferences?

Bad Privacy Behavior on OS X Mavericks 10.9 with Safari Version 7.0 (9537.71)

I wanted to document some troubling behavior I recently noticed with Safari Version 7.0 (9537.71) shortly after upgrading OS X 10.9 Mavericks.

To limit advertiser tracking, I usually only ever use Safari in its Private Browsing Mode (Safari—>Private Browsing), and regularly Reset Safari (Safari—>Reset Safari…) in order to “Remove All Website Data…” in the middle of browsing sessions with Safari.

I also enable all the privacy-enhancing settings I can find in web browsers, which in the case of Safari Version 7.0 included the following settings in Safari’s Privacy tab of the Preferences menu:
– Selecting the “Ask websites not to track me” checkbox
– Selecting the “From third parties and advertisers” checkbox from the “Block cookies and other website data” options
– Selecting the “Do not preload Top Hit in the background” and “Prevent search engine from providing suggestions” checkboxes from the “Smart Search Field” options.
I also use two extensions with Safari–AdBlock Plus and Disconnect–but these behaviors occur with extensions disabled, too.

Persistent Local Storage

I’ve noticed that Safari often appears to re-spawn (or mysteriously fails to delete) local storage for many websites when using Safari’s Private Browsing and/or the Reset Safari features and then re-opening Safari. So it’s frustrating enough that Safari’s “Reset Safari” feature—which is presented to users as an opportunity to “Remove All Website Data…”—does not actually remove all website data unless you repeat the process at least twice in some cases for Local Storage.

But the problem I noticed with the most recent version of Safari is even more frustrating from a privacy standpoint.  To verify that Safari has actually deleted my cookies as the GUI suggests, I sometimes check my ~/Library/Cookies folder where Safari and other applications store cookies in files with names like com.apple.appstore.cookies, Cookies.binarycookies, and a file I had never seen before called HSTS.plist.  

A quick Google search revealed very little pertaining to this particular HSTS.plist file, but HSTS may stand for HTTP Strict Transport Security, a web standard that allows web servers to mandate browsers interact with it using only HTTPS connections.  I was surprised to see my previous (as in pre-Mavericks) browsing history comprised of over 100 sites I had visited within the past few months listed in this ~/Library/Cookies/HSTS.plist file.



HSTS.plist Structure

Opening my ~/Library/Cookies/HSTS.plist file in TextWrangler revealed the following structure:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”&gt;
<plist version=”1.0″>
<dict>
<key>com.apple.CFNetwork.defaultStorageSession</key>
<dict>
<key>HSTS Content Version</key>
<integer>1</integer>
<key>HSTS Store Schema Version</key>
<integer>2</integer>
<key>accounts.google.com</key>
<real>-infinity</real>

 <… and so on, with “real” values of either infinity or -infinity ..>

</dict>
<key>hstsd Disk Storage Schema Version</key>
<integer>1</integer>
</dict>
</plist>

Perhaps oddly, I also found no search results when I searched Google for “hstsd Disk Storage Schema Version”.

This ~/Library/Cookies/HSTS.plist file contained browsing history that I apparently had no way of permanently deleting, and which could potentially be used as a fingerprint for tracking (if accessible via WebKit) by Apple or others. Another thing that amazed me was that this file persisted in the sense that the HSTS.plist file and its original contents were replaced within a few minutes—perhaps via iCloud syncing…even though this machine did not have iCloud or any “Internet Accounts” enabled—even after multiple iterations of disabling all plug-ins, “Reset Safari..”, toggling “Private Browsing” on and off, and restarting the machine plus all of the following:

– Closing Safari and other applications, deleting the HSTS.plist file, restarting
– Closing Safari and other applications, deleting the re-spawned HSTS.plist file, saving a blank text file to ~/Library/Cookies/HSTS.plist, making its permissions read-only and myself owner, and then restarting
– Logging in with another user’s account (with Administrator rights), deleting the HSTS.plist file, and restarting
– Logging in with another user’s account (with Administrator rights), deleting the HSTS.plist file, saving a blank file with the same filename in that file’s location, setting its permission to read-only with another user as the owner, and then restarting

Using fseventer, I was able to see that this HSTS.plist file (and the browsing history it contained) re-spawning behavior occurred whenever I opened Safari and toggled Private Browsing mode. At least on this machine, HSTS.plist never re-spawns itself unless I’m connected to the internet.

This leaves me puzzled, so I would appreciate any reactions or responses you may have in the comments.  Could this be:
– malware?  This seems less likely, since a scan of the hard drive in safe mode with clamXav turned up clean.
– an artifact of a previous non-standard configuration?  Perhaps this behavior is somehow related to something like Safari Mobile Bookmarks Sync (which I had disabled), or some sort of upgrade hiccup associated with upgrading a fully-patched copy of OS X Mountain Lion 10.8.5 to OS X Mavericks 10.9 a few days prior?
– a potential new cookie-like vector that Apple and/or advertisers could potentially use to fingerprint users via a snapshot of their HTTPS browsing history, even when using Safari’s Private Browsing mode?  This would be an outrage.
– a new “feature” associated with Safari’s implementation of HSTS?  Given the potential privacy implications, this would also be an outrage.

Aside from completely wiping the machine and reinstalling everything from scratch, I’m not sure what to do to get this artifact of old browsing history off of my machine. Even if this ~/Library/Cookies/HSTS.plist is just a simple cache of HSTS-enabled websites visited, it’s highly undesirable because it leaks browsing history–even in Private Browsing mode, and even across the GUI-accessible history and cache-clearing functions–and appears to be a highly persistent potential vector for fingerprinting users.

Advertisements
Standard