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
signature.asc
Description: Digital signature
_______________________________________________ HTTPS-Everywhere mailing list [email protected] https://lists.eff.org/mailman/listinfo/https-everywhere
