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

[Mike Perry]

Peter Eckersley:
> On Fri, Jan 17, 2014 at 06:37:02PM -0800, Mike Perry wrote:
>  
> > 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?
> 
> We should measure this.  But we should definitely measure it in the case
> where the entire sqlite file is in the OS page cache, so in TBB we
> should /definitely/ read and discard its entire contents before playing.

Yes. Having solid numbers here would make me feel better about this.

It would also be useful to have an observer event or https-everywhere
API call so that I could clear any caching during "New Identity" in Tor
Browser.

It might be nice if the page cache priming code also lived in
HTTPS-Everywhere, as a function or observer that I could call (rather
than baking in this hackery into a different addon and suffering from
bitrot if the sqlite location changes or something).

> > 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. :/
> 
> Unfortunately I fear they're actually larger because of all the pointers
> and JavaScript book-keeping.  I've tried to measure that by just looking
> at the RSS of the firefox process with and without HTTPSE enabled:
> 
> https://trac.torproject.org/projects/tor/ticket/4804

Ok, I just redid this analysis along with some diffing of about:memory,
and the results are roughly a 48M RSS reduction by using the sqlite
version as opposed to the version 3 commits prior, and a further 10M RSS
reduction if HTTPS-Everywhere is uninstalled entirely. ps's RSS
reporting and Firefox's about:memory were roughly consistent, give or
take a couple megs.

This was on a 64 bit Linux machine, and I also hacked the "3X ruleset
loading" bug to not happen in either test.


-- 
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/0e90e6db/attachment-0001.sig>