RE: [ISSUE-60] Will a recipient know if it itself is a 1st or 3rd party?

Another approach looks at the up-front development of domain strategy to simplify the 1st party and 3rd party distinction.

For any online service, it is suggested 2 sub-domains be created - one for internal (1st party) use and one for external (3rd party use).  As both a rooted to the same parent domain, the same cookie set can be accessed by both (as well as specific sub-domain cookies).

For example, ExampleCompany1 creates two sub-domains: ours.examplecompany1.com and yours.examplecompany1.com.  ExampleCompany1 would use "ours.examplecompany1.com" for internal use and would build and distribute technologies to be used by 3rd parties through "yours.examplecompany1.com".

While crisp up-front management is required to ensure the appropriate sub-domain is coupled and implemented correctly, all downstream data collection becomes simple as any data collected through the internal sub-domain should be considered 1st party and all data collected through the external sub-domain would be considered 3rd party.

Of course, any service that is purely 3rd party or 1st party would not need to go through this approach but it wouldn't be difficult to follow it nonetheless just in case a product or service expands its scope of deployment in the future.

- Shane

-----Original Message-----
From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org] On Behalf Of Bjoern Hoehrmann
Sent: Saturday, October 15, 2011 6:18 PM
To: Kevin Smith
Cc: public-tracking@w3.org
Subject: Re: [ISSUE-60] Will a recipient know if it itself is a 1st or 3rd party?

* Kevin Smith wrote:
>In Boston, we talked about how in some cases such as iFrames, a site or
>service may not know whether it was 1st or 3rd party.  As I thought more
>about this, I think the problem might actually be much more widespread
>than iframes.  I do not think there is any generic way to determine if
>even a normal request is a 3rd or 1st party request, because the server
>does not know what domain or site the user is actually on.

You can't tell from an arbitrary HTTP request where the top-level window
in a user's browser is from in all cases, that is correct. Reasons in-
clude that the HTTP request might not be coming from a user agent that
has a concept of a top-level window. With the "differently-branded" con-
cept, I myself as a citizen would not be able to tell 1st and 3rd party
apart either. Is flickr a 1st party when I read my Yahoo! mails? Is some
foo.example.com host 1st party from www.example.com even if the former
is mapped to some "obviously" 3rd party host?

>In other words, it's much easier to say "this is a 1st party than "this
>is not a 1st party", although even that may be inaccurate sometimes.

If it is relatively easy to establish that you are the first party, you
can assume that when you do not positively establish that, then you are
the third party; that would make both determinations equally "easy" even
if the determinations might not be equally as accurate.

>Consequently, I do not think its technically feasible to come up with a
>method or combination of methods that would always accurately determine
>party.  And if it were possible, it is probably outside the scope of
>this document.

I agree that formulating some algorithm that would deterministically
answer who in some particular situation is first party and who is not,
that suits everybody in all circumstances is probably impossible, but I
also do not see why that would be a requirement or why that could not be
met by changing the status quo. If browser can know who is 1st and who
is 3rd party, they can put that information into their requests, for
instance. If the group wishes to discriminate between 1st and 3rd party
requests, I would not regard such a requirement as out of scope either.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 16 October 2011 03:07:59 UTC