RE: Concerns re: Same-Entity proposal

Another point on "agent" terminology: I think agent/processor is well
defined in the NAI Web Beacon Guidelines
<http://www.networkadvertising.org/Statement.pdf> Could we use or refer to
those definitions?

++Jack++

-----Original Message-----
From: Humphrey, Jack [mailto:JHumphrey@coremetrics.com]
Sent: Wednesday, November 05, 2003 9:59 AM
To: 'public-p3p-spec@w3.org'
Subject: RE: Concerns re: Same-Entity proposal



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 agree, but if we can find a way to express these relationships
effectively, then I think we should also offer some examples of how UAs
might use the additional information.

> 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.

Is entity not well enough defined in the 1.0 specification? I agree that
agent is difficult, although the data controller/processor terminology from
the EU Directive seems helpful.

> 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?

A PRF can only make declarations about the current site. If the current site
is not entirely owned by a single entity, then it shouldn't use the
same-entity declaration mechanism, as that would not make sense. However, if
it is owned entirely by a single entity, which also owns another site, then
it makes sense for those two sites to declare each other same-entity via the
PRF. Perhaps we should introduce the concept of an entity key in the policy
file which would be matched against a key declaration in the PRF, so that
UAs could further validate the same-entity relationship when parsing the
actual policy files.

> 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

If we have the HTTP header support for declaring same-entity, we can build
an expiration property into it. There seems to be some debate as to whether
or not we should even provide this mechanism for CPs at all, though. Not
sure where I stand on that yet.

> 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).

I think these are good arguments for doing away with the HTTP header portion
of the proposal.

> 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?

Example:
1. UA has been configured to not allow third-party cookies.
2. UA visits a.com. A response from an image request to b.com wishes to set
cookie B1.
3. UA evaluates PRFs and determines that a.com and b.com have a same-entity
relationship. Cookie B1 is accepted.
4. UA visits a.com again. Cookie B1 is sent along on image request to b.com.
5. UA visits x.com, which contains an image reference to b.com.
6. Since B1 is only valid for playback on a.com, UA delays image request to
b.com and fetches x.com's PRF.
7. UA evaluates PRF and determines the x.com and b.com have a same-entity
relationship. 
8. UA sends cookie B1 with image request to b.com.

Notes:
- UA could cache same-entity relationship information along with PRF to
avoid future fetching. 
- Since same-entity is a transitive relationship, the UA could then extend
it to say that x.com and a.com are same-entity for a future transaction.


++Jack++

Received on Wednesday, 12 November 2003 15:49:55 UTC