MINUTES: 17 March 2004 P3P spec call

[Minutes taken by Giles Hogben and edited by Lorrie Cranor]

Proposal to deprecate compact policies

Microsoft does not want to have CP's deprecated and has no resources to
work on p3p right now but would probably implement a grouping mech for
CP's by the next major release. Why they need CP's has to do with
caching which was written a long time ago and would have to be
rewritten. Why can't they rewrite their code. Should we proceed on a
grouping mechanism? We are likely looking past P3P 1.1 timeframe for
next major release

Giles - even in a year is there no possibility of rewriting caching:
Lorrie: we can't assume that we can before P3P 1.1. comes out because no
possibility to discuss
Rigo: grouping would be a major piece of work
Lorrie: It is straighforward
Rigo: There are hidden issues. How big is the problem we want to solve 
and
how much work is it to solve that problem
Lorrie: Anything we put in is work but I don't think it is that much. 
But
how much does it solve. If we proceed with this then there will be less
motivation to get rid of CP's later. so if it doesn't solve many 
problems
then we shouldn't do it.#
Brookes: Do CP's accurately reflect full policies. Brookes doesn't. 15
categories can't be an accurately describe the world.
Lorrie: Most web sites only use categories.
Giles: But they are trying to please IE6
Lorrie: What other problems do we have
Rigo: People implement only one policy.
Matthias: CP reflects worst case? But grouping allows you to 
distinguish.
We figure out what exactly grouping does
Brookes: so what will MS actually do with the grouping mechanism - they 
are
displaying policies with a single message. If they display the 
granularity
then they can't put the penalties in place.
Lorrie: They are not too concerned about the presentation. When they 
block
cookies, you really have to dig to get info. So my impression is that 
they
will just change their blocking algorithm...
Rigo: When will they do this? Doubleclick has the option to make their
objections known.
Lorrie: MS will check to see that the FP exists
Giles: what about PRF's
Lorrie: They only apply to cookies. A group will be roughly analogous 
to a
statement. Statement could be implied by curly brackets. Backward
compatability - if you ignore the curly braces, you still have a valid 
CP
with duplicate tokens.
Giles: But it might have a completely different meaning.
Rigo: --> same set of tokens can have 2 different meanings.
Lorrie: Same meaning but interpreted in 2 different known ways.
Rigo: We should weaken the meaning of CP's. Want to resolve problems 
that
web sites are put off by liability issues because of mismatches in
semantics.
There is a thin line between they can't lie but if they miss some
granularity this is less of a problem.
Lorrie: You don't have to use the curly braces.
Giles: How about doing both.
Lorrie: We could say something like - think about not using them at all
because we are thinking of taking them out altogether.
Rigo: So the problem is just with the overhead. Even Mozilla has only
compact. If PRIME can implement something in Mozilla it creates a lot of
pressure on MS. Mozilla will go to safari etc...
Lorrie: So what's the answer
Rigo: we need to give it a different spin. So it means we say the CP is 
just
a hint and has to be compliant with the FP. Don't make it a legal 
statement
- it is only a hint.
Giles: If it is only a hint, what use is it?
Lorrie: To display a reason, it has to go to the full policy.
Rigo: The measure against which you are measured to see if you lied is 
the
full policy.
Dave: The clearest case of fraud is if you deliberately chose a wrong 
token.
It is still a hint and you can't mislead with it. Box of medicine 
metaphor.
Call: Proceed in this direction
Action item: Matthias?

Consent choices:
Jack: I forgot how much simpler I was supposed to make it. I need to 
get rid
of the requirement of referring to the PRF.
Lorrie: Borrow from the language we use in the hints section.
Jack: I am concerned that we are not really making it any more
straightforward than the previous ones.
Lorrie: Once it is fully simplified, the ourhosts mechanisms says that n
our-host tag in a POLICY-REF would mean that for any URIs
covered by this policy, any embedded content (anything that would be
covered by a HINT element) that is served from a URI covered by the
our-host tag should be considered as coming from the entity or its
agents (or entities for whom it is acting as an agent).

Brookes: It is very difficult for people to implement this, because if 
you
need to use the url to decide quickly how to dynamically generate a PRF.

Primary purpose spec:
Rigo: it's great. Send it to the outreach
Lorrie: How useful will it be because people will have to include all 
the
items.
Dave: How satisfactory will it be to the Art 10 WG? For real policies, a
list of 200 might be better.
Lorrie: Even a list of 200 - given that most sites are going for a 
site-wide
policy. So even that might not help.
Rigo: Banking is missing.
Dave: if they are going to lump them altogether this will never be 
useful
but it gives the possibilities.
Lorrie: But it might help if they are divided out into statements.
Dave: Main purpose of this is that a user agent loading a page can get 
the
meaning of the current purpose...
Dave: If I go to Google, which will apply: user web search. Will add 
updated
examples column.
Mathias: Would it make sense to put a textual description in. This 
would be
a long description field (own ad-hoc)
Dave: This is bound to be desireable for meaningful communication.
Especially for people who can't find theirs on the list.
Rigo: In the EU you care about the primary purpose, in the US, you care
about secondary. Important goal to express EU directives.
Lorrie: I think it can be useful in that respect. The actions are fairly
complete. Some additional types will come up.

Received on Monday, 22 March 2004 20:53:52 UTC