[HTTPS-E Rulesets] LastPass rule breaks extension functions

[Nyr]

Just received reply from they and didn't promised to fix the bug. They said
that will look at how difficult it would be to fix it on next versions but
nothing clear, so disabling the rule seems to be the only thing we can do.

PS: sorry, Peter for the double email, I forgot to CC it to the mailing
list.

2011/9/27 Peter Eckersley <pde at eff.org>

> This is an instance of a general bug we have with extensions that make HTTP
> requests which HTTPS Everywhere tries to rewrite into HTTPS requests:
>
> https://trac.torproject.org/projects/tor/ticket/3190
>
> There are three possible fixes:
>
> 1. We disable the LastPass rule :(
>
> 2. LastPass modifies its code to always use HTTPS, or to be aware of HTTPS
>   Everywhere in the same way that the Request Policy extension did:
>   https://trac.torproject.org/projects/tor/ticket/1574
>
> 3. Mozilla implements an official request rewriting API so that extensions
>   don't have to know about each other.
>
> We can do 1, but perhaps someone should post in that forum to see if
> LastPass
> woudl like to do 2?
>
> On Tue, Sep 27, 2011 at 09:17:03PM +0200, Nyr wrote:
> >  Hello,
> >
> > I had been using HTTPS Everywhere and LastPass extensions on my Firefox
> for some time and had found the cause because the LastPass extension logs
> out when Firefox is closed when it shouldn't. Apparently, having
> lastpass.com rule enabled causes this behavior and when disabled is
> solved.
> >
> > I think that rule should be rewritten (if possible) or disabled by
> default if can't be fixed, this seems to be a widespread issue:
> > http://forums.lastpass.com/viewtopic.php?f=12&t=77751&start=10
> >
>
> --
> Peter Eckersley                            pde at eff.org
> Technology Projects Director      Tel  +1 415 436 9333 x131
> Electronic Frontier Foundation    Fax  +1 415 436 9993
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere-rules/attachments/20110929/66f06e5a/attachment.html>