[HTTPS-Everywhere] Startup time measurements in Chrome and Firefox

[Mike Perry]

Jacob Hoffman-Andrews:
> On Fri, Jan 17, 2014 at 5:39 PM, Peter Eckersley <pde at eff.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140117/7fa148e1/attachment.sig>