Jacob Hoffman-Andrews: > On Fri, Jan 17, 2014 at 5:39 PM, Peter Eckersley <[email protected]> wrote: > > > Mike has been worrying about the oracle attack where someone measures > > performance differences to tell whether someone has visited site X > > before, based on whether their HTTPSE instance needs to go to disk to > > fetch a ruleset from sqlite. > > > > This is a good point, but it applies equally to testing for cached content > or DNS on site X, right?
Not for Tor Browser's case. In TBB, we isolate the browser cache per the URL bar domain, so third parties who perform this sort of probing can't probe for the cache presence of arbitrary URLs, only those urls which may have been loaded in an iframe or other content element from that same first party site. DNS is also handled as part of the SOCKS handshake (ie names go all the way to the Tor exit node) in the majority of cases. In cases where it is not, our plan is to use circuit-based isolation to keep the DNS cache similarly bound to the URL bar domain. So this would be exposing a global fingerprinting vector that didn't previously exist in TBB. OTOH, it would probably only be possible for the adversary to examine it once before it becomes useless to anyone else.. But once may be enough. How fast are these individual queries? Can we measure that, and what the impact is on total page performance for the cache hit and non-cache hit cases? I am especially worried about the sync SQLLite lookups as well, as you point out that may make people perceive the actual browser UI to get sluggish during page load, which is not good either. > > On the other hand, the SQLite solution should be let us scale not just > > to ~10K rulesets but if we're lucky to more like ~100K. 0.06 seconds for JSON is pretty quick (and 27X faster than XML on my machine). It is also possible that a lot of that time was spent setting up the parser, marshaling the object, and/or doing a JIT pass, and that a 10X increase in ruleset counts won't even mean 0.60s of JSON parsing, but something much lower. > This is one of the things I like about it. Also it reduces memory use, > which is especially valuable on mobile. Do we know how big the actual memory consumption is here? Right now, the plaintext xml rulesets are 3.6M on disk. I suspect once parsed they are smaller than that, but I am not seeing any easy way to get the memory usage for the actual parsed rulesets object. It seems the most common solution on the web is to manually traverse the thing and do some addition and approximation for each object type. :/ -- Mike Perry
signature.asc
Description: Digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
