[HTTPS-Everywhere] Managing bugs due to CDN rulesets

[Colonel Graff]

I'm curious though if working around these is necessarily practical in the
first place. I for
one am guilty of not contacting MySpace about their CDN causing the photo
section to break
prior to fixing it with an exclusion pattern, same for Imageshack.us's zoom
functionality, but
shouldn't we first try to get in touch with the website to see if it's
unintended and possibly a
bug. While we wait for their response, we could add the exclusion pattern,
but wouldn't it be
better if we took a different approach? If we decide to start contact these
websites, would it be
a bad idea if we had a sort of form letter to help ruleset authors?

On the one hand though, I prefer portability almost all of the time,
personally. With the Web
Developer tools that Firefox includes by default, it's fairly easy to see
the requests and how
they're being handled, etc. That's how I figured out the imageshack and
MySpace exclusion
patterns. So maybe we could put together a bunch of best practices for
finding the problem
with examples of good/clever exclusion patterns for ruleset authors.

On Thu, May 3, 2012 at 5:13 PM, Peter Eckersley <pde at eff.org> wrote:

> (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
>
> _______________________________________________
> HTTPS-everywhere mailing list
> HTTPS-everywhere at mail1.eff.org
> https://mail1.eff.org/mailman/listinfo/https-everywhere
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20120503/9da9fbdc/attachment.html>