<html><head></head><body bgcolor="#FFFFFF"><div>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. </div><div><br>
</div><div>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. <br><br>=nat via iPhone</div><div><br>On Aug 21, 2012, at 5:40 AM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:<br>
<br></div><div></div><blockquote type="cite"><div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
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.<br>
<br>
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.<br>
<br>
regards,<br>
Torsten.<br>
<br>
<div class="moz-cite-prefix">Am 18.08.2012 18:36, schrieb Nat
Sakimura:<br>
</div>
<blockquote cite="mid:124032512084738870@unknownmsgid" type="cite">
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>So, I think Apple's policy is more sensible. But others may
have different opinion. <br>
<br>
=nat via iPhone</div>
<div><br>
On Aug 19, 2012, at 12:45 AM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">Am 16.08.2012 22:21, schrieb Nat
Sakimura:<br>
</div>
<blockquote cite="mid:CABzCy2CxOv91nH7bPCv8kTXPTad+d2NuML-=S6iPx3UmREKemQ@mail.gmail.com" type="cite">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.
<div> <br>
</div>
<div>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. <br>
</div>
</blockquote>
<br>
Do you consider this a bug or is there a concept/philosophy
behind?<br>
<br>
regards,<br>
Torsten.<br>
<blockquote cite="mid:CABzCy2CxOv91nH7bPCv8kTXPTad+d2NuML-=S6iPx3UmREKemQ@mail.gmail.com" type="cite">
<div><br>
</div>
<div>Nat<br>
<br>
<div class="gmail_quote">On Fri, Aug 17, 2012 at 2:25 AM,
Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
all,<br>
<br>
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.<br>
<br>
regards,<br>
Torsten.<br>
<br>
<br>
<br>
Am 14.08.2012 14:37, schrieb John Bradley:
<div class="HOEnZb">
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> So I take it that this
is not about blocking what we would think of as
a normal 3rd party cookie.<br>
<br>
The Browsers are also trying to block sneaky
ways that people are using to get around 3rd
party cookie blocking.<br>
<br>
We are getting caught in that basket because the
IdP iframe is invoked from the RP iframe.<br>
<br>
Any Ideas?<br>
<br>
On 2012-08-14, at 7:22 AM, Nat Sakimura wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Latest Safari on iOS
5.1.1 and Mountain Lion.<br>
<br>
=nat via iPhone<br>
<br>
On Aug 14, 2012, at 9:11 PM, Chuck Mortimore
<<a href="mailto:cmortimore@salesforce.com" target="_blank">cmortimore@salesforce.com</a>>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Latest
versions of Safari just got far more
aggressive about this, so I'd report what
version of Safari you were on.<br>
<br>
-cmort<br>
<br>
On Aug 13, 2012, at 6:36 PM, Nat Sakimura
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I did a
little bit of checking on the
relationships between the<br>
Session management spec and third party
cookies.<br>
<br>
In short, it varies.<br>
In Safari and older Chrome, it works.<br>
<br>
In Chrome after v.17(?), if the user sets
the block third party<br>
cookies option, it does not.<br>
<br>
I have not tested IE.<br>
<br>
Nat Sakimura<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</blockquote>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Nat Sakimura (=nat)
<div>Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</blockquote>
<br>
</div></blockquote></body></html>