W3C home > Mailing lists > Public > www-p3p-policy@w3.org > May 2008

Re: Third-party cookies working, sort of

From: Lorrie Faith Cranor <lorrie@cs.cmu.edu>
Date: Wed, 21 May 2008 22:25:35 -0400
Cc: <www-p3p-policy@w3.org>
Message-Id: <BD36FF55-C93A-413C-982D-E6F84DA84480@cs.cmu.edu>
To: Henning Michael Møller Just <henning.just@datagraf.dk>

On May 20, 2008, at 7:12 AM, Henning Michael Møller Just wrote:

> Hi there
> Just joined this list after searching the archives. I couldn't find  
> an answer to the question I am going to present here, but that may  
> of course just be me :-)
> I have two clients with a fairly similar setup when seen from the  
> user's perspective. They have a SSL site with a webpage. On this  
> webpage they have an iframe referring to my site. Their site tries  
> to set a cookie (an ASP session cookie I think) and my site tries to  
> set a cookie.
> In case (A) there are no problems. This was the first site so I was  
> happy and thought I had the situation under control :-)
> In case (B) the cookies were blocked in IE7 (and IE6). Not just my  
> cookie but also their cookie. I didn't know about P3P before this  
> but read up on it and finally figured out how to make a proper  
> policy for my site. When my cookie still didn't work I figured out  
> how to make a compact policy and added it to the header. Then the  
> cookie worked for my site.

That sounds about right.

> In both cases the client sites has a /w3x/p3p.xml file, but they are  
> 1) almost identical and 2) has syntax errors in the <COOKIE- 
> INCLUDE>. There's no P3P: header in the HTTP headers and there's no  
> P3P compliant <link> element, so http://www.w3.org/P3P/ 
> validator.html cannot find a valid policy reference file.

This is not a syntax error. The validator gives a warning, but as long  
as there is a valid policy reference file at /w3c/p3p.xml, there is no  

What is happening is your site's cookie is being treated as a third- 
party cookie from the perspective of the client sites. IE7 blocks  
third-party cookies that don't have P3P compact policy headers. It  
doesn't matter whether the first party-site (in this case your  
client's site) has P3P for determining whether the third-party cookie  
gets blocked.

> In case (A) I am not providing any P3P information. No reference  
> file, no compact policy. In case (B) I am now providing the  
> information, but before doing that it didn't work.

Hard to tell from the information you have provided.

> This is my question: Why does it work in case (A) but didn't in case  
> (B)?
> What else do I have? Let's see.... In case (A) the client site tries  
> to set a cookie (and succeeds) that looks like this:
> In case (B) the client site tries to set a cookie (and is blocked)  
> that looks like this:
> Set-Cookie: ASP.NET_SessionId=ml504ruu0sazyhuqd0lvhm45; path=/;  
> HttpOnly
> In case (A) the iframe has src set to the https:// path for my site.  
> In case (B) the iframe has src set to the http:// path for my site  
> (giving the user a horrible warning about viewing secure and  
> insecure items). My site then redirects to https://

If you use https then you must make sure your P3P policy reference  
file is also available via https

> I *think* that explains why the address bar in case (A) has a lock  
> on a bright blue background to the right, while in case (B) no such  
> lock (no pun intended ;-)

Yes, that would be the reason.

> I hope I make sense with all this - and I know it works now and I  
> ought to be happy, but I want to know why it didn't work before.  
> Otherwise it will just become a magic potion I'll have to apply  
> every now and then :-(

These articles may help:


Lorrie Cranor

> Best regards
> Henning Michael Møller Just

Lorrie Faith Cranor • lorrie@cmu.edu • http://lorrie.cranor.org/
Associate Professor, Computer Science and Engineering & Public Policy
CMU Usable Privacy and Security Laboratory • http://cups.cs.cmu.edu/
Carnegie Mellon University, 5000 Forbes Ave., Pittsburgh, PA 15213
Received on Thursday, 22 May 2008 02:26:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:10 UTC