Matthias and Jeremy,
We discussed this on the call today and would like to move this
forward. We need a revised proposal. Jeremy, are you going to get us
something this week? Or perhaps Matthias could revise his proposal to
incorporate what we've discussed? I would like to have something more
concrete to discuss before next week's call.
Thanks,
Lorrie
On Monday, August 11, 2003, at 09:52 AM, Lorrie Cranor wrote:
>
>
> 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
>>
>