Some potential other things to test at the network layer

[MattMenke2]

Disclaimer: I'm not sure how practical most of these are to test, and a lot of these are a bit on the obscure side. I've mentioned most of these on docs I've published, which may or may not be on your radar:

• CORS preflght cache (https://fetch.spec.whatwg.org/#concept-cache)
• DNS over HTTPS connections
• DNS cache (unfortunately, this is mostly detectable through timing, and upstream resolver caches or even platform caches can confuse the issue, though platform caches in particular also make this harder to partition meaningfully).
• Live DNS requests. Possible these are merged even if the DNS cache is not, though seems unlikely.
• Cert validation requests (AIA, OCSP). These are often offloaded to the OS, unfortunately. Anyhow, by serving up bogus certs which require AIA to fetch bogus intermediaries, which certs a user has cached as being bad are potentially a tracking vector.
• H2 support cache. Not sure if all browsers support this, but Chrome keeps a cache of which servers support H2, and only establishes one connection to them at a time. This is separate from the alt service cache.
• QUIC brokenness cache. Not sure if all browsers do this, but Chrome keeps a cache of which advertised H3 servers it can't connect to (It also disables QUIC globally if it has too many QUIC issues, though not familiar with the logic there. Just mention this because it could cause confusion in tests. It's also one bit of fingerprint information, potentially, I suppose)
• Expect-CT reports (which need to not share sockets with anything from another tab). Edit: I not sure if Expect-CT is long for this world, once CT becomes mandator on all requests.

[arthuredelstein]

Hi! Thanks for this great list. I will look into these.

[MattMenke2]

Took a look at my old doc, and found a couple others. Some of these are likely even straightforward to test:

• WebSockets (which touch other network state, and can share H2/H3 sessions, and can possibly steal sockets previously used for H1 as well, depending on the implementation)
• Media device ID / EME (not sure if these are two things or the same thing - I'm mostly a network person)
• SSL session resumption cache
• HTTP auth credential cache (unclear if this should be partitioned - definitely should be if embedded credentials are automatically added)
• Client cert cache (similar boat to the auth cache, also unclear if it should be partitioned)
• Proxied connection (H1/H2/H3/socks) shouldn't be reused between requests from different network partitions.

Anyhow, there are an absurd number of leaks, and difficult to test them all, was just impressed by how comprehensive these tests are, and thought I'd add some more ideas.

[arthuredelstein]

Fantastic! Thanks again.

[Thorin-Oakenpants]

FYI: from https://github.com/arthuredelstein/privacytests.org/issues/70#issuecomment-966242104

rather than create a new issue or email you ... FYI

• what's on this list not in your tests - IANAE but e.g. I don't see DNS, WebSocket, OCSP, HKPK in a very quick first glance
  • note: websocket dFPI/FPI was added in FF92+
• also https://groups.google.com/g/mozilla.dev.platform/c/uDYrtq1Ne3A - I don't see CORS pre-flight, preconnect, Intermediate CA cache, speculative connections, or connection pooling

I don't know what you can or want to test, and or if some of those are aliases/redundant (e.g. under prefetch) - I'll just leave this in your capable hands

FYI: from https://github.com/arthuredelstein/privacytests.org/issues/80#issuecomment-1008282746

I have some ideas

• under navigation test? beacon, link-pre-fetching, predictor
• sanitizing: e.g. cache/HSTS etc, cookies + site data, etc
  • will look impressive for AF/LW and of course TB (being in PB Mode)
• a "security" section: e.g. the five safebrowsing types

[arthuredelstein]

Thanks @Thorin-Oakenpants ! I have added all your items to my spreadsheet.