RE: domain relationships

Yep. What Lorrie said. :)

-----Original Message-----
From: Lorrie Cranor [mailto:lorrie@cs.cmu.edu]
Sent: Tuesday, March 30, 2004 8:47 PM
To: Dobbs, Brooks
Cc: public-p3p-spec
Subject: Re: domain relationships




On Mar 30, 2004, at 5:30 PM, Dobbs, Brooks wrote:

>
> I don't think that you want it to carry through to multiple levels deep
> - at least from an adserving perspective.
>
> Adserver.com may be an agent of Publisher.com and serve an iframe onto
> Publisher.com but it is totally possible that what is referenced by 
> that
> iframe is from agency.com with absolutely no relationship to
> publisher.com.  Also there are often multiple layers of redirection.

You only carry through to multiple levels the hosts referenced in an 
our-host tag. So in your example, if there is no relationship with 
agency.com then they wouldn't be mentioned in the our-host tag. So I 
think this works.

Lorrie


>
> Sorry, I likely won't be on the call tomorrow.  On a plane to NY - not
> sure if I'll be at the office by 11.
>
>
> -Brooks
> -----Original Message-----
> From: public-p3p-spec-request@w3.org
> [mailto:public-p3p-spec-request@w3.org]
> Sent: Tuesday, March 30, 2004 5:20 PM
> To: 'Lorrie Cranor'
> Cc: 'public-p3p-spec'
> Subject: RE: domain relationships
>
> Here's an attempt to be more explicit:
>
> <p>The <i>OUR-HOST </i>element is declared in the <i>POLICY-REF</i>
> element.
>
>     For URIs covered by the associated policy, the user agent can
> encounter
> other
>     hosts in different domains serving embedded content, link, or 
> action
> requests.
>     The user agent may consider such a host to be owned by the same
> entity
> or
>     one of its agents if its URI matches an associated <i>OUR-HOST</i>
> entry.
>     Any number of <i>OUR-HOST </i>elements can be declared inside a
> <i>POLICY-REF
>     </i>element.</p>
>   <p>Embedded content is considered to be any content that is retrieved
> during
>     the processing of the current document, such as images, documents 
> in
> frames,
>     script files, etc. Content embedded more than 1 level deep (e.g. an
> image
>     inside a frame) is still considered embedded content and the
> our-host
> declarations
>     at the top-level may still apply.</p>
>   <p></p>
>   <p>Any relationships inferred by this mechanism are valid only in the
> context
>     for which they were discovered -- this is not a mechanism for
> declaring
> globally
>     that two hosts have a relationship in all contexts. By extension,
> the
> relationships
>     are not transitive. Suppose two distinct hosts A and C are matched
> by
> <i>OUR-HOST</i>
>     entries in a policy reference file for host B. Even if the same
> policy
> applies
>     to both, nothing may be inferred about the relationship between A
> and C
> for
>     use in other contexts. The relationships are not transitive even in
> the
> case
>     of multi-level embedded content -- the top-level host must declare
> our-host
>     relationships for all levels of embedded content.</p>
>
> Let me know what you think.
>
> ++Jack++
>
>
> -----Original Message-----
> From: Lorrie Cranor [mailto:lorrie@cs.cmu.edu]
> Sent: Monday, March 29, 2004 9:50 PM
> To: Humphrey, Jack
> Cc: 'public-p3p-spec'
> Subject: Re: domain relationships
>
>
>
> I think what is not explicit is the types of content to which you can
> apply our-host -- that embedded content includes both directly and
> indirectly embedded content. Maybe we need to include some examples
> like "images, frames, images embedded in frames, etc."
>
> Lorrie
>
>
> On Mar 29, 2004, at 10:32 PM, Humphrey, Jack wrote:
>
>> Does this section of the proposal not clarify it?
>> ---
>> Any relationships inferred by this mechanism are valid only in the
>> context
>> of the policy reference file and policy for which they were discovered
>> --
>> this is not a mechanism for declaring globally that two hosts have a
>> relationship in all contexts. By extension, the relationships are not
>> transitive. Suppose two distinct hosts A and C are matched by OUR-HOST
>> entries in a policy reference file for host B. Even if the same policy
>> applies to both, nothing may be inferred about the relationship
>> between A
>> and C for use in other contexts.
>> ---
>> (I think that first sentence needs to be rephrased: "in the context
> for
>> which they were discovered"?)
>>
>> Brooks, in your example, publisher.com would definitely have to
>> declare both
>> weathersite.com and adserver.com as our-hosts. There is no hierarchy
>> or any
>> kind of transitivity.
>>
>> ++Jack++
>>
>> -----Original Message-----
>> From: Lorrie Cranor [mailto:lorrie@cs.cmu.edu]
>> Sent: Monday, March 29, 2004 8:46 PM
>> To: 'public-p3p-spec'
>> Subject: Re: domain relationships
>>
>>
>>
>> Hmm... interesting question. So, my interpretation of the current
>> proposal is that there are no transitive relationships. If
>> publisher.com declares weathersite.com and adserver.com as our-hosts,
>> then both of them can be treated as first party regardless as to
>> whether they are embedded directly or indirectly. That should probably
>> be made explicit.
>>
>> Lorrie
>>
>>
>> On Mar 29, 2004, at 6:12 PM, Dobbs, Brooks wrote:
>>
>>>
>>>
>>> So something we may still need to clarify, if what we are trying to
>>> get
>>> around here is implementers that have 1st and 3rd party restrictions.
>>> Obviously IE makes some of its own defintions.  One such liberty in
>>> the
>>> whole 1st third party thing is they rely on a "parent" request that
>>> determines 1st partyness without ever really defining or even
>>> mentioning
>>> "parent".  I think we assume this parent to be the file that returns
>>> HTML that tells the browser to go pull child assets (beacons, images,
>>> iframes, whatever).  IE has the notion that these sub elements can
>>> have
>>> either a 1st or 3rd party relationship with the parent.  I think you
>>> have addressed how *that* relationship can be more expressive, but
>>> does
>>> anything in current P3P talk to the notion of their even being a
>>> parent
>>> asset?
>>>
>>> Imagine the following scenario.
>>>
>>> Weathersite.com declares an our-hosts relationship with adserver.com.
>>> So now when adserver.com serves ads on weathersite.com there is a way
>>> that weathersite.com can communicate that adserver.com should be
>>> treated
>>> as 1st party.
>>>
>>> Imagine however that there is another site publisher.com which embeds
>>> content not only from adserver.com but also from weathersite.com.
>>> What
>>> is a UA to do?  Is adserver.com an our-host of weathersite.com or of
>>> publisher.com.  Unless there is a definition or hierarchy of parent,
>>> things get messy no?
>>>
>>>
>>> -Brooks
>>>
>>>
>>> -----Original Message-----
>>> From: Humphrey, Jack [mailto:JHumphrey@coremetrics.com]
>>> Sent: Monday, March 29, 2004 5:25 PM
>>> To: Dobbs, Brooks
>>> Subject: RE: domain relationships
>>>
>>>
>>> No, Rigo didn't update it. I've attached the latest version again.
>>>
>>> ++Jack++
>>>
>>> -----Original Message-----
>>> From: Dobbs, Brooks
>>> To: Jack Humphrey (JHumphrey@coremetrics.com)
>>> Sent: 3/29/2004 4:06 PM
>>> Subject: domain relationships
>>>
>>> Jack is this the latest version?
>>>
>>>
>>>
>>> http://www.w3.org/P3P/2004/03-domain-relationships.html
>>>
>>>
>>>
>>> Brooks Dobbs
>>>
>>> Director of Privacy Technology
>>>
>>> DoubleClick, Inc.
>>>
>>>
>>>
>>> email: bdobbs@doubleclick.net <mailto:bdobbs@doubleclick.net>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Received on Tuesday, 30 March 2004 22:50:45 UTC