[HTTPS-Everywhere] Broken / bad rule feedback mechanism

[Claudio Moretti]

There might be a potential concern here: if an user is browsing a
restricted page, with some information in the URL, we might have a little
too much information disclosure...
On the other hand, stripping down the URL to the domain would probably be
useless, because if the rule is tested (and it is) before being pushed, it
would work in 99% of the cases.

Also, it might be a temporary downtime, and we'll be flooded with
complaints about something that, in reality, it's working...

There's some discussion that might be done on this and I, for one, have no
clue whatsoever on how this might be handled.

If somebody has an idea, it'll be great :)

(is it me or my email is pretty useless?)

Cheers,

Claudio


On Mon, Jan 13, 2014 at 8:16 PM, John Stinson <johnkstinson at gmail.com>wrote:

> Hey,
>
> I think this is independent of other discussions going on right now so I
> created a new thread (sorry for moar email).
>
> Has there ever been discussion of having a mechanism for users to report a
> bad transition (as a result of a bad rule) directly from the plugin? For
> instance, someone is redirected to an unexpected page, clicks on the
> https-everywhere icon, and is able to click on a "report a bad rule"
> button, that could send "us" data about the url, so we could act on
> correcting it?
>
> I'm not sure if the issue of bad rules is serious enough to warrant such
> an option, and I can also foresee some privacy implications with this, but
> just thought I'd mention the concept.
>
> --
> - John K. Stinson
>
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140113/c8cc9916/attachment.html>