Re: [HTTPS-Everywhere] persistent user-generated rules

On Fri, Jan 17, 2014 at 12:56 AM, Drake, Brian wrote: > Are you aware that you’re disclosing your e-mail address? Probably, though > not necessarily. What about other information? [1] Perhaps I’m being > unreasonably picky here. > > Relating e-mails and HTTP in terms of third parties sniffing the

[HTTPS-Everywhere] Is the "https-everywhere-uri-rewrite" nsIObserver topic obsolete?

Working on the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=939180 made me realise that we aren't going to be firing our nsIObserver notification when we do rewrites with the new, sane, channel.redirectTo() rewrite API that came out of https://bugzilla.mozilla.org/show_bug.cgi?id=765934 I

[HTTPS-Everywhere] 4.0development.14 released

Sorry we're somewhat behind on merging contributions from the list and bug tracker at the moment! Hopefully we will be caught up shortly. >From the Changelog: https://www.eff.org/files/https-everywhere-4.0development.14.xpi 4.0development.14 (2013-11-21) * Deprecat

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

Particularly in the master branch (ie, Firefox HTTPSE version 4.x), the 10,000 rulesets that we need to parse in from XML are starting to add problematic amounts of latency to browser load time. Unfortunately we can't postpone this work until after the browser has started because we don't know whe

Re: [HTTPS-Everywhere] 3.4.3

Sorry, yes, the tag should be there now. On Wed, Dec 04, 2013 at 10:10:38AM -0800, Yan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > On 12/04/2013 08:52 AM, Jérémy Bobbio wrote: > > Yan: > >> HTTPS Everywhere 3.4.3 has been released: […] > > > > It looks like I there's no ma

Re: [HTTPS-Everywhere] redesign suggestions

I like the design for the menu. It should also have a "disable | enable https everywhere" button, I think. I have grown fond of our current icon, though I think it does suffer from illegibility when rendered in very small / low resolution versions, which this alternative design may handle a bit b

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

> It's suspicious to me that the parser is almost exactly twice as fast in > Chrome as it is in Firefox. But either way, Mike and I are hacking > today on a way to fix these problematic slowdowns at browser load time. You might be interested in the SQLite branch I emailed about last week. I think

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

For what it's worth, I did a quick test converting the XML rulesets to JSON. Parsing the resulting JSON string took 0.06 seconds, were as on my machine parsing the XML rulesets took 1.61 seconds. It seems this means we want to convert the XML to JSON during build time, whichever way we go with act

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

On Fri, Jan 17, 2014 at 5:39 PM, Peter Eckersley 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 sqlit

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

On Sat, Jan 18, 2014 at 1:40 AM, Mike Perry wrote: > I still believe it is easier for humans to actually write rules in XML > rather than JSON, though. > Agreed, but there might be a workaround: Since rules are bundled in the default.rulesets file when ./makexpi.sh is run, it may be possible to e

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

Jacob Hoffman-Andrews: > On Fri, Jan 17, 2014 at 5:39 PM, Peter Eckersley 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 dis

[HTTPS-Everywhere] Old Messages

It looks like a few old messages just got delivered, to me at least. It’s obvious here because, when this happens, Gmail displays different dates on the message list and individual messages. -- Brian Drake All content created by me: Copyright

Re: [HTTPS-Everywhere] Mixed Content Blocker

On Wed, Jan 15, 2014 at 0622 (UTC), Jacob Hoffman-Andrews wrote: > On 01/14/2014 1452 (UTC), Drake, Brian wrote: > > The first thing to do is to get some decent documentation on how things > > work now > > You're right, we do need better documentation. Right now the only mention > on the HTTPS Eve

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

Ooops, sorry, I wasn't following the list closely enough. We haven't replicated any of your work, yet. 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 g

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

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 b

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

On Fri, Jan 17, 2014 at 05:51:13PM -0800, Jacob Hoffman-Andrews wrote: > > > 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. > > > This is one of the things I like about it. Also it reduces memory use, > which is

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

On Sat, Jan 18, 2014 at 02:33:19AM +, Claudio Moretti wrote: > On Sat, Jan 18, 2014 at 1:40 AM, Mike Perry wrote: > > > I still believe it is easier for humans to actually write rules in XML > > rather than JSON, though. > > > > Agreed, but there might be a workaround: Since rules are bundled

Re: [HTTPS-Everywhere] Old Messages

Yes, they were stuck in a mailman moderator queue or for reasons for obscure and hopefully historical reasons. On Sat, Jan 18, 2014 at 10:42:23AM +0800, Drake, Brian wrote: > It looks like a few old messages just got delivered, to me at least. It’s > obvious here because, when this happens, Gmail

Re: [HTTPS-Everywhere] Mixed Content Blocker

Here is the first post to elaborate on my previous comment; later, I want to try to summarise the main discussion/decisions/commits on this, because it seems to be spread over too many places. This post is to discuss what seems like a fundamental flaw in the current handling of mixed content. Can

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

On 01/17/2014 06:37 PM, Mike Perry wrote: > In TBB, we isolate the browser cache per the URL bar domain Nice! I learn something new every day. We could have a 'paranoid mode' for TBB that uses a webworker on startup to preload all the rules, removing the timing oracle. Though your 0.06 seconds t

Re: [HTTPS-Everywhere] Mixed Content Blocker

> 1. We handle both cases by adding platform="mixedcontent" and restricting > the rules to type 3 browsers. > 2. If type 2 browsers became available, there would be no easy way of > telling which rules should be enabled on those browsers, nor would there be > any way of actually doing so (while kee

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

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 any

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

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. H

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

On Fri, Jan 17, 2014 at 08:43:47PM -0800, Peter Eckersley wrote: > Calling potentiallyApplicableRulesets() with 1 domains > 1088 hits: average call to potentiallyApplicableRulesets took 0.157 > milliseconds > 1088 hits: average subsequent call to potentiallyApplicableRulesets took > 0.0513

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

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

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Porting the LRU cache from Chrome to FF is high on my to-do list, but if Nick wants to do it, he gets lots of <3's. HI NICK. - -Yan On 01/17/2014 09:41 PM, Peter Eckersley wrote: > On Fri, Jan 17, 2014 at 05:51:13PM -0800, Jacob Hoffman-Andrews > w

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

On 01/17/2014 08:56 PM, Peter Eckersley wrote: > If I run the test in master without the "www." prefixes, I get 1161 > hits; in the sqlite branch it's only 68. So I suspect a fencepost error > or similar... I found the bug: I had accidentally deleted the piece of the code that attempts bare hostn