<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">Am 21.08.2012 02:28, schrieb Nat
Sakimura:<br>
</div>
<blockquote cite="mid:-1863808570159123254@unknownmsgid" type="cite">
<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. <br>
</div>
</blockquote>
<br>
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. <br>
<br>
<blockquote cite="mid:-1863808570159123254@unknownmsgid" type="cite">
<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>
</div>
</blockquote>
<br>
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.<br>
<br>
regards,<br>
Torsten.<br>
<br>
<blockquote cite="mid:-1863808570159123254@unknownmsgid" type="cite">
<div><br>
=nat via iPhone</div>
<div><br>
On Aug 21, 2012, at 5:40 AM, Torsten Lodderstedt <<a
moz-do-not-send="true" 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">
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"
target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>