Re: Concerns re: Same-Entity proposal

On Wed, Nov 05, 2003 at 09:58:57AM -0600, Humphrey, Jack wrote:
> 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.

I think, this is a question for the UA-Guidelines. So if we have a
relationsship proposal, this will be then considered by the UA-TF or the
WG as a whole under the angle of our current UA-Guidelines proposal.
> 
> > 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.

The issue here is that we have already the term agent in our
specification, but it is not defined. So the concept of agent in a
narrow sense already works for the vocab, but not for the PRF. I think
like general federation is an issue, the term of 'agent' is also an
issue. Therefor, I suggest we discuss that on the next call. 
> 
> > 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. 

This assumption is not quite correct. A PRF can point to a multitude of
policies with different entities being responsible. So the question is,
whether the element <known-hosts> should go at the top level or one
level down into the <policy about='uri'>

It is not impossible, that an entity is having their own site and
getting some service from some other site. IMHO, this is rather common,
if you get counting service, database inclusion etc. All depends on
whether this is just an independend service used or whether there are
contractual relationsships that also include rules for the use of the
data collected.

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

I think, this is too much overhead as we would have to write another
IETF-Draft and push it through their procedures. I would rather stick
with the PRF-expiry. 

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

Also note, that in case of headers, the evaluation is real time and does
not need all the caching. In this case, it is easier to just evaluate
the header CP that comes anyway instead of adding complicated agent
relationsships. 

The relationsship proposal should not serve to circumvent shortcomings
of the compact format that lead to blocking of cookies because they
contain an overstatement leading to unacceptable policies. This should
be solved in another way. It shouldn't be possible to hide a bad
practice behind a good policy and some complex domain relationsships.
> 
> > 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.

Again, third party cookies are not a concept of P3P! P3P distinguishes
between cookies with acceptable policy and those that haven't an
acceptable policy.

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

You try to solve the wrong problem here. Or P3P in 1.1 should accept and
incorporate the notion of third party content and state on this. If you
wish to discuss it, raise it on the mailing-list.

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

Nice example for further improvements.. But this is rather a tip for
implementers than a direct thing for the specification.

Best, 

Rigo

Received on Monday, 24 November 2003 15:27:35 UTC