W3C home > Mailing lists > Public > public-p3p-spec@w3.org > November 2003

Re: Concerns re: Same-Entity proposal

From: Rigo Wenning <rigo@w3.org>
Date: Tue, 4 Nov 2003 01:00:52 +0100
To: "'public-p3p-spec@w3.org'" <public-p3p-spec@w3.org>
Message-ID: <20031104000051.GA830@rigo.w3.org>

On Wed, Oct 22, 2003 at 03:31:48PM -0400, Dobbs, Brooks wrote:
> 1)       We need be careful between providing tools on which to make policy
> and making policy itself.  While it may be a useful tool to have the ability
> to state that collection covered by separate PRFs  is under the control of
> the same entity, ultimately it is up to the UAs to decide how they want to
> implement these tools.

I think, the beneficial in this proposal is, that it allows to have a
means by which the double control on PRF's is checked. In fact, the same
entity requires that the issuing host's PRF mentions the same entity AND
the same entity has to refer to the issuing host. As configuration of
both needs privileged access to configuration files, hacking without
control of those files will be harder. Therefor, I think the addressing
mechanism is good, but I have issues with the semantics like I expressed
them during the last calls.

> 
> 2)       We use the term entity (and later in the agent relationship
> proposal - "agent") without providing sufficient guidance on what this
> means.  Rigo suggests there may be ways around this but I think they would
> be unclear at best and difficult to explain to the end user.  This suggests
> to me that point 1) may mean that UAs don't act on this tool if they had it.

I referred to the rather clear definitions in the EU Directive, where a
data controller is the entity that controls data processing, means has
power to order, manage and prohibit things. The agent for me here is a
data processor, means an entity that does some processing on behalf of
somebody else (i.e. with a contractual background that allows that
control). But I agree, that this is rather complex.

> 
> 3)       I think that there is an issue in that entity is today defined at
> the policy level.  A PRF for a host can reference 2 distinct policies each
> of 2 distinct entities (data controllers) - how then can there be meaning to
> say at the PRF level this entity is the same as anything else?  The same as
> which of the 2?

Don't forget, that the entity is not defined at the PRF-level but at the
Policy-level. This means that a same Policy with the same entity can be
referenced by multiple PRF's. We extend that proposal now to multiple
PRF's by the way of allowing third party PRF's to reference other PRFs.

> 
> 4)       There would need to be a mechanism to expire same entity
> relationship.  This may be handled through the expiry in policy files but
> there is currently no such mechanism for CPs

Advantage and disadvantage of CPs is, that they have a lifetime for
exactly the request that is made. So no need for expiry on CPs. CPs are
out of scope here. I know that the issue came from the CPs and from the
third party cookies. But we would be rather unwise to remove the
incentive to create policies in the third party context. BUT: Full
policies in the third party context were a nuisance so far and this
proposal might remedy the performance issues attached to it, if we get
it right.

> 
> 5)       Headers are limited practically by the number of same hosts that
> they can declare.  Also declaring multiple "same-entity" relationships would
> presumably require a validation against each full policy prior to accepting
> the accuracy of the header declaration.  This is somewhat illogical, as, IF
> we where to accept the performance hit of policy prefetching, then we would
> have no need for CPs!  Jack rightly points out that we may only need to
> validate against the PRF and not the policy - but I think that I may have
> brought that into question with point 3).

As far as I remember our discussion, the same host has to reference the
PRF of the referring host. (apart from CP, where we are in a stateless
context). This means that we might obtain sufficient performance
improvements to get rid of CPs and avoid the false declarations inherent
to the summary-nature of CPs.

> 
> 6)       Again on the topic of CPs, once a same entity relationship has been
> established between cookie (set by A) and site B from which an asset
> appears, how they can a same entity relationship be established from a
> subsequent replay on site C (provided that PRFs or policies) for all these
> sites do indeed declare each other as same entity?

This shows the issues which were discussed the most. It means that
browsers would have to switch to pay attention to cookies replayed. At
the moment, the performance improvement is that we only evaluate cookies
at set-cookie. If the same cookie is re-used in different contexts,
either you declare up-front all the potential uses or you evaluate on
the replay-time. While 1/ is good for browsers, 2/ is good for content
providers using the same cookie in different contexts. This might be
easier with the full format, where specific data has a specific
statement attached to it. In the context of CP, this just turns into
nightmare, as the potential overstatement is huge. The same entity
proposal does not remedy the situation. But it would perhaps allow the
browsers to get sufficient performance to do full policy. Full policy
remedies as it allows for fine-grained expression of data concerned.

Best, 

Rigo
Received on Monday, 3 November 2003 19:01:01 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 17 March 2004 17:46:28 EST