News
Topics API vs Third-Party Cookies for Marketing Sites
March 22, 2026
Topics API vs third-party cookies for marketing sites is two advertising identity models. Third-party cookies (especially unpartitioned SameSite=None) let an embed recognize the same browser across sites. The Topics API (Privacy Sandbox) lets participating sites observe coarse interest topics the browser computed — not a durable cross-site cookie, still a measurement channel. Neither is access control. A brochure that needs pageviews can stay on first-party analytics and skip both. Permissions-Policy can restrict browsing-topics. RoastMyOpsec pattern-matches common analytics and marketing hosts in public HTML. It does not score Topics, does not call document.browsingTopics(), and does not treat missing Topics as an F.
The practical difference
A third-party cookie is a shared jar. Partitioned cookies (CHIPS) isolate per top-level site. Topics is an API on the page origin after the user has a history the browser classifies. Client Hints are another browser-described surface. See partitioned cookies, Storage Access API, and Client Hints vs User-Agent.
Adding a Topics snippet because 'cookies are dying' still adds a third-party script unless you use a first-party wrapper you actually control.
How to choose a measurement plan
Need counts on your own site: first-party analytics, tight cookies, no None on the session. Need ads: talk to counsel and vendors; do not paste unpartitioned trackers 'until Topics works.' Use Permissions-Policy to disable unused Topics if you do not participate. ads.txt is authorized sellers, not a tracker toggle.
| Channel | What it shares | Brochure default | Takeaway |
|---|---|---|---|
| Unpartitioned third-party cookie | Cross-site identity | Avoid | High CSRF and tracking cost |
| Topics API | Coarse interests, if enabled | Skip unless you sell ads | Not a roast F if missing |
| First-party analytics | Your origin's counts | Usual win | See trackers vs first-party |
| Permissions-Policy | Can restrict browsing-topics | Disable unused APIs | See Permissions-Policy guide |
When Topics still wins
Topics wins as a vendor requirement on a site that already runs ads and has a privacy review. First-party analytics still wins for a brochure. Missing Topics is healthy. Pair with ads.txt if you actually sell inventory.
What the roast can prove
Known tracker hosts in HTML can surface. Topics participation is not scored. Confirm Permissions-Policy and scripts yourself. Pair with consent-based scanning — do not roast third-party ad hosts as research.
Common mistakes
The first mistake is keeping unpartitioned ad cookies 'as a backup' after adding Topics.
The second mistake is treating Topics as a security header.
The third mistake is requiring Topics 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 Topics API a vulnerability?
- No. It is an ads/measurement choice. Missing it is not a roast F.
- Does Topics replace first-party analytics?
- No. Topics is an interest signal for participating ad flows. Pageviews still belong first-party if you need them.
- Does RoastMyOpsec call the Topics API?
- No. It may pattern-match known marketing hosts in HTML. It does not observe topics.