Intent to Prototype: First-party sets
Lily Chen
Contact emails
{bingler,chlily,davidben,kaustubhag}@chromium.org
Explainer
Summary
Introduce a mechanism by which a set of registrable domains (a "First-Party Set") can declare themselves to be the same "party" or entity, such as web properties owned by the same company, or domains with different ccTLDs used by the same website. A First-Party Set applies to all HTTPS origins with a registrable domain that is the owner or a member element of the set. This proposal is for a simplified initial prototype.
Motivation
In support of potential browser privacy models to restrict cross-party tracking, web platform features can use First-Party Sets to determine whether embedded content may or may not access its own state. First-Party Sets define a more realistic “privacy boundary” by reflecting the real-world organization of websites, which often span multiple registrable domains.
Firefox's Enhanced Tracking Protection features use a list of "entities" maintained by Disconnect, so that third-party resources are not blocked if they belong to the same entity as the top-level site. Edge's tracking prevention feature includes an "Org Relationship Mitigation" that exempts third-party content from being blocked if the resource's URL belongs to the same organization as the requesting site. This proposal aims to standardize such behavior by introducing First-Party Sets as the web's privacy boundary, replacing the existing ad hoc and UA-specific behavior.
Some potential uses enabled by First-Party Sets are listed below. These are not in scope for the current proposal, and are listed here only for background. Separate proposals will be shared when these are ready to be prototyped:
Cross-domain first-party cookies: Often, the website the user is interacting with may be deployed across multiple domain names. Since cookies default to SameSite=Lax, the use of cookies in such contexts requires the SameSite=None attribute, even though the ostensibly "cross-site" usage is actually more narrowly scoped to domains that belong to the same First-Party Set. A SameParty cookie attribute, which restricts access to cookies by First-Party Set (rather than by site), allows cookies to be more precisely scoped so that widespread reliance on SameSite=None can be phased out.
Partitioned network caches: In Chromium, the HTTP cache, socket pools, and other caches of network state are currently partitioned by top-frame site and subframe site. By sharing network state along First-Party Set groupings, cache hit rates can be improved while retaining the privacy boundaries enforced by partitioned state.
Anti-fingerprinting: In order to limit how much information about individual users is exposed to sites, the browser can enforce a privacy budget for API calls that reveal a large amount of stable or semi-stable information identifying a particular user or device (a "fingerprint"). A shared privacy budget can apply to members of a First-Party Set, such that the amount of information accessible to a single entity (even an entity controlling multiple sites) is limited.
Risks
Interoperability and Compatibility
This is not a breaking change. Sites will opt in to using First-Party Sets. For this initial prototype phase, there is no change to existing behavior for sites not opting in to First-Party Sets.
Edge: Positive (supportive of continued discussion)
Firefox: Opposed (harmful)
Safari: Positive (support for working together in a W3C CG)
Web / Framework developers: Positive signals as demonstrated in W3C PrivacyCG discussions
Ergonomics
The initial prototype will support use of First-Party Sets with the SameParty cookie attribute. (There will be a separate Intent to Prototype for the SameParty cookie attribute.) There are no performance concerns.
Activation
Sites will create first-party sets and assert their membership within the appropriate set. This assertion is then subject to a verification process to ensure that the registrable domain meets a published policy. The browser reads this assertion and, if the set has been verified, the browser then treats those domains as the same party (or first-party). Policy specifics are still being refined, and will be posted here when they are finalized. The intent is to ensure that first-party sets reflect common ownership and privacy policy details, as well as user understanding of the first-party affiliation.
Security Risks
None
Debuggability
No changes to DevTools are planned at this stage.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No. This will be supported on Windows, Mac, Linux, Chrome OS, and Android, but will not initially be supported on Android WebView. In the initial prototype, the First-Party Set information will be delivered via component updater, which is not supported on Android WebView.
Is this feature fully tested by web-platform-tests?
No WPTs yet (not testable at the content layer). This proposal is still in its early stages. The associated policy component is expected to evolve over time. Once the shape of the policy, specification, and implementation are better understood, we'll reevaluate whether/how to test in WPTs.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5640066519007232
Requesting approval to ship?
No
Yoav Weiss
Contact emails
{bingler,chlily,davidben,kaustubhag}@chromium.org
Explainer
Summary
Introduce a mechanism by which a set of registrable domains (a "First-Party Set") can declare themselves to be the same "party" or entity, such as web properties owned by the same company, or domains with different ccTLDs used by the same website. A First-Party Set applies to all HTTPS origins with a registrable domain that is the owner or a member element of the set. This proposal is for a simplified initial prototype.
Motivation
In support of potential browser privacy models to restrict cross-party tracking, web platform features can use First-Party Sets to determine whether embedded content may or may not access its own state. First-Party Sets define a more realistic “privacy boundary” by reflecting the real-world organization of websites, which often span multiple registrable domains.
Firefox's Enhanced Tracking Protection features use a list of "entities" maintained by Disconnect, so that third-party resources are not blocked if they belong to the same entity as the top-level site.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24OxyMx%3DYvB6_MSCFhWkTyEeZW6iZwM_quQDB_7_2fyQZw8Q%40mail.gmail.com.
Lily Chen
Thanks for working on this!On Mon, Aug 17, 2020 at 11:27 PM Lily Chen <chl...@chromium.org> wrote:Contact emails
{bingler,chlily,davidben,kaustubhag}@chromium.org
Explainer
Summary
Introduce a mechanism by which a set of registrable domains (a "First-Party Set") can declare themselves to be the same "party" or entity, such as web properties owned by the same company, or domains with different ccTLDs used by the same website. A First-Party Set applies to all HTTPS origins with a registrable domain that is the owner or a member element of the set. This proposal is for a simplified initial prototype.
Motivation
In support of potential browser privacy models to restrict cross-party tracking, web platform features can use First-Party Sets to determine whether embedded content may or may not access its own state. First-Party Sets define a more realistic “privacy boundary” by reflecting the real-world organization of websites, which often span multiple registrable domains.
Firefox's Enhanced Tracking Protection features use a list of "entities" maintained by Disconnect, so that third-party resources are not blocked if they belong to the same entity as the top-level site.
That's interesting, given that their opposition is mainly grounded in UI treatment and user understanding of the relationships between e.g. example-brand.com and other-brand.com.Do they somehow surface that in their UI?
Yes, but only by omission of the same-entity third-party from indications of "blocked cross-site trackers" and "known trackers" surfaced in the UI. The entities.json affiliations are not directly surfaced in the UI.
However, Firefox have expressed that their use of the Disconnect.me list is a medium-term solution and something that they hope to remove the need for long-term. Since FPS is proposed as a long term web-platform mechanism, they would like to pay closer attention to how users can discover/understand the affiliations.
The explanation for Mozilla's use of the entity list doesn't quite address UI treatment. It says, "For example, if abcd.com owns efgh.com and efgh.com is on the blocklist, it will not be blocked on abcd.com. Instead, efgh.com will be treated as first party on abcd.com, since the same company owns both. But since efgh.com is on the blocklist it will be blocked on other third-party domains that are not all owned by the same parent company."
This matches the empirical behavior of Firefox 79.0, in which the "Standard" mode of Enhanced Tracking Protection (described as "Balanced for protection and performance. Pages will load normally.") does the following. (amazon.com and amazon-adsystem.com are listed as the same entity, whereas cnn.com and amazon-adsystem.com are not.)
Loading cnn.com makes a cross-site request to s.amazon-adsystem.com, but it does not carry request cookies. The list of "cross-site tracking cookies blocked" in the Protections dialog lists s.amazon-adsystem.com. There is a crossed-out shield icon with a tooltip marking the request as matching "a known tracker".
Loading amazon.com makes a cross-site request to s.amazon-adsystem.com, which carries request cookies. There is no indication that this domain is considered a tracker.
As far as I can tell, (in this ETP configuration,) cross-site cookies for a same-entity-third-party are not blocked, and requests are not marked as matching "a known tracker".
Perhaps someone from Mozilla can chime in, if I missed something.