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

[Mike Perry]

Peter Eckersley:
> On Fri, Jan 17, 2014 at 08:01:40PM -0800, Mike Perry wrote:
> > 
> > > 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.
> >
> 
> So I have implemented some performance tests in the sqlite branch of my
> github remote:
> 
> https://github.com/pde/https-everywhere/commits/sqlite
> 
> They operate by asking potentiallyApplicableRulesets() for each of the
> Alexa top 10K domains, measuring overall ellapsed time, then doing it
> again.  
> 
> Here's what I see:
> 
> Calling potentiallyApplicableRulesets() with 10000 domains
> 1088 hits: average call to potentiallyApplicableRulesets took 0.157 milliseconds
> 1088 hits: average subsequent call to potentiallyApplicableRulesets took 0.0513 milliseconds
> 
> So wrt Mike's fingerprinting concern, subsequent calls to
> potentiallyApplicableRulesets() are 3x faster (and will be more so if we
> put in the LRU cache) but the measurable difference is only a tenth of a
> millisecond, which will be hard to exploit given that this is over the
> top of the Tor network and repetitive measurement is impossible.

This is not quite certain yet. I did a bit of digging and there are at
least three potential ways to time the specific redirect operation from
JS, using microsecond precision timers (DOMHighResTimeStamps), without
waiting on the network.


The first one is Performance Navigation Timers:
http://www.w3.org/TR/2012/REC-navigation-timing-20121217/#sec-navigation-timing-interface

As you can see there, there is a breakout property for redirectStart and
redirectEnd.

However, right now it appears that Firefox is not filling in those
timestamps for internal redirects caused by our redirectTo API. This
might change without notice, though.


The second is Mutation Events that observe for DOMAttrModified event
changes to any element's src, href, or link attributes:
https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Mutation_events

Mutation events are deprecated due to performance costs, but they still
exist, and they do have a timestamp field (milliseconds only), and you
can also call window.performance.now() to get microseconds from inside
your event handler.


The third way is through Mutation Observers. Mutation observers are
meant to replace mutation events. Luckily they apparently are supposed
to be called in batch after the DOM is loaded/modified:
https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver

It's not clear to me what happens if a script is clever enough to wait
until after the main batch of DOM modifications happens. If it only
tries to create redirected elements after this point, will it get more
accurate, single-fire MutationRecord callbacks for just the redirect
updates that it can then call performance.now() inside of?


Did I miss any other ways of timing this operation? Am I wrong about any
of the above?

 

-- 
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/af15a15f/attachment.sig>