Re: first party resource

This would add an extra 1xRTT to pageload, and block ALL subresources, no?
My understanding of your proposal is that I would have to fetch /, wait for
the response which indicates where I find its DNT info (or perhaps it's at
a well-known location?) and then only after I get this array of "here's how
big I am" can I issue subsequent requests, as I need to know if I'm
interacting with a 1st or 3rd party to send the correct header in the

On Tue, Apr 10, 2012 at 2:00 PM, Roy T. Fielding <> wrote:

> I am unsatisfied by all of the first-party definitions because I don't
> consider
> them to be implementable (e.g., neither "can infer with high probability
> that the
> user knowingly and intentionally" nor "the party that owns the Web site or
> has
> control over the Web site" can be determined programmatically).
> I suggest that we simply state:
>  1) A first-party resource is a resource that has been designed for direct
>     interaction with a user.
>  2) When a user interacts with a given first-party resource, all
> subrequests
>     made to that first-party's domain or to any of the domains listed in
> the
>     same-party array within the first-party's tracking status resource are
>     also considered first-party resources; all other subrequests are
> considered
>     third-party resources.
>  3) The same-party array MUST be limited to domains that are owned or
> controlled
>     by the same legal entity that owns or controls the first-party as well
> as
>     domains that qualify as third parties acting on behalf of this first
> party.
>  4) The same-party array SHOULD be limited to domains that share sufficient
>     context with the first-party, such that the user has a reasonable
> expectation
>     that data provided to any of these domains might be shared or combined
> with
>     data provided to the other same-party domains.
>  5) Data provided to first-party resources is subject to first-party
> compliance
>     requirements; data provided to third-party resources is subject to
> third-party
>     compliance requirements.
> ....Roy

Received on Wednesday, 18 April 2012 15:44:52 UTC