- From: Lorrie Cranor <lorrie@research.att.com>
- Date: Mon, 11 Aug 2003 09:52:57 -0400
- To: Matthias Schunter <mts@zurich.ibm.com>
- Cc: "Jeremy Epling" <jepling@windows.microsoft.com>, <public-p3p-spec@w3.org>
On Monday, August 11, 2003, at 09:13 AM, Matthias Schunter wrote: > Hi! > > The proposal looks good. Once Jerry contacts me, I'll work with him to > resolve the remaining issues. Some initial ideas/remarks: > - the opt-in or opt-in elements inside all elements of an > opt-in/out-out group where included > to preserve backward compatibility of the semantics. Yes, that's what I remember too. But the problem still occurs as to what to do if people violate this rule. I think we need to define how to handle this error case. > - The issue of the OURS/CURRENT may be resolved by defining that they > cannot be included in an > opt-in/opt-out group. I think we may need to include them, but perhaps we can define that the opt-in/opt-out doesn't apply to them. > - Does it makes sense to use "required" instead of "no-group" or do > you envision that with > consent="no-group", one can nevertheless have opt-in's and out's > inside? I was envisioning the "no-group" would indicate a mix of opt-in's opt-out's and required, or all required. Lorrie > > Regards, > matthias > > > > > At 11:58 AM 8/6/2003 -0400, Lorrie Cranor wrote: > >> We discussed this on today's call, minutes should be forthcoming. My >> quick summary is: >> >> - combining these two group concepts probably makes sense >> - we probably want an extension that looks something like the >> following that can be inserted into all statement's that belong to a >> group: >> >> <STATEMENT> >> <EXTENSION> >> <STATEMENT-GROUP id = "fflyer" /> >> </EXTENSION> >> . . . >> </STATEMENT> >> >> Then somewhere else in the policy >> <EXTENSION >> <STATEMENT-GROUP-DEF id="fflyer" >> short-description="Frequent Flyer Club" >> consent = "opt-in" /> >> </EXTENSION> >> >> Some groups of statements might not be consent groups, in which case >> they might use an attribute like consent = "no-group" (which might be >> the default). >> >> There are also some concerns about consent group that need to be >> worked out. In Mathias' proposal it says that all PURPOSE and >> RECIPIENT elements in a group have to have the same required >> attribute. But ours and current are special cases that don't have >> this attribute. This needs to be accounted for (the example in >> Mathias' draft is actually incorrect because of this). Also we need >> to be clear on how to handle errors. What if someone uses consent >> group but then uses different required attributes (which is >> incorrect)? Does that invalidate the policy? Perhaps if that happens >> the user agent should treat it as if it is consent = "no-group" ? >> >> In any case, Jeremy is going to put together a more specific proposal >> on this grouping. Mathias, it would be great if you could work with >> him on the consent aspect. >> >> Lorrie >> >> >> On Wednesday, July 30, 2003, at 02:53 AM, Matthias Schunter wrote: >> >>> >>> Hi Jeremy, >>> >>> thanks for your design. I feel that grouping statements is a good >>> idea. >>> >>> The actual syntax for grouping is elaborated in our earlier draft on >>> consent choices: >>> http://www.w3.org/P3P/2003/05-cc-changes-to-P3P.html >>> >>> I feel that grouping statements is a good idea for multiple purposes. >>> Therefore, I feel that we should have a general group mechanism >>> where each group should have multiple properties: >>> - opt-in opt-out or always (from consent choices) >>> syntactically this can be implicit: either all statements are >>> always/opt-in, or opt-out. >>> - target (something specifying whether it's the ebay or amazon part) >>> The target is something that might be useful to add to your >>> proposal. >>> I don't know how to express this in a nice syntax. >>> >>> Why don't we merge both proposals into a "grouping statements" >>> proposal? >>> >>> Regards, >>> >>> matthias >>> >>> >>> >>> At 07:00 PM 7/29/2003 -0700, Jeremy Epling wrote: >>> >>>> Below are the basics of my proposal for statement grouping. >>>> >>>> >>>> >>>> Problems >>>> * Policies are not relevant to how a user interacts with the site >>>> * Users don t know what part of a P3P policy applies to them >>>> and there activities on a site >>>> * Users understand scenarios of how they interact with a >>>> site better than a series of statements related to a feature of the >>>> site >>>> * Policy authors have to make highest common denominate policies >>>> that could look more privacy impacting than they are for most users >>>> >>>> >>>> Goals >>>> * Provide a method for showing the sections of the P3P policy >>>> that apply to how a user interacts with the site/service >>>> * Allow an easy way for policy authors to describe what sections >>>> of their P3P policy apply to different user interaction with their >>>> site/service >>>> >>>> >>>> Scenarios >>>> * User browses to ebay and views the P3P policy. They are able >>>> to skip to the buyer section of the P3P policy since that is what >>>> applies to them. >>>> * User browses to amazon and views the P3P policy. The can see >>>> that since they are not logged in less information is collected >>>> about them. >>>> >>>> >>>> Design >>>> >>>> >>>> >>>> The P3P author decides the name of the statement group which is >>>> used in the display of the agent when it translates the nodes to >>>> natural language. >>>> >>>> >>>> >>>> <Statement> >>>> >>>> <extention> >>>> >>>> <grouping-id>Member</grouping-id> >>>> >>>> </extention> >>>> >>>> <statement> >>>> >>>> >>>> >>>> Issues >>>> * Do agents now show conflicts per grouping? >>>> >>>> >>>> Jeremy Epling >>>> Windows - Privacy and Trust UX >>>> >>>> <BLOCKED::>wpihelp - where to go for all your privacy questions >>>> >>> >>> -- Dr. Matthias Schunter <mts (at) zurich.ibm.com> --- >>> IBM Zurich Research Laboratory, Ph. +41 (1) 724-8329 >>> Fax +41-1-724 8953; More info at www.semper.org/sirene >>> PGP Fingerprint 989AA3ED 21A19EF2 B0058374 BE0EE10D >> > > -- Dr. Matthias Schunter <mts (at) zurich.ibm.com> --- > IBM Zurich Research Laboratory, Ph. +41 (1) 724-8329 > Fax +41-1-724 8953; More info at www.semper.org/sirene > PGP Fingerprint 989AA3ED 21A19EF2 B0058374 BE0EE10D >
Received on Monday, 11 August 2003 09:50:02 UTC