On 8/17/11 5:21 AM, Jean-Marc Desperrier wrote: > Also, at the moment it seems that Firefox's private mode doesn't > properly protect against this.
That's a problem. We've tried hard to prevent disk writes in Private Browsing mode, but I think the cache got a pass because performance in Private Browsing mode would be too painful without it. Even without ETags there's some information that can be gleaned about site visits using timing attacks. We definitely don't want to blow away the non-private-mode cache when we go into and out of private mode (switching would take too long, and some users would notice the bad performance after switching back) but we could potentially set up an extra private-mode cache. Pretty expensive in disk-space but might be worth it if a lot of people spend time in private mode. Another alternative could be to use only the memory cache in private mode, that's a bit quicker to blow away when we switch modes. Neither suggestion helps the ETags issue for users who stay within one mode or the other; for now I'm focused only on the narrow issue of leakage between modes which is a problem even if we solve the ETags issue. > I wonder if the end result could be to disable ETags and replace > Last-Modified with a neutered header, where : > - the browser formats the strings > - only recent requests are precise, older one have a much bigger range If we want to pretend to be a HTTP/1.0 dumb client we could do that, yeah. Slightly better would be to remain HTTP/1.1-compliant for same-origin requests and only play such games with "3rd party" requests. Unfortunately "3rd" party sometimes includes the 1st party's CDN. On the assumption the CDN content is likely to be strictly static assets rather than personalized content dropping 3rd party ETags might still work out. On the modified dates if you assume clocks are perfectly in sync (ha!) in theory you could safely send back any time between the Last-Modified date and when the browser requested the content. In practice there's clock skew, and some caches might do something dumb (but fast) like "if (browser-date != my-stored-date) send-it". Either issue leads to a lot of cache misses, bad performance, and on mobile perhaps huge bills for exceeding data caps. When the bad guys (or at least slimy ones) use the specs against you any defense means breaking legitimate uses. -Dan Veditz _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
