[HTTPS-Everywhere] Managing bugs due to CDN rulesets

[Alex Xu]

They can always just ignore the onpage exclusion, like HTTPS-Everywhere 
is now.

On 12-05-03 01:36 PM, Peter Eckersley wrote:
> 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.
>
>