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

[Dan Auerbach]

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