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