[Openid-specs-ab] Session management and third party cookies

Torsten Lodderstedt torsten at lodderstedt.net
Tue Aug 21 19:28:13 UTC 2012


Am 21.08.2012 02:28, schrieb Nat Sakimura:
> For the session management purpose, we really do not need to track. We 
> just need to tell the client the state change. It is the other 
> direction than tracking.

That's not my point. I don't want to track anyone. But, the way the 
session management is intended to work uses similar mechanisms and thus 
could be affected by tracking countermeasures.

>
> The browser does not need to send anything to the server but pull the 
> state efficiently. Local storage is ideal if it err not governed by 
> the same policy as cookies.

I quickly checked for Chrome, IE and Firefox. Chrome seems to apply the 
same policy to Cookies and local storage. With 3rd party cookies turned 
off, a script won't get read access to neither cookies nor local storage 
values. IE and FF are very relaxed regarding local storage. They do not 
seem to apply the 3rd party settings to local storage.

regards,
Torsten.

>
> =nat via iPhone
>
> On Aug 21, 2012, at 5:40 AM, Torsten Lodderstedt 
> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>
>> Internet Explorer seems to behave quite similar to Safari. It allows 
>> the iframe to read but not to write a cookie after this cookie had 
>> been set by a top level window.
>>
>> Are we facing a real show stopper here? In my opinion, the session 
>> management design might collide with all kinds of tracking 
>> countermeasures implemented by the browser vendors. It might not be 
>> the default today but as people get more sensible about this topic 
>> this might change.
>>
>> regards,
>> Torsten.
>>
>> Am 18.08.2012 18:36, schrieb Nat Sakimura:
>>> It seems there are philosophical differences. Chrome seems to have 
>>> the philosphy that when Blocking them, they rearly have to be 
>>> blocked completely, perhas because if it could be read, it can be 
>>> sent over to rhe server via a script. Firefox seems to be moving 
>>> towards that direction, too.
>>>
>>> On the surface, it looks privacy enhancing. However, in reality, it 
>>> is not IMHO. Blocking even the read of the third party local storage 
>>> makes it very hard for the users to use the web in that mode 
>>> resulting in less people actually setting that option. This means 
>>> less privacy protection. True, you can set the exception regex in 
>>> the setting but that is way too geeky.
>>>
>>> So, I think Apple's policy is more sensible. But others may have 
>>> different opinion.
>>>
>>> =nat via iPhone
>>>
>>> On Aug 19, 2012, at 12:45 AM, Torsten Lodderstedt 
>>> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>>>
>>>>
>>>> Am 16.08.2012 22:21, schrieb Nat Sakimura:
>>>>> Actually, Safari should not be a problem because the cookie is 
>>>>> first created at the top level window when the user first logged 
>>>>> in to the IdP. Safari allows the read of the cookie in iFrame, 
>>>>> though it does not allow write. This is perfectly fine.
>>>>>
>>>>> The problem is in other browsers. Chrome after rel. 17, when the 
>>>>> user sets no third party cookie / local storage option, it even 
>>>>> blocks the reading of the cookie. The same behavior was reported 
>>>>> on Firefox as well. Since they are not the default setting, not 
>>>>> many people perhaps are affected, yet it is a valid concern.
>>>>
>>>> Do you consider this a bug or is there a concept/philosophy behind?
>>>>
>>>> regards,
>>>> Torsten.
>>>>>
>>>>> Nat
>>>>>
>>>>> On Fri, Aug 17, 2012 at 2:25 AM, Torsten Lodderstedt 
>>>>> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>>>>>
>>>>>     Hi all,
>>>>>
>>>>>     according to one of our develpers, at least Safari is blocking
>>>>>     such cookies only if they were not created as a result of some
>>>>>     user interaction, e.g. a form post.
>>>>>
>>>>>     regards,
>>>>>     Torsten.
>>>>>
>>>>>
>>>>>
>>>>>     Am 14.08.2012 14:37, schrieb John Bradley:
>>>>>
>>>>>         So I take it that this is not about blocking what we would
>>>>>         think of as a normal 3rd party cookie.
>>>>>
>>>>>         The Browsers are also trying to block sneaky ways that
>>>>>         people are using to get around 3rd party cookie blocking.
>>>>>
>>>>>         We are getting caught in that basket because the IdP
>>>>>         iframe is invoked from the RP iframe.
>>>>>
>>>>>         Any Ideas?
>>>>>
>>>>>         On 2012-08-14, at 7:22 AM, Nat Sakimura wrote:
>>>>>
>>>>>             Latest Safari on iOS 5.1.1 and Mountain Lion.
>>>>>
>>>>>             =nat via iPhone
>>>>>
>>>>>             On Aug 14, 2012, at 9:11 PM, Chuck Mortimore
>>>>>             <cmortimore at salesforce.com
>>>>>             <mailto:cmortimore at salesforce.com>> wrote:
>>>>>
>>>>>                 Latest versions of Safari just got far more
>>>>>                 aggressive about this, so I'd report what version
>>>>>                 of Safari you were on.
>>>>>
>>>>>                 -cmort
>>>>>
>>>>>                 On Aug 13, 2012, at 6:36 PM, Nat Sakimura wrote:
>>>>>
>>>>>                     I did a little bit of checking on the
>>>>>                     relationships between the
>>>>>                     Session management spec and third party cookies.
>>>>>
>>>>>                     In short, it varies.
>>>>>                     In Safari and older Chrome, it works.
>>>>>
>>>>>                     In Chrome after v.17(?), if the user sets the
>>>>>                     block third party
>>>>>                     cookies option, it does not.
>>>>>
>>>>>                     I have not tested IE.
>>>>>
>>>>>                     Nat Sakimura
>>>>>                     _______________________________________________
>>>>>                     Openid-specs-ab mailing list
>>>>>                     Openid-specs-ab at lists.openid.net
>>>>>                     <mailto:Openid-specs-ab at lists.openid.net>
>>>>>                     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>>             _______________________________________________
>>>>>             Openid-specs-ab mailing list
>>>>>             Openid-specs-ab at lists.openid.net
>>>>>             <mailto:Openid-specs-ab at lists.openid.net>
>>>>>             http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>>         _______________________________________________
>>>>>         Openid-specs-ab mailing list
>>>>>         Openid-specs-ab at lists.openid.net
>>>>>         <mailto:Openid-specs-ab at lists.openid.net>
>>>>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Nat Sakimura (=nat)
>>>>> Chairman, OpenID Foundation
>>>>> http://nat.sakimura.org/
>>>>> @_nat_en
>>>>>
>>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120821/fde4e9f9/attachment.html>


More information about the Openid-specs-ab mailing list