EFForg/https-everywhere — pull request #172 by semenko (2014-02-22 20:52:57+00:00)
Title: Chrome: Remove blocking HTTP header listener

(For issue #12)

After thinking about this more, this function seems insane. I think we should
remove it for a lot of reasons. Here are the big ones:

1: Performance

We want wider HTTPS Everywhere adoption, and performance is the big limiting
factor here. The biggest complaints are still "it's slow," and blocking all
HTTP request headers to loop over & reconstruct cookies is nuts.

Testing on a CR-48 & other CPU-limited machines, HTTPS Everywhere still causes
a significant performance/battery hit (*especially* this single function).

2: It doesn't really work right

If the comments are any indication ("XXX I have no idea..."):

The if(ruleset) code doesn't actually secure any cookies -- it just adds the
ruleset to the tab, but doesn't append a new secure cookie to the newCookies
array.

3: The race condition this "prevents" seems just silly

The old justification for this function is it prevents a race-condition, but
wow, that's insanely hard to replicate. After running with some alert()s for
some time, I can't even get the warning in question to trigger.

To really steal a cookie here, you'd need:
- A site that supports HTTPS
- and is in our rulesets
- and has appropriately scoped, secureable cookies
- and sets them without the HTTPS Only flag
- and they're interesting enough to steal

AND

- An active, MITM attacker that controls a subdomain of interest
- with the ability force the user to visit an HTTP page
- with millisecond-level timing precision

This just seems silly to me. If you're controlling HTTP subdomains & any
sites the end-user is visiting, this seems like it's simultaneously the most
complex and also most meaningless attack you could mount.

Signed-off-by: Nick Semenkovich \