[HTTPS-Everywhere] Managing bugs due to CDN rulesets

[Russell Golden]

On Thursday, May 3, 2012, Colonel Graff wrote:

> 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?


Absolutely.


> 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.


I would love to see this. As a downstream packager, I have a responsibility
to get as much information as I can before forwarding a bug to you guys. I
did not do this in my last email, and we all saw the results: not a bug,
wasted people's time.

With a best practices document, I could direct people (and myself) on how
to gather this information, and try to prevent you guys from getting bogus
bug reports.

Pyramid quote clipped.


-- 
Russell Golden
Fedora Project Contributor
niveusluna at niveusluna.org
(972) 836-7128
--
"We are the Borg. Lower your shields and surrender your ships. We will add
your biological and technological distinctiveness to our own. Your culture
will adapt to service us. Resistance is futile."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20120504/435a3d4d/attachment.html>