W3C home > Mailing lists > Public > public-p3p-spec@w3.org > February 2004

Re: proposal to deprecate compact policies

From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Fri, 13 Feb 2004 11:03:38 -0500
Message-Id: <200402131603.i1DG3cCA082583@nic-naa.net>
To: Rigo Wenning <rigo@w3.org>
Cc: public-p3p-spec <public-p3p-spec@w3.org>, brunner@nic-naa.net

Hi Rigo,

This is written for poeple that may not have been around back when we
did cookies.

> compact policies in P3P 1.0 were added in the last minute. They were
> very controversial but still made it into the 1.0 Recommendation. 

Well, a history in two sentences is bound to have some simplifications.

Dan Jaye and I (then of the now profoundly cratered dotGone Engage/CMGI)
had a http trust mechanim for state management, originating from the PICS
label problem area, which proposed to deliver a label set and a trust
property. We took some of the label space present in P3P, circa Fall '00,
substituting an abnf syntax for the xml syntax, and tried to keep the
byte count down. We also removed the digital signature portion of the
proposal.

There was controversy over the label semantics (doubleclick vs cmgi).
There was controversy over the label syntax (anything vs xml).
There was controversy over the equivalence of the semantic scope of the
label space (self-policied objects vs url-reference-policied objects).
There was (implicit) controversy over the over-the-wire cost of policy
delivery, hence of the tractible complexity of policy evaluation within
a single DOM tree. [I never considered the stream problem, and I don't
recall anyone else doing so either.]

There was also Microsoft's "cookie patch" in IE5.5, which really trumped
standards-based realities.

At the November meeting in Palo Alto Microsoft insisted on a mechanism for
policy evaluation for cookies, and Engage insisted on the adoption of a
on-cookie policy delivery mechanism. Each for their own reasons (tractible
DOM eval by brower-implementor MS, tractible third-party policied object
delivery by ad-network-implementor CMGI).

XML, part of the label space, including round-trip one-to-one and on-to
semantic properties were evaluated and discarded.

> Now we have the new discussion about the compact format. 
> This new discussion war triggered by feedback from web-site implementers
> and by feedback from 2 P3P workshops. In fact, by aggregating the whole
> rather complex structure of a full P3P Policy into a set of simple
> tokens with no relationship to each other, the assertion made by compact 
> policies can get inaccurate from blurry to heavy overstatements.
> 
> We discussed and offered to discuss the performance implications many
> times. With known-hosts we make asynchronus evaluation even easier. We
> offered to work on enhancing the compact format to give it at least 
> 'some' structure, but there was no interest.
> 
> Now the time has come to deprecate compact policies and to throw that
> burden over board. This means, Web-sites can still put up some tokens to
> make some P3P 1.0 agents happy, but the basis for semi-automatic
> decision-making in P3P 1.1 will be only based on the full XML format. At
> least, this is my suggestion.

This isn't paid work for me. Little is, but that's a feature, I guess.

One of the non-profit and/or left-of-center email/webservice shops in the
US is Kintera.org. They handle the retail mass mailings for the Dennis
Kucinich (left Democrat) for President campaign. In every html mailing is
a 1x1 gif, a web bug. See my note at Lisa English's blog "Ruminate This",
the article id is http://www.ruminatethis.com/archives/001702.html for a
collection of Kintera web bugs on Kucinich mailings.

Ignoring the point that these 1x1 gifs are delivered from URLs that could
in principle be correctly policied, and the point that Kintera is about as
far from the principle of informed disclosure and good table manners as a
Stasi agent pickled in Soviet vodka, or John Ashcroft sober, it is possible
that large objects could be made out of small objects, and that the small
objects may not have a common point of origin, and that some good can come
out of a policy delivery mechanism that scales, and does not require some
property absent from those two properties -- (1) many and (2) diverse.

Anyway, as I wrote 15 minutes earlier, this isn't paid work for me, nor is
it prestige work. The W3C is about things that about 100 companies pay real
money for, so this comment is ... insubstantial.

Thanks for reading,
Eric
Received on Friday, 13 February 2004 10:49:40 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 17 March 2004 17:46:30 EST