[feanaro]

> It seems both more straightforward and more effective to build recursion paths that you can trust aren't doing any intentional or unintentional caching.

I agree, but as you say, that will take quite some work and time to happen and will be costly. I was thinking of this as a possible temporary mitigation which would retain some benefits of caching. If it was made adaptive[1], it would also have the nice side-effect of being more resource intensive for those servers that attempt to use tracking.

[1] i.e. only fetch many responses if they appear to vary while doing a smaller number of "probing" requests. Continue fetching more responses for your local sample until they stop varying with some degree of confidence.

[DanielDent]

It would be difficult to differentiate between responses that vary due to load balancing and responses that vary due to active fingerprinting.

Even when a site only has a single physical location, load balancing might be done in part by having DNS randomly return one of many valid IP addresses. E.g. this is a behaviour supported by Amazon's Route53.

Larger sites frequently use a combination of anycast and DNS based routing to get packets to the closest POP. This introduces both (1) difficulty identifying when fingerprinting is occurring, and (2) still more opportunities for fingerprinting.

Most users will find it impossible to control which POP their packets get routed towards. For someone doing fingerprinting, it could be a very useful signal.

[feanaro]

Yes, but variation due to such load balancing would surely be limited in entropy in practical non-tracking scenarios?

Approaching from the other end, it points towards anycast itself (and similar techniques) being incompatible with hard tracking resistance.

I'm glad to see that Firefox containers already mitigate this by using a separate DNS cache for each container.