[HTTPS-Everywhere] Incompatibilities between HTTPS Everywhere for Chrome and Keep {My, More} Opt Outs

[Mike West]

Yes, sorry. I'll be making some changes to KMOO in the near future, and
I'll certainly poke at this as I do that. Thanks for giving me an
actionable bug report. :)

-mike

--
Mike West <mkwst at google.com>, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


On Tue, Feb 12, 2013 at 5:18 AM, Dan Auerbach <dan at eff.org> wrote:

> Just wanted to bump this thread. Mike, will you have a chance to look at
> this soon? I imagine it will be an easy fix.
>
> On 02/01/2013 06:59 PM, Dan Auerbach wrote:
> > Hi Mike,
> >
> > I think what's happening is described in the last comment here:
> > https://trac.torproject.org/projects/tor/ticket/8132
> >
> > Basically, Chrome's cookie API considers changes to a cookie's attribute
> > as two separate delete and recreate steps
> > (http://developer.chrome.com/extensions/cookies.html). When HTTPS
> > Everywhere's listener sees a cookie without secure flag being set, we
> > change it to have a secure attribute.  This first step (deletion of
> > cookie) fires the onChanged event, which KMOO listens to and says "oh
> > no, someone tried to delete my opt-out cookie, let me recreate it". Now,
> > KMOO waits 5 seconds and presumably HTTPS Everywhere has already written
> > the alternative cookie with secure flag by then. So why is KMOO still
> > writing the cookie sans secure flag again? The reason seems to be the
> > "set" method of KMOO.Cookie:
> >
> >
> https://code.google.com/p/chrome-opt-out-extension/source/browse/trunk/chrome/KMOO.Cookie.js#109
> >
> > This does NOT use domain to search for relevant cookies via
> > chrome.cookies.get, but rather uses URL (with hardcoded http scheme for
> > the cookies by default, see
> >
> https://code.google.com/p/chrome-opt-out-extension/source/browse/trunk/chrome/KMOO.PolicyRegistry.js#85
> ).
> > The documentation isn't clear but it seems that a URL is required for
> > this API method. Ideally the API would allow you to pass in a domain
> > instead of a URL. But in the interim, it seems to me that the KMOO code
> > could hack around this. Thoughts?
> >
> > Thanks for helping to get this resolved,
> > Dan
> >
> > On 11/02/2012 06:09 PM, Peter Eckersley wrote:
> >> Sorry, that was the wrong line number:
> >>
> >>
> https://gitweb.torproject.org/https-everywhere.git/blob/c343f230a49d960dba90424799c3bacc2325fc94:/chromium/background.js#l145
> >>
> >> On Fri, Nov 02, 2012 at 06:06:08PM -0700, Peter Eckersley wrote:
> >>> Our cookie wrangling code is here:
> >>>
> >>>
> https://gitweb.torproject.org/https-everywhere.git/blob/c343f230a49d960dba90424799c3bacc2325fc94:/chromium/background.js#l199
> >>>
> >>> it looks as though the way we modify the secure flag is by recreating
> the
> >>> whole cookie, which might be the wrong way to do it...
> >>>
> >>> On Sat, Nov 03, 2012 at 12:56:47AM +0100, Mike West wrote:
> >>>> -BCC other googlers.
> >>>>
> >>>> Keep My Opt-Outs is me. Keep More Opt-Outs is a fork, as is "Protect
> My
> >>>> Choices" and probably others. :)
> >>>>
> >>>> KMOO watches for changes to cookies and overwrites them if they
> diverge
> >>>> from the opt-out text specified in the registry. If the name and
> domain
> >>>> match, it should simply leave them alone:
> >>>>
> http://code.google.com/p/chrome-opt-out-extension/source/browse/trunk/chrome/KMOO.Cookie.js#97
> >>>>
> >>>> Is HTTPSEverywhere modifying the cookies in ways other than setting
> the
> >>>> secure flag?
> >>>>
> >>>> --
> >>>> Mike West <mkwst at google.com>, Developer Advocate
> >>>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> >>>> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255
> 91
> >>>>
> >>>>
> >>>> On Sat, Nov 3, 2012 at 12:36 AM, Peter Eckersley <pde at eff.org> wrote:
> >>>>
> >>>>> (Sorry for CCing a bunch of googlers, hopefully one of you can route
> this
> >>>>> to
> >>>>> real KMOO developer(s))
> >>>>>
> >>>>> In Chrome, it seems that HTTPS Everywhere has an incompatibility
> with two
> >>>>> extensions, called Keep More Opt Outs and Keep My Opt Outs.  These
> >>>>> extensions
> >>>>> attempt to police and preserve "opt-out" cookies for a bunch of
> advertising
> >>>>> and tracking domains.
> >>>>>
> >>>>> Unfortunately they seem to fight against HTTPS Everywhere's attempts
> to
> >>>>> turn
> >>>>> on the "secure" flag in some of those cookies.  I haven't looked
> closely at
> >>>>> the precise API hooks through which that's occurring, but it can be
> >>>>> discussed
> >>>>> in this ticket:
> >>>>>
> >>>>> https://trac.torproject.org/projects/tor/ticket/7099
> >>>>> (make an account to post there, or use the anonymous one which is
> >>>>> "cypherpunks" / "writecode")
> >>>>>
> >>>>> In my experience, reproducing is faster and easier with Keep More
> Opt Outs;
> >>>>> just install the two extensions, browse around for a bit, and watch
> the
> >>>>> infinite loops start.
> >>>>>
> >>>>> --
> >>>>> Peter Eckersley                            pde at eff.org
> >>>>> Technology Projects Director      Tel  +1 415 436 9333 x131
> >>>>> Electronic Frontier Foundation    Fax  +1 415 436 9993
> >>>>>
> >>> --
> >>> Peter Eckersley                            pde at eff.org
> >>> Technology Projects Director      Tel  +1 415 436 9333 x131
> >>> Electronic Frontier Foundation    Fax  +1 415 436 9993
> >>>
> >
>
>
> --
> Dan Auerbach
> Staff Technologist
> Electronic Frontier Foundation
> dan at eff.org
> 415 436 9333 x134
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20130212/a496887b/attachment.html>