W3C home > Mailing lists > Public > www-p3p-public-comments@w3.org > August 2000

Re: P3P and the privacy legislation in Germany:

From: Joseph M. Reagle Jr. <reagle@MIT.EDU>
Date: Fri, 18 Aug 2000 17:23:20 -0400
Message-Id: <>
To: Ruediger Grimm <grimm@darmstadt.gmd.de>
Cc: rosnagel@uni-kassel.de, www-p3p-public-comments@w3.org
Thank you for the explainations Rüdiger!

At 18:41 8/8/2000 +0200, Ruediger Grimm wrote:
 >>o P3P doesn't not provide the authentication of the policy or the
 >>The appropriate English translated text of TDDSG states, "(7) Consent can 
 >>also be declared electronically if the provider ensures that such consent 
 >>can be given only through an unambiguous and deliberate act by the user, 
 >>consent cannot be modified without detection, the creator can be
 >The point is not to associate PERSONAL DATA with an electronic 
 >signature (in order to make them authentic): there is no requirement 
 >to sign personal data. 
 >Our point is to associate a user CONSENT or a server POLICY 
 >with an electronic signature in order to make it authentic. If the consent 
 >is to be signed by a person who wants to remain unidentified, the 
 >person would use a persona signature (a "pseudonym" as the related 
 >acts on data protection and signature call it). 

So the text above, "the creator can be identified" refers to the service,
and not the user? Regardless, even a requirement for pseudonymous signatures
seems aggresive. P3P can certainly employ the functionality of XML Signature
[1], however the TDDSG then seems to presume a massively deployed and usable
signature and key infrastructure. I don't think this is likely any time
soon. (Even if I was peronally given the ability to use a key to sign
contracts or purchase orders on-line today, as a user, I would refuse it
because of other consumer protection concerns.) Regardless, P3P+XMLSignature
is technically capable of meeting this requirement.

[1] http://www.w3.org/Signature/

 >>o How is the "description material for an automatic interpretation ... 
 >Just two examples: the purpose element should contain "billing" and 
 >"delivery of hard goods" in order to satsify two other important 
 >application areas. However, the problem of automatic interpretation 
 >will remain, until experience has identified those purposes which 
 >cover most real cases. 

 >>o Can you cite text that requires the category to be associated with 
 >>purpose? Would this not make the matrix of possible categories/purposes
 >>enumerated overwhelming? The purpose of the P3P vocabulary design is to
 >>as expressive as possible while limiting the variables and their range
 >Does this question refer to our critique that recipients of data should be 
 >associated with the PURPOSE of data procession, and not with the 
 >type of privacy practice of the recipient? 


 >If so: the German act does require this association because there should 
 >never be an indirection with the reason for data procession (or storage) 
 >of this type: 
 >"we have stored your personal data because our privacy statement is 
 >similar to the privacy statement of another organisation which has stored 
 >the data with your explicit consent": this would open an endless route of 
 >data transfer out of control of the user. 

I still don't follow. Is your bad case the following: if a site A says they
give the data to sites that have similar practices (such as those that don't
use it for marketing) including site B. Site B has similar practices (no
marketing, etc.) also gives it to site C? This could go on for a while. But
the goal is to provide the use with the assurance that if they don't want
marketing, they won't get marketing, and to give them a sense of the scope
of distribution, not a complete audit trail (which I think is infeasible).
What is the alternative and how does it prevent this scenario?

Regards,          http://www.mit.edu/~reagle/
Joseph Reagle     E0 D5 B2 05 B6 12 DA 65  BE 4D E3 C1 6A 66 25 4E
MIT LCS Research Engineer at the World Wide Web Consortium.

* This email is from an independent academic account and is 
not necessarily representative of my affiliations.
Received on Friday, 18 August 2000 17:23:31 UTC

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