Re: Do you know a resource that compares P3P to DNT?

Eyal,

Dan Jay and I didn't really want to use XML as the syntax for placing
policy data in instances of the http state management mechanism
("cookies"), but there it was.

We gave up on the digital signature (chain of validation) associated
with a policy statement -- xmldsig was immature, and retained the
critical business logic element differentiating Engage (now extinct)
and its non-deterministic user behavior tracking, from DoubleClick
(now Google, not extinct) and its deterministic user behavior tracking.

For pre-P3P art see the CPEX user profile stuff, the relevant bits are
how metadata about collection policy associated with customer profiles
is propagated through a multi-party sequence of exchanges.

That's where we started with the existing W3C P3P project, and the
balance between syntax consistency (use XML for everything) and per
packet overhead was worked. The result expressing some of the larger
P3P semantic was more verbose than the simple key-value pair in the
earlier http state management mechanism proposals, so an encoding was
useful for the packet overhead part of the problem, and semantic
consistency was approached, at the loss of syntax consistency.

I hope this helps for the "how did we get where we got" question.

To step back, and change the problem domain from the specifics of the
protocol (http) to that of the metadata, I proposed a <dcp> to the
(also XML enamored at this period of time) IETF PROVREG WG
(provisioning ICANN registries, domain names), in which the registries
would announce their data collection policies (sell to arbitrary third
parties, keep forever, ...) so we could express the data retention and
redistribution policies ICANN applied to each registry contract. This
hasn't proven to be a critical need, as the policy for .com is really
the policy for all ICANN registries, one of the several aspects of
monopoly power.

However, it was easy to implement.

Harald Alvestrad, then IETF Chair, and a very few others, insisted on
a binary valued "do not publish" metadata. So that got added to the
protocol (EPP).

So there was a data collection policy announcement mechanism, used by
servers at session create time, to announce to clients what horrible
things the investor-speculators would do with domain registrant data
(email, telephone, postal data), and a publish/no-publish toggle, used
by registrants at data-harvesting time to suggest that putting the
email/telephone/postal data in public WHOIS servers to be harvested by
the spammers of the world was not what the user requested of the
registrar-registry-ICANN chain of contractors and policy authors.

This has been harder to implement. It is easy to code, but getting the
toggle at one end of the sequence to control the behavior of WHOIS
servers several ownership and policy hops distant is ... lame and
unlikely to get unlame.

And Harald et al didn't think data retention or bulk resale or
repurposing was as important as being spammed, which may have been
more self-referential than applicable to the general users of browsers
who disclose PII as a condition of services other than basic access.

Obviously, I've a view on that instance of the model of user
originating metadata to the effect of "do not track (me)", and I hope
that the current instance -- DNT -- is less unsuccessful.

Eric

Received on Wednesday, 29 February 2012 14:07:06 UTC