Thanks for the question!

Perhaps our attempt to strictly follow the normative format in the prescribed W3C explainer template didn't serve us very well; because I think of FPS less as a concrete platform feature, and more as a technical manifestation of the concept of "party" or "same-party", as pertains to the definition of "tracking on the web".

IMO, the direct answer to the question you posed is:

2. Develop a coherent definition of "first-party" vs "third-party" for privacy mechanisms on the web platform.

(However, many find this answer too abstract, because they are looking for more concrete goals like they would typically see in an explainer for a new platform feature, and that's how goals 1 and 3 came in)

Here, "privacy mechanisms" refers to changes to existing platform features (such as restrictions on access to cross-site cookies), as well as new platform features (such as WebID), that are defined elsewhere. The collective goal of these mechanisms is to (loosely speaking) "prevent tracking on the web".

The DNT specification's definition of tracking, which is consistent with major browsers' definitions, is as follows:

Tracking is the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. A context is a set of resources that are controlled by the same party or jointly controlled by a set of parties.

I personally find Mozilla's paraphrasing of the same sentence easier to read:

Tracking is the collection of data regarding a particular user's activity across multiple websites or applications (i.e., first parties) that aren’t owned by the data collector, and the retention, use, or sharing of data derived from that activity with parties other than the first party on which it was collected.

In fact, the DNT specification also had a technical manifestation of "same-party" that sites self-declared [example]. Further, the specification says:

A user agent might use the same-party array, when provided, to inform or enable different behavior for references that are claimed to be same-party versus those for which no claim is made. For example, a user agent might choose to exclude, or perform additional pre-flight verification of, requests to other domains that have not been claimed as same-party by the referring site.

Important: With the FPS proposal, we explicitly do not want to automatically make different security decisions for same-party domains. This is because modern web applications may consciously choose to separate untrusted content onto another same-party domain.

We list the set of mechanisms that we intend for to use FPS in the explainer's Applications section. We won't claim that the list is complete, because much of the work in this space is actively evolving. In fact, we already know that we need to add navigational tracking / bounce tracking prevention as another application (but that work item is just now spinning up in the PrivacyCG).

As evidenced on #53 , we don't all agree on the set of applications yet; but as you suggest, perhaps the key to resolution is to first examine the answer to your headline question. I hope my explanation delivered an answer.

Perhaps @krgovind could use an existing set as an example?

Google defines what could be considered a set in their browser source code today. See this list.

  ".android.com",
  ".doubleclick.com",
  ".doubleclick.net",
  ".ggpht.com",
  ".googleadservices.com",
  ".googleapis.com",
  ".googlesyndication.com",
  ".googleusercontent.com",
  ".googlevideo.com",
  ".gstatic.com",
  ".litepages.googlezip.net",
  ".ytimg.com",

How would FPS apply to this group of domains and what would the benefits for the web be?

None of these are likely to be visited as a FP

@jwrosewell - Based on the source code call-sites/references to that function, I don't believe that list is related to First-Party Sets, since the usage does not overlap with our list of proposed Applications in the browser.

@krgovind - Thank you for confirming this group of domains would not be considered a first party set. I wonder therefore what this set of domains should be called. Perhaps a third-party set?

@krgovind - Thank you for confirming this group of domains would not be considered a first party set. I wonder therefore what this set of domains should be called. Perhaps a third-party set?

My apologies for missing your last message. I don't believe we need to define a "third-party set", or any platform API at this time because the usage of the list doesn't pertain to any platform-wide capability/usecase.

I'm closing this issue since I've answered the originally posted questions in my comment.

I was specifically looking for answers from others, because it was not clear that there was agreement about the purpose of the feature. @krgovind, do you truly believe that this ambiguity has been resolved?

I was specifically looking for answers from others, because it was not clear that there was agreement about the purpose of the feature. @krgovind, do you truly believe that this ambiguity has been resolved?

Ah sorry, I didn't realize that you were posing the question to the group at-large. You had quotes from the explainer, so I presumed those needed clarification. :)

Would it be helpful for us to expand on the Applications section, and how these fit in with privacy protections across browsers?

What I'm looking for is some sort of consensus about the purpose.

What I'm looking for is some sort of consensus about the purpose.

Right. I'm suggesting that perhaps discussing what Applications there is interest in, will lead us to consensus on the purpose. I think of FPS/"party" as more a concept analogous to "origin" or "site", and less as a mechanism.

My apologies if I'm being slow to fully comprehend the central question here; but IMO, the methodology we could go about getting to the purpose really depends on how many of us are comfortable with "bottom-up" vs. "top-down" thinking. I'm suggesting the "bottom-up" approach.

@martinthomson, please look at PR #84 for potential applications of FPS. Our goal is to use the application section to drive consensus on use cases & purpose for FPS.

Emberi nyelven, emberi logika mentén emberi használatra tervezünk és fejlesztünk.