[HTTPS-Everywhere] Managing bugs due to CDN rulesets

[Peter Eckersley]

In a few instances, we seem to have bugs due to rulesets that rewrite static
resource URLs hosted by CDNs.  A common pattern is that something about the
first party site is unhappy when the third party material becomes HTTPS.
It would, however, be less than ideal to disable a CDN ruleset just because a
small fraction of the sites that use the CDN have these bugs.

In some cases, Negres and perhaps other ruleset authors have been able to hack around
these bugs with clever exclusions:

https://gitweb.torproject.org/https-everywhere.git/blobdiff/19d876ffe580285386b7c58a41a51a5df23384ed..af45142e4daf5ed8ad2a2bb5bafee1e043b20181:/src/chrome/content/rules/AmazonAWS.xml

However, there seem to be other cases where we haven't fixed them yet:

https://trac.torproject.org/projects/tor/ticket/4593
https://trac.torproject.org/projects/tor/ticket/5703
https://trac.torproject.org/projects/tor/ticket/4199

My question is: will the sort of method that Negres used above work for all of
these kinds of bugs, or do we need a new kind of exclusion that is based, not
on the URL of the resource being loaded, but on the URL of the top-level page
being loaded?

So the cloudfront rule could have something like this:

<exclusion onpage=".*goodreads.com/"> 

which would prevent it from operating on goodreads.com.

One /disadvantage/ of taking this road is that it would make life harder for
people who want to build and use proxy-based ports of HTTPS Everywhere.  I
know there are several such projects out there, including plans to support
<securecookie> via MITMproxy.


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