mukul975/privacy-data-protection-skills

cookieless-alternatives

- Evaluating and implementing cookie-less tracking alternatives for a post-cookie era.

View source

How to use

  1. Copy the installation command and review the source package before installing it in your own agent environment.
  2. Check the source document for required tools, credentials and supported hosts.
  3. Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill cookieless-alternatives

Before you start

  • Installation does not include a model subscription, API allowance or permission to access your files.
  • Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document

Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.

Cookie-less Tracking Alternatives

Overview

The deprecation of third-party cookies by browsers and increasing consent-driven restrictions on first-party cookies are driving the advertising and analytics industries toward alternative measurement and targeting approaches. Google's Privacy Sandbox initiative, launched in 2019 and iteratively developed through 2024-2026, provides a suite of browser APIs designed to replace cross-site tracking functionality with privacy-preserving alternatives. Alongside browser-based solutions, server-side analytics and probabilistic measurement methods offer additional paths. This skill evaluates each alternative's privacy properties, technical requirements, and readiness for production use.

Privacy Sandbox APIs

Topics API

Purpose: Interest-based advertising without cross-site tracking.

How It Works:

  1. Chrome observes the user's browsing activity (top-level page visits) locally on-device
  2. Each week, the browser classifies visited sites into topics from a taxonomy of approximately 470 advertising-relevant categories
  3. When an ad tech company calls the Topics API on a publisher's site, the browser returns up to 3 topics (one from each of the last 3 weeks)
  4. Topics are selected with 5% random noise (a random topic is returned instead of the true one)
  5. A caller only receives topics that it has also observed the user being interested in (on other sites where the caller was present)

Topics Taxonomy Examples:

Topic IDCategoryLevel
1Arts & Entertainment1
57Arts & Entertainment / Movies2
86Business & Industrial / E-Commerce2
243Shopping / Apparel2
332Sports / Team Sports / Football3

Implementation for Pinnacle E-Commerce Ltd:

javascript
// Check if Topics API is available
if ('browsingTopics' in document) {
  // Observe: register this page visit for topic classification
  // The fetch call with {browsingTopics: true} both observes and retrieves
  const response = await fetch('https://ads.pinnacle-ecommerce.com/topics', {
    browsingTopics: true
  });
  const topics = await response.json();
  // topics = [{ topic: 86, version: "chrome.2:2:1", configVersion: "chrome.2", taxonomyVersion: "2", modelVersion: "1" }]
}

Privacy Properties:

  • No cross-site identifier shared
  • Topics are coarse-grained (470 categories, not granular interests)
  • 5% noise prevents deterministic profiling
  • Users can view and clear their topics in Chrome settings
  • Sites can opt out via Permissions-Policy: browsing-topics=()

Limitations:

  • Chrome-only (no Safari, Firefox support)
  • Coarse targeting compared to cookie-based audiences
  • Adoption depends on ad tech ecosystem support

Attribution Reporting API

Purpose: Measuring ad conversions without cross-site tracking.

Two Modes:

ModeReport TypeDataNoiseDelay
Event-levelPer-conversionSource: 64-bit ID; Trigger: 3 bits (8 values) for clicks, 1 bit for viewsYes (noise applied to trigger data)2 days (click), 1 day (view)
AggregatableAggregate summarySource + trigger combined into histogram bucketsAdditive Laplace noise10-60 minutes (batched)

Event-Level Attribution Flow:

1. User clicks ad on publisher.com
   → Browser stores: source_event_id=12345, destination=pinnacle-ecommerce.com

2. User converts on pinnacle-ecommerce.com
   → Browser matches: trigger_data=2 (e.g., "purchase")

3. After 2-day delay, browser sends report:
   {
     "source_event_id": "12345",
     "trigger_data": "2",
     "source_type": "navigation",
     "randomized_trigger_rate": 0.0024
   }
   → Sent to reporting origin (ads.pinnacle-ecommerce.com)

Aggregatable Attribution Flow:

1. Ad impression/click registered with source keys
2. Conversion triggers aggregation keys
3. Browser generates encrypted aggregatable report
4. Reports sent to aggregation service (Trusted Execution Environment)
5. Aggregation service applies differential privacy noise
6. Summary report returned: { "campaign_A_purchases": 1247 ± 23 }

Implementation for Pinnacle E-Commerce Ltd:

Source registration (on ad click):

html
<a href="https://www.pinnacle-ecommerce.com/product/widget-pro"
   attributionsrc="https://ads.pinnacle-ecommerce.com/register-source">
  Buy Widget Pro
</a>

Source registration response header:

Attribution-Reporting-Register-Source: {
  "destination": "https://www.pinnacle-ecommerce.com",
  "source_event_id": "12345678",
  "expiry": "604800",
  "aggregation_keys": {
    "campaignCounts": "0x159",
    "geoValue": "0x5"
  }
}

Trigger registration (on conversion):

html
<img src="https://ads.pinnacle-ecommerce.com/register-trigger" attributionsrc>

Trigger registration response header:

Attribution-Reporting-Register-Trigger: {
  "event_trigger_data": [
    { "trigger_data": "2", "priority": "100" }
  ],
  "aggregatable_trigger_data": [
    { "key_piece": "0x400", "source_keys": ["campaignCounts"] }
  ],
  "aggregatable_values": { "campaignCounts": 32768 }
}

Protected Audiences API (formerly FLEDGE)

Purpose: Remarketing and custom audience targeting without third-party cookies.

How It Works:

  1. Advertiser adds users to interest groups via JavaScript on their site
  2. Interest group data (ad creative URLs, bidding logic) stored locally in the browser
  3. When a publisher's ad slot runs an auction, the browser executes on-device bidding
  4. Winning ad is rendered in a fenced frame (isolated from the publisher page)
  5. No cross-site data leaves the browser; auction happens locally

Interest Group Join (on pinnacle-ecommerce.com):

javascript
navigator.joinAdInterestGroup({
  name: "widget-pro-viewers",
  owner: "https://ads.pinnacle-ecommerce.com",
  biddingLogicUrl: "https://ads.pinnacle-ecommerce.com/bidding.js",
  ads: [
    {
      renderUrl: "https://ads.pinnacle-ecommerce.com/ads/widget-pro-retarget.html",
      metadata: { "product": "widget-pro", "discount": "10%" }
    }
  ],
  userBiddingSignals: { "viewed_product": "widget-pro", "visit_count": 3 },
  trustedBiddingSignalsUrl: "https://ads.pinnacle-ecommerce.com/signals",
  trustedBiddingSignalsKeys: ["widget-pro-bid"],
  dailyUpdateUrl: "https://ads.pinnacle-ecommerce.com/update-ig",
  lifetimeMs: 2592000000  // 30 days
}, 2592000000);

Privacy Properties:

  • User profile data never leaves the device
  • Auction runs in browser, not on ad server
  • Fenced frames prevent information leakage to publisher
  • K-anonymity requirements on ad creatives (must be shown to sufficient users)
  • Users can view and leave interest groups in Chrome settings

Shared Storage API

Purpose: Cross-site data access with restricted output gates.

Allows writing data from multiple sites into a shared storage partition, but reading is restricted to privacy-preserving output gates:

  • Select URL (choose from a predefined list)
  • Private Aggregation (contribute to aggregate histograms)
  • Fenced Frames (render content without leaking data)

Use Case for Pinnacle E-Commerce Ltd: Frequency capping across sites — count how many times a user has seen an ad without cross-site cookies:

javascript
// On publisher site, inside shared storage worklet
class FrequencyCapOperation {
  async run(data) {
    const count = await this.sharedStorage.get('pinnacle-widget-pro-views') || 0;
    if (count >= 3) {
      // User has seen this ad 3 times — show fallback
      return 1; // Index of fallback URL
    }
    await this.sharedStorage.set('pinnacle-widget-pro-views', count + 1);
    return 0; // Index of ad URL
  }
}

Server-Side Analytics Alternatives

Cookieless Server-Side Measurement

SolutionCookiesPII CollectionHostingConsent Required
Server log analysisNoneIP address (anonymize)Self-hostedNo (operational necessity)
Plausible AnalyticsNoneNo PIIEU cloud or self-hostedVaries by jurisdiction
Fathom AnalyticsNoneNo PIICanadian/EU hostingVaries by jurisdiction
UmamiNone (optional)No PIISelf-hostedVaries by jurisdiction
Matomo (cookieless mode)NoneFingerprint hash (session only)Self-hostedCheck with local DPA

Plausible Analytics Configuration for Pinnacle E-Commerce Ltd

html
<!-- Single script, no cookies, ~1KB -->
<script defer data-domain="pinnacle-ecommerce.com"
  src="https://plausible.io/js/script.js"></script>

What Plausible Collects (per pageview):

  • Page URL (path only)
  • Referrer (domain only)
  • Browser (derived from User-Agent)
  • Operating system
  • Device type (desktop/mobile/tablet)
  • Country (from IP, IP discarded immediately)

What Plausible Does NOT Collect:

  • Cookies
  • Persistent identifiers
  • IP addresses (hashed for daily unique counting, hash rotated daily)
  • Cross-session tracking
  • Personal data

Comparison Matrix

CapabilityThird-Party CookiesTopics APIAttribution ReportingProtected AudiencesServer-Side Analytics
Interest-based targetingFull granularity~470 topicsNoRetargeting onlyNo
Conversion measurementDeterministicNoYes (with noise/delay)LimitedServer-side only
Cross-site trackingYesNoNoNoNo
Works in SafariNo (blocked)NoNoNoYes
Works in FirefoxNo (blocked)NoNoNoYes
Consent requiredYesEvolvingEvolvingEvolvingDepends on config
Production-readyLegacyYes (Chrome)Yes (Chrome)Yes (Chrome)Yes

Key Legal and Technical References

  • Google Privacy Sandbox Documentation — Topics API, Attribution Reporting, Protected Audiences specifications
  • W3C Private Advertising Technology Community Group — Standards development for privacy-preserving advertising
  • ePrivacy Directive 2002/58/EC, Article 5(3) — Legal basis for consent requirements; exemptions may apply to some alternatives
  • GDPR Recital 47 — Legitimate interest considerations for analytics
  • UK ICO Guidance on Analytics Cookies (2019, updated 2023) — Analytics cookies require consent under PECR
  • CNIL Topics API Analysis (2023) — French DPA assessment of Privacy Sandbox proposals
  • CMA (UK Competition and Markets Authority) Privacy Sandbox Commitments — Google's commitments regarding Privacy Sandbox development
  • IAB Tech Lab Privacy Sandbox Task Force — Industry evaluation of Privacy Sandbox APIs

Related by task

from this repository

More skills

All skills
mukul975
Community

applying-privacy-design-patterns

- Systematic application of the eight privacy design patterns per Hoepman: minimize, hide, separate, abstract, inform, control, enforce, and demonstrate. Covers pattern selection methodology per processing activity, mapping to GDPR principles, and practical implementation guidance for privacy-by-design system architecture.

installs
1
GitHub stars
315
Updated
Mar 16
mukul975
Community

brazil-lgpd

- Guides compliance with Brazil's Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018). Covers the 10 lawful bases under Art. 7, DPO appointment, ANPD enforcement, data subject rights under Arts. 17-22, and international transfer mechanisms. Keywords: LGPD, Brazil data protection, ANPD, lawful bases, data subject rights, international transfers.

installs
1
GitHub stars
315
Updated
Mar 16
mukul975
Community

adequacy-assessment

- Guides assessment of third-country adequacy decisions under GDPR Article 45 for international data transfers. Covers the current EC adequacy decisions list, adequacy assessment criteria, partial adequacy handling, and monitoring of adequacy decision reviews. Keywords: adequacy decision, Article 45, third country, adequate protection, EC adequacy list.

installs
1
GitHub stars
295
Updated
Mar 16
mukul975
Community

age-gating-services

- Implements age-gating mechanisms for online services to restrict access based on user age. Covers hard gates versus soft gates, neutral age prompts, re-verification triggers, circumvention prevention, and regulatory requirements under GDPR, COPPA, UK Online Safety Act, and DSA. Keywords: age gate, age restriction, neutral prompt, children, online services, access control.

installs
1
GitHub stars
295
Updated
Mar 16