News
Related Website Sets vs Partitioned Cookies for Brands
July 18, 2025
Related Website Sets vs partitioned cookies for brands is two ways browsers treat cookies across related origins. Partitioned cookies (CHIPS) isolate a third-party cookie per top-level site so site A and site B do not share the embed's jar. Related Website Sets (RWS) lets a primary site declare a small set of related domains so participating browsers may treat some storage as same-party within that set — still not a security boundary. Neither replaces SameSite=Lax on your login cookie. A brochure that only needs its own origin can skip RWS entirely. RoastMyOpsec grades Set-Cookie on the landing response and pattern-matches known trackers. It does not fetch /.well-known/related-website-set.json, does not score RWS, and does not load you in third-party iframes.
The practical difference
CHIPS is a cookie attribute: Partitioned. RWS is a declared list of sites, historically via a well-known JSON file and a submission process. Topics is an ads interest API. Storage Access API is a user-gesture path for embeds. Do not stack all four because a vendor slide said 'cookies are changing.'
Declaring shop.example and news.example as related does not make a shared session cookie safe. CSRF and XSS still follow the cookie flags and the origin that set them.
How to choose for a public brand
One marketing origin: first-party analytics, Lax sessions, no RWS. Widget embed that must remember a user on other sites: Partitioned None on a dedicated cookie, not the login cookie. Multiple first-party hostnames that already share a login: keep the session first-party per host or use a documented SSO — do not treat RWS as SSO. Permissions-Policy still governs unused device APIs.
| Control | What it groups | Brochure default | Takeaway |
|---|---|---|---|
| Partitioned (CHIPS) | Embed cookie per top-level site | Use if you must embed | See partitioned vs None |
| Related Website Sets | Declared related domains | Skip unless you operate a set | Not a roast F if missing |
| First-party Lax session | Your login origin only | Usual win | Do not mark it None |
| Topics API | Coarse ad interests | Skip unless you sell ads | See Topics vs cookies |
When Related Website Sets still wins
RWS wins when you already operate a small, documented set of first-party domains and a privacy review blessed the declaration. Partitioned cookies still win for third-party widgets. Missing RWS is healthy. Pair with third-party trackers vs first-party analytics if the 'set' is actually an ad graph.
What the roast can prove
Set-Cookie flags and known tracker hosts in HTML can surface. Related Website Sets membership is not scored. Confirm the well-known file and cookie attributes yourself. Pair with consent-based scanning — do not treat another brand's set as research.
Common mistakes
The first mistake is treating RWS as a WAF or as proof third-party cookies are gone.
The second mistake is putting the login cookie in a set so 'users stay signed in everywhere.'
The third mistake is requiring a related-website-set.json as an OPSEC finding.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is missing Related Website Sets a vulnerability?
- No. It is a Privacy Sandbox grouping choice. Missing it is not a roast F.
- Does RWS replace partitioned cookies?
- No. CHIPS isolates embed cookies per top-level site. RWS declares related first-party domains. Login cookies should stay first-party Lax.
- Does RoastMyOpsec fetch related-website-set.json?
- No. It reads landing Set-Cookie and may pattern-match known marketing hosts. Confirm the well-known file yourself.