@@ -402,7 +402,7 @@ Unfortunately, many aspects of browser state can serve as identifier storage, an
...
@@ -402,7 +402,7 @@ Unfortunately, many aspects of browser state can serve as identifier storage, an
**Implementation Status**: We isolate the content and image cache to the URL bar domain by setting privacy.firstparty.isolate to true.
**Implementation Status**: We isolate the content and image cache to the URL bar domain by setting privacy.firstparty.isolate to true.
Furthermore there is the [CacheStorage API]https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage(). That one is currently not available in Tor Browser as we do not allow third party cookies and are in Private Browsing Mode by default. As the cache entries are written to disk the CacheStorage API [got disabled](https://bugzilla.mozilla.org/show_bug.cgi?id=1173467) in that mode in Firefox, similar to how IndexedDB is handled. There are [thoughts](https://bugzilla.mozilla.org/show_bug.cgi?id=1117808) about enabling it by providing a memory-only database but that is still work in progress. But even if users are leaving the Private Browsing Mode and are enabling third party cookies the storage is isolated to the URL bar domain by `privacy.firstparty.isolate` set to **true**.
Furthermore there is the [CacheStorage API](https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage). That one is currently not available in Tor Browser as we do not allow third party cookies and are in Private Browsing Mode by default. As the cache entries are written to disk the CacheStorage API [got disabled](https://bugzilla.mozilla.org/show_bug.cgi?id=1173467) in that mode in Firefox, similar to how IndexedDB is handled. There are [thoughts](https://bugzilla.mozilla.org/show_bug.cgi?id=1117808) about enabling it by providing a memory-only database but that is still work in progress. But even if users are leaving the Private Browsing Mode and are enabling third party cookies the storage is isolated to the URL bar domain by `privacy.firstparty.isolate` set to **true**.
Finally, we have the asm.js cache. The cache entry of the script is (among others things, like type of CPU, build ID, source characters of the asm.js module etc.) keyed [to the origin of the script](https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/). Lacking a good solution for binding it to the URL bar domain instead we decided to disable asm.js for the time being by setting `javascript.options.asmjs` to **false**. It remains to be seen whether keying the cache entry e.g. to the source characters of the asm.js module helps to avoid using it for cross-origin tracking of users. We did not investigate that yet.
Finally, we have the asm.js cache. The cache entry of the script is (among others things, like type of CPU, build ID, source characters of the asm.js module etc.) keyed [to the origin of the script](https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/). Lacking a good solution for binding it to the URL bar domain instead we decided to disable asm.js for the time being by setting `javascript.options.asmjs` to **false**. It remains to be seen whether keying the cache entry e.g. to the source characters of the asm.js module helps to avoid using it for cross-origin tracking of users. We did not investigate that yet.
