[www-p3p-policy] <none>

>From rigo  Fri Sep 21 05:28:51 2001
Return-path: <rigo@tux.w3.org>
Envelope-to: rigo@localhost
Delivery-date: Fri, 21 Sep 2001 05:28:51 +0200
Received: from localhost ([127.0.0.1])
	by rigo with esmtp (Exim 3.31 #1 (Debian))
	id 15kGzi-00006W-03
	for <rigo@localhost>; Fri, 21 Sep 2001 05:28:50 +0200
Received: from www49.inria.fr [138.96.10.12]
	by localhost with POP3 (fetchmail-5.8.3)
	for rigo@localhost (single-drop); Fri, 21 Sep 2001 05:28:50 +0200 (CEST)
Received: from sophia.inria.fr by www49.inria.fr (8.11.1/8.10.0) with ESMTP id f8L1F6100460 for <rwenning@www49.inria.fr>; Fri, 21 Sep 2001 03:15:06 +0200 (MET DST)
Received: from tux.w3.org by sophia.inria.fr (8.11.1/8.10.0) with ESMTP id f8L1Fle18759 for <Rigo.Wenning@sophia.inria.fr>; Fri, 21 Sep 2001 03:15:47 +0200 (MET DST)
Received: (from rigo@localhost)
	by tux.w3.org (8.9.3/8.9.3) id VAA22511
	for Rigo.Wenning@sophia.inria.fr; Thu, 20 Sep 2001 21:15:46 -0400
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA22505
	for <rigo@w3.org>; Thu, 20 Sep 2001 21:15:46 -0400
Received: by www19.w3.org (8.9.0/8.9.0) id VAA18287
	for rigo@w3.org; Thu, 20 Sep 2001 21:15:45 -0400 (EDT)
Date: Thu, 20 Sep 2001 21:15:45 -0400 (EDT)
X-Envelope-From: www-p3p-policy-request@tux.w3.org  Thu Sep 20 21:15:34 2001
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id VAA18267
	for <www-p3p-policy@www19.w3.org>; Thu, 20 Sep 2001 21:15:34 -0400 (EDT)
Received: from mail1.websidestory.com (mail1.websidestory.com [208.232.223.4])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA22500
	for <www-p3p-policy@w3.org>; Thu, 20 Sep 2001 21:15:34 -0400
Received: from jmccarthy (10.100.100.120.hitbox.com [10.100.100.120] (may be forged))
	by mail1.websidestory.com (8.11.3/8.11.3) with SMTP id f8L1FS307721
	for <www-p3p-policy@w3.org>; Thu, 20 Sep 2001 18:15:28 -0700 (PDT)
From: "Jay McCarthy" <jay@websidestory.com>
To: "'P3P policy '" <www-p3p-policy@w3.org>
Old-Date: Thu, 20 Sep 2001 18:15:28 -0700
Message-ID: <LLEHKPKKACJPIODDNAFKAEHNDAAA.jay@websidestory.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3BB5DC2594ACD51191CC00902771C5DF0385AA@SONNESVR08>
X-Diagnostic: Not on the accept list
Subject: [Moderator Action] RE: what cp will satisfy IE 6?
X-Diagnostic: Mail coming from a daemon, ignored
X-Envelope-To: www-p3p-policy
Resent-From: rigo@localhost
Resent-Date: Fri, 21 Sep 2001 07:30:48 +0200
Resent-To: www-p3p-policy@w3.org


Yep,

It makes for a bunch of pretty ugly warning messages. Consider the case
where you get a 1st party cookie from a content distribution company like
Digital Island or Akamai. Then you upgrade IE and everytime you then go to a
site that uses DI or Akamai you get a warning message because the cookie is
sent in the 3rd party context. It's also important to note that domains can
have up to 20 cookies per domain and the warning will persist until all the
legacy cookies for that domain are churned..

Fun stuff... Microsoft really wanted to provide "out of the box" privacy and
thus had to do something about legacy cookies their solution was to apply
the same rules to legacy cookies and since legacy cookies have no CP they
are blocked in the 3rd party context.

The thing that is most discouraging is that the warning doesn't say
"outgoing cookie blocked" or "legacy cookie blocked from being sent" only
"blocked" which leads one to think that all cookie transactions are
failing..

Unfortunately given that they wanted to provide this "out of the box"
protection and that there were no easy ways of knowing whether a cookie was
originally issued in the first or third party context it's hard to solve
this one. I would certainly love to see them change this policy and just
accept legacy cookies knowing that they'll eventually be churned anyway..

									-Jay-


> -----Original Message-----
> From: www-p3p-policy-request@w3.org
> [mailto:www-p3p-policy-request@w3.org]On Behalf Of Keith Ball
> Sent: Thursday, September 20, 2001 3:13 PM
> To: 'P3P policy '
> Subject: RE: what cp will satisfy IE 6?
>
>
>  We have also implemented P3P in a 3rd party context.  It mostly works.
>
> The problems we have had to deal with is in the are that microsoft calls
> "legacy cookies".  These are cookies that existed before IE 6 was
> installed.
> So, the user received a cookie from a site with an earlier
> version of IE and
> the cookie does not have a P3P policy associated with it.  Microsoft made
> some very short sighted (IMHO) decisions on how to handle these legacy
> cookies, preventing those cookies from being used ever in 3rd
> party context.
> Our compact policy would allow a newly set cookie to be saved,
> but the same
> cookie if a legacy has no way of being upgraded.  In addition, IE 6
> indicates a "blocked" cookie by displaying the privacy problem icon in the
> status bar (but no information in the privacy report dialog) when it tries
> to use this "legacy" cookie in a 3rd party context.  However, with our
> software, the legacy cookie is overwritten with a new and "satisfactory"
> cookie.  So, the icon isnt displayed in subsequent acesses to the
> 3rd party
> site.  However, in our case, the old cookie value is lost and cannot be
> recreated causing the user to lose information they created.
>
> You can see the E-Color compact policy and find our P3P policy
> reference and
> policy file by going to our company site home page with IE6
> (www.ecolor.com).  Our 3rd party domain is trueinternetcolor.com. Our
> compact policy is:
> NOI DSP CUR ADM DEV OUR IND UNI COM NAV INT
>
>
> I feel the problem is two fold.  First, Microsoft took an expedient short
> cut to limit the work they had to do to deal with "legacy" cookies.  More
> importantly, the P3P spec does not effectively address the issue of the
> status of "legacy" cookies.  Specifically, how a user agent should handle
> upgrading the status of these legacy cookies.
>
> Microsoft's proposed work-around for this legacy cookie problem
> is to force
> the end-user to make a 1st party request to a server in the
> domain where the
> 3rd party request is targeted.  They allow legacy cookies to be returned
> unqualified to these 1st party requests.  However, not all
> applications have
> the ability to get a first party request.  They gave me no solution to the
> other problem.
>
>
> good luck.
> keith
> ----
> Keith Ball
> E-Color, Inc.
>
> -----Original Message-----
> From: Laurel Jamtgaard
> To: P3P policy
> Sent: 9/20/01 2:04 PM
> Subject: RE: what cp will satisfy IE 6?
>
> Ken Martin [mailto:ken@kpmartin.com] wrote:
> >My first (quite recent) post here asked if anyone is successfully using
> >cookies in IE6 in a third-party context. I didn't get a response yet.
> >Specifically, I'm using .domain.com cookies.
> [snip]
> >Ken Martin
>
> Ken and others,
>   We have implemented P3P in a third-party context.  It took some
> fiddling but it seems to be working OK with IE 6.
>
>   This is our compact policy:
> 	CP="NOI LAW NID BUS CUSo PSAo PSDo TAIo OUR OTR COM DEM NAV PRE
> STA PUR INT NAV"
>
> Regards,
> Laurel
> Chief Privacy Officer and General Counsel
> Angara E-Commerce Services, Inc.
> www.angara.com
>
>

Received on Friday, 21 September 2001 07:04:13 UTC