I'm curious though if working around these is necessarily practical in the first place. I for <br>one am guilty of not contacting MySpace about their CDN causing the photo section to break<br>prior to fixing it with an exclusion pattern, same for Imageshack.us's zoom functionality, but<br>
shouldn't we first try to get in touch with the website to see if it's unintended and possibly a <br>bug. While we wait for their response, we could add the exclusion pattern, but wouldn't it be<br>better if we took a different approach? If we decide to start contact these websites, would it be<br>
a bad idea if we had a sort of form letter to help ruleset authors?<br><br>On the one hand though, I prefer portability almost all of the time, personally. With the Web <br>Developer tools that Firefox includes by default, it's fairly easy to see the requests and how<br>
they're being handled, etc. That's how I figured out the imageshack and MySpace exclusion<br>patterns. So maybe we could put together a bunch of best practices for finding the problem<br>with examples of good/clever exclusion patterns for ruleset authors.<br>
<br><div class="gmail_quote">On Thu, May 3, 2012 at 5:13 PM, Peter Eckersley <span dir="ltr"><<a href="mailto:pde@eff.org" target="_blank">pde@eff.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Adding CCs to the people I know who are interested in/working on proxy ports<br>
of HTTPS Everywhere to see if there are any strong opinions.)<br>
<br>
Yes, at the expense of things breaking. The alternative would be to keep<br>
trying to do things like Negres did below, which would be more portable to<br>
proxies but harder for ruleset authors.<br>
<br>
It's a tricky tradeoff; making bugfixing easier for ruleset authors is very<br>
important, but it also may be that proxies are the best/only way to get things<br>
like Android ports of HTTPS Everywhere in the future.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, May 03, 2012 at 04:16:51PM -0400, Alex Xu wrote:<br>
> They can always just ignore the onpage exclusion, like<br>
> HTTPS-Everywhere is now.<br>
><br>
> On 12-05-03 01:36 PM, Peter Eckersley wrote:<br>
> >In a few instances, we seem to have bugs due to rulesets that rewrite static<br>
> >resource URLs hosted by CDNs. A common pattern is that something about the<br>
> >first party site is unhappy when the third party material becomes HTTPS.<br>
> >It would, however, be less than ideal to disable a CDN ruleset just because a<br>
> >small fraction of the sites that use the CDN have these bugs.<br>
> ><br>
> >In some cases, Negres and perhaps other ruleset authors have been able to hack around<br>
> >these bugs with clever exclusions:<br>
> ><br>
> ><a href="https://gitweb.torproject.org/https-everywhere.git/blobdiff/19d876ffe580285386b7c58a41a51a5df23384ed..af45142e4daf5ed8ad2a2bb5bafee1e043b20181:/src/chrome/content/rules/AmazonAWS.xml" target="_blank">https://gitweb.torproject.org/https-everywhere.git/blobdiff/19d876ffe580285386b7c58a41a51a5df23384ed..af45142e4daf5ed8ad2a2bb5bafee1e043b20181:/src/chrome/content/rules/AmazonAWS.xml</a><br>
> ><br>
> >However, there seem to be other cases where we haven't fixed them yet:<br>
> ><br>
> ><a href="https://trac.torproject.org/projects/tor/ticket/4593" target="_blank">https://trac.torproject.org/projects/tor/ticket/4593</a><br>
> ><a href="https://trac.torproject.org/projects/tor/ticket/5703" target="_blank">https://trac.torproject.org/projects/tor/ticket/5703</a><br>
> ><a href="https://trac.torproject.org/projects/tor/ticket/4199" target="_blank">https://trac.torproject.org/projects/tor/ticket/4199</a><br>
> ><br>
> >My question is: will the sort of method that Negres used above work for all of<br>
> >these kinds of bugs, or do we need a new kind of exclusion that is based, not<br>
> >on the URL of the resource being loaded, but on the URL of the top-level page<br>
> >being loaded?<br>
> ><br>
> >So the cloudfront rule could have something like this:<br>
> ><br>
> ><exclusion onpage=".*<a href="http://goodreads.com/" target="_blank">goodreads.com/</a>"><br>
> ><br>
> >which would prevent it from operating on <a href="http://goodreads.com" target="_blank">goodreads.com</a>.<br>
> ><br>
> >One /disadvantage/ of taking this road is that it would make life harder for<br>
> >people who want to build and use proxy-based ports of HTTPS Everywhere. I<br>
> >know there are several such projects out there, including plans to support<br>
> ><securecookie> via MITMproxy.<br>
> ><br>
> ><br>
><br>
> _______________________________________________<br>
> HTTPS-everywhere mailing list<br>
> <a href="mailto:HTTPS-everywhere@mail1.eff.org">HTTPS-everywhere@mail1.eff.org</a><br>
> <a href="https://mail1.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://mail1.eff.org/mailman/listinfo/https-everywhere</a><br>
<br>
</div></div><div class="im HOEnZb">--<br>
Peter Eckersley <a href="mailto:pde@eff.org">pde@eff.org</a><br>
Technology Projects Director Tel <a href="tel:%2B1%20415%20436%209333%20x131" value="+14154369333">+1 415 436 9333 x131</a><br>
Electronic Frontier Foundation Fax <a href="tel:%2B1%20415%20436%209993" value="+14154369993">+1 415 436 9993</a><br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
HTTPS-everywhere mailing list<br>
<a href="mailto:HTTPS-everywhere@mail1.eff.org">HTTPS-everywhere@mail1.eff.org</a><br>
<a href="https://mail1.eff.org/mailman/listinfo/https-everywhere" target="_blank">https://mail1.eff.org/mailman/listinfo/https-everywhere</a><br>
</div></div></blockquote></div><br>