[HTTPS-Everywhere] Managing bugs due to CDN rulesets

[Peter Eckersley]

(Adding CCs to the people I know who are interested in/working on proxy ports
of HTTPS Everywhere to see if there are any strong opinions.)

Yes, at the expense of things breaking.  The alternative would be to keep
trying to do things like Negres did below, which would be more portable to
proxies but harder for ruleset authors.

It's a tricky tradeoff; making bugfixing easier for ruleset authors is very
important, but it also may be that proxies are the best/only way to get things
like Android ports of HTTPS Everywhere in the future.

On Thu, May 03, 2012 at 04:16:51PM -0400, Alex Xu wrote:
> 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.
> >
> >
> 
> _______________________________________________
> HTTPS-everywhere mailing list
> HTTPS-everywhere at mail1.eff.org
> https://mail1.eff.org/mailman/listinfo/https-everywhere

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