- From: Lorrie Cranor <lorrie@cs.cmu.edu>
- Date: Mon, 29 Mar 2004 22:50:05 -0500
- To: "Humphrey, Jack" <JHumphrey@coremetrics.com>
- Cc: 'public-p3p-spec' <public-p3p-spec@w3.org>
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 Monday, 29 March 2004 22:50:22 UTC