FAfastest963·May 2, 2025
This is already a feature called "Related Websites": https://github.com/WICG/first-party-sets
In Third party cookies must be removedWICG
first-party-sets
Bikeshed2020–2025
WICG / first-party-sets · Archived
first-party-sets
Discover this repository through its Hacker News conversations.
7Distinct people
8Mentions
0Explicit recommenders
401GitHub stars
What to know before exploring
What it is
A public description has not been verified.
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- googlechrome/related-website-sets · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year8 dated mentions
Observed mentions: 2020-09-11 13:34:04 UTC to 2025-05-02 22:33:09 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
8 sourceshttps://github.com/WICG/first-party-sets#non-goals has:
Non-goals: ... Information exchange between unrelated sites for ad targeting or conversion measurement.
To get something onto the list (https://github.com/GoogleChrome/first-party-sets/blob/main/f..., currently empty) you need to make a public PR with rationale (https://github.com/GoogleChrome/first-party-sets/blob/main/F...). It doesn't look to me like DoubleClick would qualify?
In New in Chrome 113First party sets are a centralized list of sites that act as one logical site. The list is gated by the browser vendor. Details here (https://github.com/GoogleChrome/first-party-sets/blob/main/F...).
This is intended to deal with several technical challenges (https://github.com/WICG/first-party-sets#use-cases), such as the technical challenge that when company A buys company B, the process of fusing the auth rules so that being logged into A implies a login to B is a colossal nightmare project under first-party-only rules. So, for example, this lets Facebook declare that instagram.com is in the same FPS as facebook.com to simplify the auth story. What it should not allow is for joe-random-domain.com to declare that the DoubleClick ad endpoints are first-party to them.
In New in Chrome 113There's at least one proposed solution for this--replacing the public suffix list with first party sets:
https://github.com/privacycg/first-party-sets
In Public Suffix List Problems (2019)> if it would hasten the demise of 3rd party cookies
Will FLoC speed this up?
As far as I know, Firefox, Chrome, and Safari are already largely publicly committed to phasing out 3rd party cookies over the next couple years. I guess FLoC might move that deadline up a bit?
But I suspect some critics of FLoC are looking at the proposal as a compromise that we don't need to make. The thinking is, at the point where we have public statements from every single major browser, including Chrome and Edge, that 3rd party cookies are going to get phased out, why do we need to throw the advertising industry a bone? We won this particular fight, 3rd party cookies are going out the door. Now (the thinking is) we just need to make sure that counter-proposals like FLoC and FPS[0] don't reverse the gains we've made.
I'm not completely sure how to character
Read the rest
ize Google's recent proposals, but an arguably reasonable take that I've seen online is that Google somehow got peer-pressured into making a very public commitment to remove 3rd-party cookies, that they no longer feel they can back down from that commitment, and that a lot of their recent proposals seem to be attempts to find some way to get out of that deal. First Party Sets in particular are just a very conveniently timed proposal. I suspect this take is at least a little simplistic, but if it is at all accurate then now is a very good time to increase pressure on Google, not decrease it.
So I think we might be in a situation where the onus is on people proposing compromise to prove that compromises will make a difference, because I don't take it for granted at this point that FLoC's acceptance or rejection will change anything about how 3rd party cookies are handled in the future.
[0]: https://github.com/privacycg/first-party-sets
How would you propose handling this with DNS? Here are some things it covers:
* a.example.com and b.example.com are the same site
* a.co.uk and b.co.uk are not the same site
* a.cloudfront.net and b.cloudfront.net are not the same site
* a.higashikawa.hokkaido.jp and b.higashikawa.hokkaido.jp are not the same site
* a.example.higashikawa.hokkaido.jp and b.example.higashikawa.hokkaido.jp are the same site
There is a proposal to do something similar using response headers and .well-known urls: https://github.com/privacycg/first-party-sets
In Google Safe Browsing can kill a startupI didn’t see it mentioned but a common use case for 3rd party cookies is correlating session data across your own multiple domains (if your company owns multiple domains). Publishing companies typically own multiple domains/verticals and can increase ad revenue / seo / traffic quality by linking properties together. It’s important to be niche as a site (verticalization) but also broad as a publishing operation (own many verticals and shift your marketing spend daily).
Anyways, google has been writing a spec for “first party sets” to help replace the use of a 3rd party cookie to connect domains you own. https://github.com/privacycg/first-party-sets
I believe this will need to be implemented before Chrome moves aggressively against 3rd party cookies.
In Google Chrome browser privacy plan investigated in UKWe are. Deliberate sabotage like that would take quite a while before it was noticed, however, and it wouldn’t magically fix cookies and how people use them.
To the extent it is used by cookies, we still want to maintain a fair and equitable solution. However, we also want to actively discourage any new users or use cases, to the extent possible, while we also try to fix cookies.
Ideas like https://github.com/privacycg/first-party-sets provide a possible model. While FPS doesn’t directly address this, as part of keeping a narrow scope, the approach to explicitly expressing boundaries is one that has the best viable path. However, that’s effectively “Deprecate the Host option for cookies”, so... that’s a big task.
Simply sabotaging the PSL doesn’t force the problem to be solved, so mostly, it’s an education campaign of “We made a mistake;
Read the rest
learn from ours, rather than repeating it.”