W3C home > Mailing lists > Public > www-p3p-dev@w3.org > March 2002

Re: IE6, p3p, frames & 3rd party cookies

From: Lorrie Cranor <lorrie@research.att.com>
Date: Fri, 15 Mar 2002 09:56:21 -0500
Message-ID: <007601c1cc31$926941c0$9816cf87@barbaloot>
To: "Miles Sampson" <miles.sampson@ihavemoved.com>, <www-p3p-dev@w3.org>
First, the good news is that your situation is not as unique
as you might think, and others in this sort of situation have
gotten P3P to work.

IE6 makes cookie blocking decisions at the time
that cookies are set. So as long as your cookie has
a proper compact policy that IE6 views as "satisfactory"
it will not be blocked (unless a user is blocking all cookies)
-- even when used in the third party context.

You say that the cookie you are using is being used only
to serve the correct cotent based on which partner
a user came from. In that case, why can't it be a session
cookie? Also, it doesn't sound like it would be necessary
to log that cookie and link it with personally-identifiable
data. In that case, you could have a seperate P3P policy
for the cookie than for the rest of your site. Can you setup
your system so that your cookie doesn't get logged with PII?

Also, you should have a full P3P policy in addition to the
compact policy. If you use the well-known location
/w3c/p3p.xml for your policy reference file, browsers can
fetch your P3P policy before you serve a page.

If you give us an example URL I can check further to see what
the problem might be.

for more information on IE6.


----- Original Message -----
From: "Miles Sampson" <miles.sampson@ihavemoved.com>
To: <www-p3p-dev@w3.org>
Sent: Friday, March 15, 2002 6:13 AM
Subject: IE6, p3p, frames & 3rd party cookies

> Hi
> We're finding that our pages aren't serving on IE6 because of the way we
> cookies combined with the browser's new security features.
> We're a totally reputable site served over https and we have a p3p policy.
> The problem appears to derive from our architecture - we run a number of
> distributed sites where we re-purpose our content for partners. We serve
> these pages from the same URL, but we use a cookie to determine which
> distributed site the viewer should be looking at.
> Roughly what happens is this: when we repurpose content, we give our
> a URL like https://www.domain.com/site/partnername/. When a browser hits
> that page it sets a cookie that lets our servers know they should be
> receiving the <partnername> version of our content. Subsequently, the URL
> that the user sees resolves to https://www.domain.com/ and the server
> pre-pends all the relevant paths to serve up the right stuff.
> The issue comes when our partners serve those pages in frames and our
> then becomes a third-party cookie (that is served from a different site
> the site serving the frameset). At that point IE at default security
> won't serve our page before seeing the p3p statement.
> Catch 22 is that we can't serve a page until the browser's got a cookie &
> we haven't served a page the browser doesn't have our p3p statement.
> Therefore IE6 blocks the page and users get caught in a loop and never see
> anything.
> Has anyone got experience of this issue, or got any thoughts on how to
> circumvent it? Although there's quite a bit of talk around p3p and IE6 on
> newsgroups, we haven't seen this issue directly referred to before. We
> can't find any official Microsoft advice.
> Finally, here comes the science bit:
> here's what we send to the server. the lines numbered 1,2,3,4,5,6,7 are
> sent back we say it's a redirect, we tell the P3P (compact) policy, we
> the new location, set the cookie name=value but IE6 replies without the
> cookie.
wget --load-cookies=cookies.txt --save-cookies=cookies.txt --server-response
> --16:10:35--
> => `index.html'
> Connecting to connected.
> HTTP request sent, awaiting response...
> 1 HTTP/1.1 301 Moved Permanently
> 2 Date: Wed, 13 Mar 2002 16:07:33 GMT
> 3 Server: Apache Ben-SSL IHM
> 4 Set-Cookie: sw=bd3aa6cd7cebdab57c9857f8791369c9; expires=Thursday,
> 13-Mar-2003 16:07:33 GMT; path=/;
> 6 Location: /
> 7 Connection: close
> 8 Content-Type: text/html; charset=iso-8859-1
> Location: / [following]
> Miles
> Miles Sampson
> ihavemoved.com
> miles@ihavemoved.com
> dd: 020 7799 8404
> m: 07971 991444
Received on Friday, 15 March 2002 10:00:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:42:50 UTC