[HTTPS-Everywhere] HTTPS Everywhere & insecure JS in Chrome

[Peter Eckersley]

Recent versions of Chromium have a security feature, which is that on HTTPS
pages Chromium refuses to load insecure JavaScript (and possibly CSS?) by
default, instead rendering the page without that content, and offering the
user a button to load it manually.

This is definitely a good design choice, since it pushes the admins
of insecure HTTPS sites to fix their stuff, and it gives users who want to be
more secure a way to get that.

This Chromium feature interacts interestingly with HTTPS Everywhere, though.
Because we turn on HTTPS on a lot of pages where site admins werent't 
expecting it, we cause Chromium to block a lot of script loads until the user
clicks "yes" to allow them (this shouldn't be confused with the other annoying
CSS-fails-to-load bug we have on Chrome, which will hopefully be fixed soonish
https://trac.torproject.org/projects/tor/ticket/5585).

Now I'm pretty sure that this is the right experience for security-conscious
power users, who are probably pleased to see nytimes.com render the way it
does with HTTPS Everywhere for Chrome.  But I doubt it's the right default for
everyone.

I think there are several ways to try to fix this:

0. Don't fix it.  HTTPS Everywhere for Chrome will be maximally secure, but
will cause a lot of sites to render without scripts by default.  Unfortunately
I think this will seriously limit our userbase (we have millions of Firefox users,
and only about 100K users for the Chrome alpha/beta right now due in part to
issues like this)

1. Disable all the rulesets that cause mixed scripting loads in Chromium by
default (!!!), with a button to turn them all back on for power users.

2. Try to land a patch to Chromium to let us tell the browser "hey we're
redirecting this request from HTTP to HTTPS, but please allow it to load
subsidiary content via HTTP".  Presumably this would require modifying the Web
Request API somewhere, perhaps by adding an additional tolerateMixedContent
parameter to webRequest.BlockingResponse.   Again, power users could tweak a
setting to make tolerateMixedContent always be false.

Option 2 is better than 1 because mixed content is generally better than pure HTTP
content (partial HTTPS still hides a lot from passive eavesdroppers, even if
active JS injection attacks remain possible).  But 2 will require help from
the Chrome team (Adam, what do you think of this?).

-- 
Peter Eckersley                            pde at eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993