- Edited
State Partitioning
For background, see Brave blog post or Mozilla post
These are about preventing the sharing of any kind of state between two sites, which can provide a conduit between them for tracking or correlation of a user.
Test is to attempt to do a set from one first-party domain, then do a read from a different first party domain - there should be no sharing of state between the domains in these tests. The obvious trade-off is you lose benefits from caching on first visit to a site, and likely use more storage space on-disk with caches of the same content per-site (unless you build a smart overlay that then has a shared cache, but denies knowledge of an entry until it's cached... Which would be a bit complex to build I suspect).
Clicking the titles of tests on https://privacytests.org/ gives a small description of each, and clicking on a tick/cross shows the JS code used to do a test (generally).
In a loose priority order:
Delta against Safari
(These should be reasonably feasible, and are implemented in other browsers)
[ ] localStorage
[ ] XHR cache
[ ] CSS cache
[ ] Fetch cache
[ ] Font cache
[ ] iframe cache
[ ] image cache
Delta against the "ideal"
[ ] Favicon cache
[ ] prefetch cache
Navigation Tests
Delta against the "ideal"
[ ] sessionStorage (basically a per-tab session storage API that persists if you visit another site in the same tab) - this should be easy enough, as it should just be like visiting a site in a fresh tab.
HTTPS upgrading
(Trade-offs being that it attempts to load everything over HTTPS, which could result in a lot of failed requests, most likely)
There's an HTTPS mode in Orion, it didn't seem to pass this test for some reason, and I had it enabled for the test.
Delta against ideal world
[ ] Plain HTTP site
[ ] Auto-upgrade the URL bar entry to HTTPS where possible
[ ] Auto-upgrade clicked hyperlinks where possible
[ ] Auto-upgrade images in pages where possible
Other
There appears to be some standard called GPC that they look for implementation of.
A couple of other misc ones that maybe don't make sense to implement:
[ ] Blob URL (this seems a bit excessive to not permit them to be used at all, if that's what is being suggested... It's not clear)
[ ] document.referer (cross-domain, only the main domain is passed as referer, but I assume the test looks for an empty referer to be sent. Would this break sites?)
Most of the rest of the "gaps" look to be quite subjective, and would be for avoiding fingerprinting, while trading off compatibility with websites, so are probably worth revisiting separately.