RE: first party resource

I think its ok (although not ideal) for those desiring more rigorous controls to experience a bit poorer performance if that is the only way we can provide those controls, as long as it does not affect those who do not turn on the setting.  That would just be part of the tradeoff.  Obviously we would want to ensure the experience is still as good as possible, but there may be some compromising we will have to make with performance.
From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: Wednesday, April 18, 2012 10:52 AM
To: ifette@google.com
Cc: Tracking Protection Working Group WG
Subject: Re: first party resource

On Apr 18, 2012, at 8:44 AM, Ian Fette (イアンフェッティ) wrote:


This would add an extra 1xRTT to pageload, and block ALL subresources, no?

This alone?  No.  This is primarily just a way to define the scope of a
first party such that our requirements make sense.  A user agent that
*needs* this info can get it.  If they don't need it, they would not get it.

E.g., if the user agent *wants* to send different header to the claimed
first-party sites (as opposed to just the primary request vs subrequests),
then it would need this information to do so; if it just wishes to send
a different value on subrequests, then it does not need the info.
A user agent that is coloring request elements based on the distinction
could check the info either pre or concurrent with rendering.

....Roy


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 request?
On Tue, Apr 10, 2012 at 2:00 PM, Roy T. Fielding <fielding@gbiv.com<mailto:fielding@gbiv.com>> 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