Last updated: April 7, 2026 · Adworth℠ LLC · Charleston, SC
adworth-ads Cloudflare Worker (v5.3.0, powered by DataForSEO), which includes a PII Advertiser Name Classifier that anonymizes person names before any response leaves the worker — only a non-reversible SHA-256 audit hash is retained. The public /analyze endpoint is rate-limited to 10 requests per IP per hour to prevent abuse. Our Ingestion API (adworth-ingestion-api v1.3.0) and Privacy Cockpit Chrome extension allow secure submission of cryptographically signed marketing data — your private Ed25519 key is generated on your device and never transmitted to Adworth. As of v1.3.0, upon successful signature verification the Ingestion API also writes a CONSENT_ISSUED event to the ADWORTH_LEDGER KV namespace, enabling the Privacy Governance Engine to evaluate your issued token in real time during advertiser access requests. No PII is written to the ledger — only opaque identifiers, timestamps, and cryptographic references. Our consent token API (adworth-consent-widget, v3.4.0) uses opaque identifiers only — no PII in tokens or ledger entries. Our Privacy Governance Engine (v2.3.0) enforces consent in real time. Our State-Persistence Monitor scans for unauthorized data retention after revocation. As of March 11, 2026, our Removal Payload Engine (adworth-rpe v2.3.0) fetches legal citations, deadlines, and obligations at runtime from a versioned, machine-readable regulation rules table served by the adworth-rules Worker via a Cloudflare Service Binding (rules v1.0.0, effective March 5, 2026). Our Advanced Privacy Protocols (described in Section 8) add Ledger Chaff noise injection, Local Differential Privacy (2% fuzz), Location Grid Quantization (1 km² precision), and a Minor Shield protocol — all of which are built to protect you from external surveillance, not to obscure your own rights. No hardcoded legal strings, every notice carries a rules_version for permanent audit linkage. Both the monitor and RPE currently operate in simulated mode. As of the March 14, 2026 security audit, all Workers use constant-time HMAC-SHA256 API key comparison via crypto.subtle, strict CORS origin allowlists (no wildcards), and self-hosted fonts via adworth-fonts Worker. All API access is authenticated. API keys entered in dashboards are held in memory for the session only and never written to persistent browser storage, cookies, or server-side logs. Vercel Analytics is disabled. No third-party trackers, advertising pixels, or analytics services. That’s kind of the whole point.
When you join our waitlist (via the homepage form or dashboard inline form), we collect:
dashboard-consent-moment or dashboard-explainer-panel)When you visit adworth.app, our infrastructure (Cloudflare and Vercel) may automatically log standard request metadata including:
We do not use any third-party analytics scripts, tracking pixels, or behavioral analytics tools on adworth.app. Vercel Analytics is explicitly disabled on our deployment. No external analytics code runs on our pages.
The Privacy Cockpit Chrome extension (Manifest V3) and Ingestion API (adworth-ingestion-api Cloudflare Worker) allow you to submit cryptographically signed campaign-level marketing data from advertising platform dashboards. The following data is collected and processed:
chrome.storage.local on your device. Only your public key is uploaded to and stored by Adworth in Cloudflare Workers KV under the key pattern user:{user_id}:pubkey:{device}.signature_verified: true flag are stored with each ingestion record in Cloudflare Workers KV under the key pattern ingestion:{user_id}:{ingestion_id}.CONSENT_ISSUED event to the ADWORTH_LEDGER KV namespace. This event contains: a unique token ID (matching the ingestion ID), opaque user ID, advertiser ID, data scope, expiry timestamp (one year from issuance), issuance method (privacy_cockpit_extension), and a signatureVerified: true flag. No PII is written. This event enables the Privacy Governance Engine to evaluate the token in real time during subsequent advertiser access requests. The ledger write is subject to the same immutability and append-only rules as all ledger entries.Multi-device support is provided by design — each device generates its own keypair. If a device is lost or compromised, you may request key revocation by contacting .
CONSENT_ISSUED ledger write to ADWORTH_LEDGER are all live on Cloudflare. The extension is currently distributed as a developer build and has not been published to the Chrome Web Store.
When you use our Ad Intelligence Dashboard (adworth.app/demo), all processing runs through our own adworth-ads Cloudflare Worker. The following data is processed:
apple.com)No personal user data is transmitted to DataForSEO or Anthropic as part of dashboard analysis. The pipeline processes publicly available advertiser data only. Results are cached in Cloudflare Workers KV (AD_CACHE namespace) for six hours.
Our CCPA Enforcement Gap page (adworth.app/ccpa-gap) displays aggregated data from publicly available CCPA transparency reports published by other companies. This data is:
CCPA_DATA namespace) and served via the adworth-ccpa-gap Cloudflare WorkerAdworth is not affiliated with any company listed on the CCPA Enforcement Gap page. No data on this page is obtained through scraping protected content, accessing private systems, or any non-public source.
The adworth-ads worker includes a PII Advertiser Name Classifier. This component:
The classifier ensures that individual person names in public ad data are never surfaced to end users or stored in recoverable form anywhere in the Adworth pipeline.
When you interact with our Consent Token API (adworth-consent-widget.adworthllc.workers.dev, the current active consent infrastructure worker), we collect and process:
Consent tokens contain no personally identifiable information. Token identifiers are 128-bit cryptographic random values only.
The adworth-rules Cloudflare Worker serves a versioned, machine-readable regulation rules table to the RPE at runtime. No personal data is processed by or transmitted to this Worker. The data it serves consists exclusively of publicly available regulatory text (GDPR, CCPA/CPRA, DSA articles), structured as a version-controlled JSON schema. The rules table is stored in the isolated ADWORTH_RULES Cloudflare KV namespace and is publicly readable at GET /rules and sub-paths. Write access (POST /admin/sync) requires API key authentication.
The standalone RPE worker (adworth-rpe.adworthllc.workers.dev v2.3.0) generates legally-cited deletion notices. As of March 11, 2026, all legal citations, deadlines, and obligations are fetched at runtime from the adworth-rules Worker via a Cloudflare Service Binding (direct worker-to-worker communication, no public network hop) rather than hardcoded strings. When a notice is generated, the following data is created and stored:
RPE-YYYY-XXXXXX (unique, non-sequential)GDPR-ART17, DSA-ART25) evaluated from the rules tablerules_version and rules_effective_date — the exact version of the regulation rules table used to generate this notice, creating a permanent audit linkactive, demo, or voided)No personally identifiable information is included in any RPE notice. Demo-mode notices generated via the enterprise page are clearly prefixed with “DEMO — THIS NOTICE CARRIES NO LEGAL EFFECT” and stored with a demo status flag.
The adworth-rpe worker provides public verification endpoints accessible without authentication. Verification responses include notice status, target domain, regulation, right ID, rules_version, jurisdiction, compliance deadline, generation timestamp, content hash, HMAC signature, and integrity verification result. No PII is disclosed. Demo-mode notices are clearly identified in verification responses.
The Consent API dashboard requires API key authentication via constant-time HMAC-SHA256 verification. API keys are held in JavaScript memory for the active session only, never written to localStorage, sessionStorage, cookies, or any server-side log. The dashboard loads no third-party scripts, uses self-hosted fonts, and sets no cookies.
The Invisibility Ledger dashboard is a read-only viewer of the unified tamper-evident audit trail. It reads from ADWORTH_LEDGER KV and never writes to it. It displays the complete event timeline across all five patent components with filtering by event type and user. The same in-memory-only API key handling applies as all other Adworth dashboards.
When the State-Persistence Monitor runs a scan, it processes revoked and expired consent token identifiers from the Invisibility Ledger, associated opaque user IDs, advertiser IDs, consent scope data, and scan metadata including violation detection results and removal payload records.
adworth-rules Worker) but are not yet transmitted to actual data brokers.
When the Privacy Governance Engine evaluates a data access request, it processes the requesting advertiser’s identifier, the opaque user identifier, the data scope being requested, and the active consent tokens for that user-advertiser pair. Every decision — granted or blocked — is recorded in both GOVERNANCE_LOG and ADWORTH_LEDGER. No PII is processed or stored by the Governance Engine.
Adworth provides demonstration and testing interfaces for investor review and system validation:
adworth.app/advertiser-sandbox.html): Developer-facing interface for testing access requests against the live Privacy Governance Engine (adworth-bouncer v2.3.0). As of April 7, 2026, the sandbox is fully wired end-to-end — a userId from a real Privacy Cockpit sync can be pasted into the Wire to Live Sync field and the Bouncer evaluates the exact CONSENT_ISSUED token written to the ledger during that sync. All evaluations are logged to GOVERNANCE_LOG and ADWORTH_LEDGER. No PII is processed. API keys are held in JavaScript memory only and never persisted.We do not collect government IDs, financial account numbers, or health data. We do not use Formspree or any third-party form processing service — all form submissions are handled exclusively by our own adworth-waitlist Cloudflare Worker (v2.3.0). Private Ed25519 keys generated by the Privacy Cockpit extension are never transmitted to or stored by Adworth. API keys used to access Adworth dashboards are held in memory for the session only and are never written to persistent browser storage, cookies, or server-side logs. No personal data flows through or is stored by the adworth-rules Regulation Rules Worker.
We use the information we collect to:
CONSENT_ISSUED event to the ADWORTH_LEDGER KV namespace upon successful signature verification (Ingestion API v1.3.0), enabling the Privacy Governance Engine to evaluate your issued token during advertiser access requests — no PII is writtenadworth-rules rules table to determine the correct legal citations, deadlines, and obligations for each enforcement actionrules_version reference in each RPE notice to create a permanent, auditable link between the notice and the exact regulatory ruleset appliedWe do not use your information for behavioral advertising. We do not build advertising profiles from your activity on our platform.
Our Ad Intelligence pipeline uses two third-party APIs. All calls to these services are made exclusively from our adworth-ads Cloudflare Worker — no third-party API calls originate from the user’s browser.
Ad data is retrieved from Google’s Ads Transparency Center via DataForSEO (dataforseo.com) using the POST /v3/serp/google/organic/live/advanced endpoint. All DataForSEO calls are made exclusively from our adworth-ads Cloudflare Worker — the domain name you entered is transmitted using Basic Auth credentials stored as encrypted Cloudflare Worker secrets. No personal user data is transmitted to DataForSEO. Before any DataForSEO response is returned to the dashboard, the PII Advertiser Name Classifier runs to detect and anonymize individual person names. Results are cached in AD_CACHE KV for six hours. DataForSEO’s privacy policy: dataforseo.com/privacy-policy.
Privacy risk scores, transparency scores, regulatory flags, and AI findings are generated by Anthropic’s Claude AI via the Anthropic API. Data transmitted to Anthropic is the already-anonymized ad metadata from DataForSEO — any person names have been replaced by the PII classifier before this call is made. No personal user data, waitlist emails, consent token data, or ingestion records are transmitted to Anthropic. Anthropic’s privacy policy: anthropic.com/legal/privacy.
All server-side logic runs on Cloudflare Workers edge infrastructure. Our complete active worker fleet:
adworth-ads.adworthllc.workers.dev — Ad Intelligence Worker v5.3.0: DataForSEO integration (POST /v3/serp/google/organic/live/advanced), Anthropic AI analysis, PII Advertiser Name Classifier, AD_CACHE KV storage (6-hour TTL). Public /analyze endpoint rate-limited to 10 requests per IP per hour. Strict CORS origin allowlist. Constant-time HMAC API key authentication. /debug endpoint removed.adworth-consent-widget.adworthllc.workers.dev — Consent Token API v3.4.0 and management dashboard with CPRA opt-out page (Patent Components #1, #3). This is the active consent infrastructure worker. The legacy worker name adworth-consent-api refers to an earlier deployment of this same codebase; adworth-consent-widget is the current active version. Strict CORS origin allowlist (12 origins). Constant-time HMAC-SHA256 API key authentication. IP-based rate limiting via KV (opt-out: 5/hr, admin: 10/hr). User IDs SHA-256 hashed before KV storage. Location coordinates quantized and fuzzed for privacy. XSS protection via esc() (createElement/createTextNode). Event delegation replaces inline onclick handlers. API key stored in JS memory only (no sessionStorage). Self-hosted fonts via adworth-fonts Worker. KV binding: ADWORTH_TOKENS.adworth-bouncer.adworthllc.workers.dev — Privacy Governance Engine v2.3.0 and dashboard (Patent Component #2); applies Minor Shield blocking when user_type: minor is detected in token metadata. Strict CORS origin allowlist. Constant-time HMAC API key authentication. Self-hosted fonts via adworth-fonts Worker. Inline error banners replace alert() dialogs.adworth-ledger.adworthllc.workers.dev — Invisibility Ledger read-only viewer and dashboard (Patent Component #3) — reads ADWORTH_LEDGER, never writes; ledger entries include synthetic chaff events (see Section 8)adworth-state-monitor.adworthllc.workers.dev — State-Persistence Monitor and dashboard (Patent Component #4)adworth-rpe.adworthllc.workers.dev — Standalone Removal Payload Engine v2.3.0 (Patent Component #5): fetches regulation rules at runtime from adworth-rules via Cloudflare Service Binding (RULES_WORKER), generates HMAC-SHA256-signed deletion notices with embedded rules_version, provides public verification endpoints, demo mode requires authentication (no hardcoded demo key), stores notices in RPE_DATA KV. Strict CORS origin allowlist. Constant-time HMAC API key authentication. Self-hosted fonts via adworth-fonts Worker.adworth-rules.adworthllc.workers.dev — Regulation Rules Worker: serves versioned machine-readable regulation rules table (v1.0.0, effective March 5, 2026) from isolated ADWORTH_RULES KV namespace. Public read endpoints at /rules and sub-paths. No personal data processed or stored.adworth-ingestion-api.adworthllc.workers.dev — Ingestion API v1.3.0: receives Ed25519-signed marketing data from the Privacy Cockpit Chrome extension, verifies signatures using stored public keys, stores verified ingestion records. As of v1.3.0, upon successful signature verification also writes a CONSENT_ISSUED event to ADWORTH_LEDGER KV. Manages device keypair registration via single-use setup tokens. Three KV bindings: USER_KEYS (public keys by device), INGESTION_DATA (verified ingestion records), ADWORTH_LEDGER (consent event ledger write). No PII in any stored record.adworth-waitlist — Waitlist Worker v2.3.0: form processing via redirect at adworth.app/waitlist-submit (homepage) and JSON response at /submit endpoint (dashboard inline forms), admin dashboard, and CSV export (authenticated). All waitlist submissions are handled exclusively by this worker; no third-party form processors are used. Strict CORS origin allowlist (localhost and file:// origins removed). Constant-time HMAC API key authentication. Self-hosted fonts via adworth-fonts Worker. Internal UUIDs are no longer returned to public callers.adworth-ccpa-gap — CCPA Enforcement Gap public API and admin dashboard, CCPA_DATA KV storageadworth-fonts.adworthllc.workers.dev — Self-hosted font delivery v1.2.0 with origin-aware CORS and edge caching. No requests are made to Google Fonts or any third-party font service from user browsers.adworth-consent-widget.adworthllc.workers.dev — Active consent infrastructure worker (v3.4.0). The legacy Cloudflare Worker deployment named adworth-consent-api shares the same codebase and was the original deployment name. adworth-consent-widget is the current active deployment and supersedes it. Both reference the same ADWORTH_TOKENS KV namespace.adworth-auth-guard.adworthllc.workers.dev — Auth Guard v1.2.0: Sovereign key protection: rate limiting, brute force blocking, and authentication audit log for the Worker fleet. Stores IP addresses temporarily in the ADWORTH_AUTH_GUARD KV namespace for rate limit enforcement only. Rolling window: 300 seconds. Block duration: 900 seconds. IP data is used solely for security purposes and is not shared with third parties. Audit log retains the last 500 entries. Strict CORS origin allowlist. Constant-time HMAC API key authentication.adworth-social — Social content draft queue and content library v1.1.0. Stores drafts in ADWORTH_SOCIAL KV. No user PII stored. Strict CORS origin allowlist (7 origins). Constant-time HMAC-SHA256 API key authentication. IP-based rate limiting via KV (read: 60/hr, write: 20/hr). XSS protection via esc() (createElement/createTextNode). Event delegation replaces inline onclick handlers. API key stored in JS memory only. Self-hosted fonts via adworth-fonts Worker.adworth-comms — Internal communications metadata log. Metadata-only logging; no message body storage. Stores metadata in ADWORTH_COMMS KV. All email delivery is handled directly through Proton Mail. No user personal data stored.adworth-changelog — Infrastructure change log. Append-only record of all Worker deployments and configuration changes stored in ADWORTH_CHANGELOG KV. No user data.adworth-expenses — Internal operational expense tracker v1.1.0. No user data. Stores cost records in ADWORTH_EXPENSES KV. Strict CORS origin allowlist (7 origins). Constant-time HMAC-SHA256 API key authentication. IP-based rate limiting via KV (read: 60/hr, write: 20/hr). CSV export uses header-based auth (API key never passed in URL query parameters). XSS protection via esc() (createElement/createTextNode). Event delegation replaces inline onclick handlers. API key stored in JS memory only. Self-hosted fonts via adworth-fonts Worker.adworth-dsr — Data Subject Request processor. Handles GDPR/CCPA deletion and access requests. Stores DSR records in ADWORTH_DSR_LOG KV with verification token TTL of 3600 seconds. Confirmation sent to requester via adworth-comms.adworth-headers — Security header enforcement. Injects Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy headers on all adworth.app responses. No data stored.adworth-retention — Automated data retention enforcement. Runs on a daily cron trigger at 03:00 UTC. Purges expired consent tokens, stale KV entries beyond retention window, and stale monitor state. No user data retained beyond policy windows.adworth-breach — Breach detection and notification. Logs security events in ADWORTH_BREACH_LOG KV. Sends email alert to on new breach events. Triggers SC § 39-1-90 notification workflow when threshold conditions are met.adworth-age-gate — Age certification enforcement. Stores age certifications in ADWORTH_AGE_GATE KV. Enforces Minor Shield eligibility at the platform front door before any advertising data access is permitted.adworth-healthcheck — Fleet health monitoring. Runs on a daily cron trigger at 06:00 UTC. Pings all 29 Worker /health endpoints and logs availability. No user data.adworth-audit-export — Audit trail export. Generates user-facing exports of real ledger entries, excluding synthetic chaff. Exports contain no PII. Used to fulfill GDPR Art. 15 access requests.adworth-consent-receipt — Consent receipt delivery. Generates and delivers cryptographically signed consent receipts to users upon token issuance. No PII stored server-side.adworth-key-rotation — API key rotation log. Stores rotation events and key fingerprints in ADWORTH_KEY_ROTATION_LOG KV. Key values are never stored — fingerprints only.adworth-deploy-integrity — Deployment integrity verification. Records Worker deployment hashes in ADWORTH_DEPLOY_LOG KV for tamper detection. No user data.adworth-abuse — Abuse detection and rate limiting. Logs abuse events in ADWORTH_ABUSE_LOG KV. Provides coordinated blocking signals across the fleet. IP addresses stored temporarily for security purposes only.adworth-well-known.adworthllc.workers.dev — Well-Known Worker: serves RFC 9116 security.txt at adworth.app/.well-known/security.txt and reserves the /.well-known/* route for future use (e.g. DID, OpenID Connect discovery). No personal data processed or stored. Static text response only. Deployed March 18, 2026.Cloudflare Workers KV namespaces in use:
WAITLIST — Waitlist email addresses and signup source metadataAD_CACHE — Ad intelligence results cache (TTL 1–2 hours, auto-purged) and PII classifier SHA-256 audit hashes (90-day retention)ADWORTH_TOKENS — Active consent tokens (TTL = consent duration + 24-hour audit buffer)ADWORTH_LEDGER — Append-only tamper-evident audit trail across all five patent components; includes synthetic chaff entries generated by the Ledger Chaff protocol (Section 8). Written to by: adworth-consent-widget (consent lifecycle events), adworth-bouncer (access decisions), adworth-state-monitor (violation events), adworth-rpe (removal payload events), and as of Ingestion API v1.3.0, adworth-ingestion-api (CONSENT_ISSUED events upon successful Ed25519 signature verification). No PII in any ledger entry.MONITOR_STATE — State-Persistence Monitor scan results, violation recordsGOVERNANCE_LOG — Privacy Governance Engine access decisions; includes MINOR_SHIELD_ACTIVE eventsRPE_DATA — Removal Payload Engine notices with HMAC signatures, content hashes, and rules_version referencesADWORTH_RULES — Versioned regulation rules table served by the adworth-rules Worker. Isolated namespace; no personal data. Source of truth for all legal citations evaluated by the RPE at runtime.USER_KEYS — Ed25519 public keys registered by Privacy Cockpit extension users, keyed by device identifierINGESTION_DATA — Verified ingestion records from Privacy Cockpit extension submissions, containing sanitized campaign metrics and signature verification statusCCPA_DATA — CCPA Enforcement Gap company dataADWORTH_AUTH_GUARD — Auth Guard rate limit counters and authentication audit log. Stores temporary IP-based failure counters (TTL = 300 seconds) and block records (TTL = 900 seconds). Audit log capped at 500 entries. No personal data beyond IP addresses. Security purpose only.ADWORTH_SOCIAL — LinkedIn content draft queue. No user PII.ADWORTH_COMMS — Internal communications metadata log. No message body content. No user personal data.ADWORTH_CHANGELOG — Infrastructure change log entries. No user data.ADWORTH_EXPENSES — Internal expense records. No user data.ADWORTH_DSR_LOG — Data Subject Request records including request type, timestamp, and verification token (TTL 3600 seconds). Deleted after request is fulfilled.ADWORTH_BREACH_LOG — Breach event log entries. Contains event type, timestamp, and severity. No PII beyond IP address where relevant to the security event.ADWORTH_AGE_GATE — Age certifications. Records certification timestamp and session token. No biometric data.ADWORTH_KEY_ROTATION_LOG — Key rotation event log. Stores fingerprints only; never stores key values.ADWORTH_DEPLOY_LOG — Deployment integrity hashes. No user data.ADWORTH_ABUSE_LOG — Abuse event records. Contains event type, timestamp, and temporary IP data for security purposes only.Cloudflare’s privacy policy: cloudflare.com/privacypolicy.
Waitlist submissions are processed entirely through our own adworth-waitlist Cloudflare Worker. No third-party form processors, mailing list providers, or email delivery services are used. Email addresses are never transmitted to external services. Waitlist communications are sent directly via Proton Mail using BCC to protect subscriber privacy. No message body content is stored by any Adworth system.
We do not sell, rent, or trade your personal information. We may share it only in the following limited circumstances:
adworth-rules.json regulation rules table is version-controlled in GitHub as the source of truth. No user personal data of any kind is stored in or transmitted through GitHub. API secrets are never committed to version control. docs.github.com/privacyadworth-ads Cloudflare Worker using the POST /v3/serp/google/organic/live/advanced endpoint. Credentials stored as encrypted Cloudflare Worker secrets. No personal user data is transmitted to DataForSEO — only the domain name entered for analysis. Results are cached in AD_CACHE KV for six hours. dataforseo.com/privacy-policyapp.adworth.app subdomain and handles system email routing for . Standard server access logs may be retained. ionos.com/terms-gtc/privacy-policyWhen the Removal Payload Engine transitions to live operation, legally-cited deletion requests will be transmitted to data brokers on your behalf. These will contain only opaque token identifiers, revocation timestamps, legal citations (derived from the versioned rules table), and the rules_version reference — no PII. This policy will be updated before any live broker communications begin.
We may disclose your information if required by law, court order, or government authority.
In the event of a merger, acquisition, or sale of assets, we will notify you before your information becomes subject to a different privacy policy.
The Consent Token API (adworth-consent-widget.adworthllc.workers.dev, v3.4.0) manages the complete lifecycle of cryptographic consent tokens. On issuance, a 128-bit cryptographically random token is generated via the Web Crypto API and bound to a specific advertiser, data scope, and time window via HMAC-SHA256 signature. Validation performs six sequential checks: token existence, revocation status, expiration, advertiser match, scope match, and cryptographic signature verification. Revocation is immediate and irreversible. Expired tokens are auto-purged by Cloudflare KV TTL with a 24-hour audit buffer.
All protected endpoints require an X-API-Key header or Bearer token. As of the March 14, 2026 security audit, all Workers use constant-time HMAC-SHA256 comparison via crypto.subtle to verify API keys, preventing timing-based side-channel attacks. Keys are stored as encrypted Cloudflare environment secrets, never in source code or version control. When entered in dashboards, keys are held in memory for the session only — never written to localStorage, sessionStorage, cookies, or any server-side log. Unauthenticated requests receive 401 Unauthorized with no data disclosure.
The Invisibility Ledger (ADWORTH_LEDGER KV namespace) is an append-only, tamper-evident log of all consent lifecycle events across all five patent components. Each entry records: entry ID, event type, token ID, advertiser ID, consent scope, decision result and reason code where applicable, and UTC timestamp. No email addresses, names, IP addresses, or PII of any kind is stored. Entries are written once and never overwritten. The ledger retains the most recent 500 events in rolling storage; indefinite retention is configurable for compliance deployments.
The Invisibility Ledger intentionally contains synthetic “chaff” entries alongside real consent events. These are decoy records injected to prevent external parties from performing pattern-of-life analysis against your consent history. Only your Sovereign Key can distinguish real entries from chaff. Chaff entries are mathematically indistinguishable to any observer who does not hold your key. This is a privacy protection, not an inaccuracy. The presence of chaff entries does not affect the accuracy or enforceability of your real consent records, and does not affect any payout calculations in the consent marketplace.
All KV namespaces (ADWORTH_TOKENS, ADWORTH_LEDGER, MONITOR_STATE, GOVERNANCE_LOG, RPE_DATA, WAITLIST, AD_CACHE, CCPA_DATA, USER_KEYS, INGESTION_DATA, ADWORTH_RULES, ADWORTH_AUTH_GUARD) are fully isolated. There is no cross-namespace access between systems. The ADWORTH_RULES namespace is read-only to all Workers except the authenticated sync operation on adworth-rules. The RPE accesses adworth-rules via a Cloudflare Service Binding (RULES_WORKER) for direct worker-to-worker communication without traversing the public network.
The Privacy Governance Engine (adworth-bouncer.adworthllc.workers.dev, v2.3.0) is a real-time consent enforcement system. Every data access request is evaluated against active consent tokens before any data can be reached.
Any failed check triggers an immediate block. The decision is final and cannot be overridden. Every decision is recorded in both GOVERNANCE_LOG and ADWORTH_LEDGER. No PII is stored in any decision record.
Blocked responses include one of: TOKEN_NOT_FOUND, TOKEN_REVOKED, TOKEN_EXPIRED, ADVERTISER_MISMATCH, SCOPE_MISMATCH, SIGNATURE_INVALID, MINOR_SHIELD_ACTIVE, GPC_OPT_OUT, or INVALID_REQUEST.
When a consent token carries user_type: minor metadata, the Governance Engine enters a High-Shield state and blocks all advertising-related data access requests regardless of scope, advertiser, or token validity. A MINOR_SHIELD_ACTIVE event is recorded in the Invisibility Ledger. No long-term profile is built for minor users. See Section 8 for the complete Minor Shield protocol.
Adworth honors Sec-GPC: 1 browser signals as valid opt-outs of data sale and sharing under CPRA § 1798.135(d). When a user’s browser sends this header, the Governance Engine immediately blocks the access request and returns a GPC_OPT_OUT block reason. This check runs after Minor Shield but before any token lookup — no consent token can override a GPC opt-out signal. The block is recorded in both GOVERNANCE_LOG and ADWORTH_LEDGER.
The Governance Engine dashboard displays the real-time decision log, block reason breakdown, and validation stats. API key held in JavaScript memory for the session only. No third-party scripts. Self-hosted fonts. No cookies.
The State-Persistence Monitor (adworth-state-monitor.adworthllc.workers.dev) detects unauthorized data retention after a user revokes or expires consent. On scan, it reads the Invisibility Ledger to identify all revoked/expired tokens, checks a registry of data brokers for unauthorized retention, and records any VIOLATION_DETECTED events in the Invisibility Ledger. Only opaque identifiers, scopes, and timestamps are processed — no PII.
As of March 11, 2026, the RPE (adworth-rpe v2.3.0) fetches all regulation rules at runtime from the adworth-rules Worker via a Cloudflare Service Binding rather than using hardcoded legal citations. This means legal citations, deadlines, controller obligations, penalty tiers, and third-party notification requirements are evaluated deterministically from versioned JSON — no fuzzy interpretation. The RPE operates in two modes:
Each removal payload contains a Notice ID, target domain, right ID and regulation evaluated from the rules table, rules_version and rules_effective_date, opaque data subject reference, data categories, legal citations, compliance deadline, HMAC-SHA256 cryptographic signature, SHA-256 content hash, and full legal notice text. Notices generated by the standalone RPE worker are stored in the dedicated RPE_DATA Cloudflare Workers KV namespace with the rules_version under which they were generated. Demo-mode notices are stored with a demo status flag and clearly identified in all verification responses.
The standalone adworth-rpe worker provides public endpoints accessible without authentication. Verification checks the stored HMAC signature and content hash against the original notice data, and returns the rules_version embedded in the notice. No PII is disclosed through verification endpoints.
Demo-mode notices require full API key authentication (no public demo key exists) and are generated with a demo: true flag in the request body, stored with status demo, prefixed with “DEMO — THIS NOTICE CARRIES NO LEGAL EFFECT / NO COMPANY WILL RECEIVE THIS NOTICE”, and carry no legal effect. No company named in a demo notice will receive any communication from Adworth.
adworth-rules) and HMAC-SHA256 signatures but are not transmitted to actual data brokers. No deletion requests have been sent to any third party. This policy will be updated before live delivery begins.
Adworth implements a set of advanced, systemic privacy protections designed to prevent external surveillance of your consent activity — beyond what individual data-handling rules can achieve. These protections operate at the infrastructure level and are active by default. None of these mechanisms are used to obscure your own rights, limit your access to your data, or affect payout accuracy.
To prevent “pattern-of-life” analysis — where an external party identifies you by correlating when and how you grant or revoke consent — the adworth-ledger Worker injects synthetic “chaff” (decoy) entries alongside real consent events. To an outside observer, real and synthetic events are mathematically indistinguishable. Only your Sovereign Key can distinguish your authentic consent records from noise. This technique is consistent with established differential privacy practices for audit log protection.
Chaff entries:
A 2% randomized “fuzz” coefficient is applied to numeric metadata fields in consent scope records (e.g. time window durations, frequency parameters) where mathematically applicable. This makes the ledger statistically less useful for inferring your habits from aggregate data while preserving complete accuracy for individual consent enforcement and payout calculations. The fuzz is applied locally within the Worker before any data is written — it is never applied to payment amounts, token signatures, or legal notice content.
This technique is a standard implementation of local differential privacy and is not a data inaccuracy. The underlying consent grant remains fully enforceable and auditable.
When consent token scope metadata includes a location parameter, Adworth applies Grid Quantization: GPS coordinates are snapped to a 1 km² grid square before being written to any ledger entry or token record. Raw GPS coordinates are never stored or transmitted by Adworth systems. This prevents geospatial fingerprinting — the practice of identifying individuals based on precise location patterns over time.
Grid-quantized coordinates are sufficient for geographic consent scoping (e.g. a user consenting to location-based advertising in a city area) but insufficient to identify a specific address or home location.
When a consent token carries user_type: minor metadata — either set explicitly or triggered by device-level signals — the system enters a High-Shield state:
MINOR_SHIELD_ACTIVE to the ledgerAdworth does not knowingly collect personal data from minors under 13 in any form (see Section 13). The Minor Shield protocol applies as an additional protection layer for users aged 13–17 where parental or guardian consent exists, and for any session where minor status cannot be definitively excluded.
MINOR_SHIELD_ACTIVE blocking) is implemented in the adworth-bouncer Worker. All four protocols are active in the current deployment. The Nashville Offline Protocol and Biometric Gating described below are on the product roadmap and are not yet deployed.
A future capability planned for the consent marketplace: device-bound authorization that functions without an internet connection. When deployed, consent authorization will be stored in the device’s Secure Enclave (not in the cloud) and will support cryptographically-signed Promissory Tokens exchangeable via NFC or Bluetooth Mesh. Promissory transactions will settle on the Adworth ledger when connectivity is restored. This feature requires a mobile application and is contingent on post-funding development. This policy will be updated when the feature enters development.
A future capability planned for the consent marketplace: local biometric verification (FaceID / TouchID) as a gate before consent tokens can be activated or payment authorized. When deployed, biometric data will remain entirely on the user’s device and will never be transmitted to or stored by Adworth. The result of a biometric check will be a signed pass/fail signal only — no biometric template, hash, or identifier will leave the device. This feature requires a mobile application and is contingent on post-funding development.
WAITLIST KV until you unsubscribe or request deletionAD_CACHE KV with a 1–2 hour TTL, then automatically purgedAD_CACHE KV with a 90-day retention period, then automatically purged. Cannot be used to reconstruct the original name.USER_KEYS KV for the duration of device registration. Revoked on request; revocation prevents further submissions from that device but does not delete previously verified ingestion records.INGESTION_DATA KV for the duration of your account. Contain only sanitized campaign metrics, timestamps, device identifiers, and signature verification status — no PII. Deletable on request by contacting .ADWORTH_TOKENS KV with a TTL matching the consent duration plus a 24-hour audit buffer, then automatically purged.ADWORTH_LEDGER KV. Entries contain only cryptographic identifiers and timestamps — no PII. Ledger entries include both real consent events and synthetic chaff entries (see Section 8); both are retained equally.MONITOR_STATE KV for audit and compliance purposes. No PII.GOVERNANCE_LOG KV for audit and compliance purposes. Includes MINOR_SHIELD_ACTIVE events. No PII.RPE_DATA KV for audit, compliance, and public verification purposes. Each notice includes the rules_version under which it was generated. No PII. Active and voided notices are retained indefinitely for verification integrity.ADWORTH_RULES KV. Contains only publicly available regulatory text structured as versioned JSON. No personal data. Updated via authenticated admin sync from GitHub source of truth; previous versions accessible via GitHub commit history for audit purposes.CCPA_DATA KV. Updated annually. No individual consumer data.When you request deletion of your personal data, we will remove it from active systems within 30 days and from backups within 90 days. Ledger entries, violation records, RPE records, and standalone RPE notices (which contain no PII) may be retained as part of the immutable audit trail even after personal data deletion.
Depending on your location, you may have the following rights regarding your personal information:
Sec-GPC: 1 signal, Adworth automatically honors it as a valid opt-out of data sale and sharing under CPRA § 1798.135(d) — no additional action required on your partTo exercise any of these rights, contact us at . We will respond within 30 days.
We implement industry-standard security measures including:
adworth-rules v1.0.0) evaluated at runtime by the RPE — every notice embeds a rules_version creating a permanent, auditable link between legal citations and the specific ruleset version applied; rules changes require a GitHub commit and authenticated KV sync before taking effectcrypto.subtle on all protected endpoints across the entire worker fleet (29 Workers), preventing timing-based side-channel attacks*) origins, no localhost or 127.0.0.1 origins in productionadworth-ads /analyze: 10 requests per IP per hour via KV) to prevent credential-free abuseRULES_WORKER) for RPE-to-rules worker communication — direct worker-to-worker calls without traversing the public networkX-API-Key authentication on all protected API endpoints across the entire worker fleet (29 Workers)localStorage, sessionStorage, cookies, or any server-side logadworth-ads worker; only a non-reversible SHA-256 audit hash is retainedADWORTH_RULES namespaceadworth-fonts.adworthllc.workers.dev — no requests to Google Fonts or any third-party font service from any Worker dashboardrobots.txt includes explicit Disallow: / directives for 13 known AI training crawlers (GPTBot, ChatGPT-User, Google-Extended, CCBot, anthropic-ai, Claude-Web, Bytespider, cohere-ai, PerplexityBot, Amazonbot, FacebookBot, meta-externalagent, Applebot-Extended) — standards-compliant signal that site content must not be used for AI model trainingsecurity.txt published at adworth.app/.well-known/security.txt — provides a verified, machine-readable responsible disclosure contact for security researchers and enterprise due diligence. Served by the adworth-well-known Worker. Expires annually.If you discover a potential security vulnerability in any Adworth system, please report it to with the subject line “Security Disclosure.” We will acknowledge reports within 72 hours and keep you informed as we investigate. We ask that you do not publicly disclose the issue until we have had reasonable time to address it. Full disclosure policy: adworth.app/.well-known/security.txt.
No method of transmission over the internet is 100% secure. If you believe your information has been compromised, contact us immediately at .
We use minimal cookies necessary to operate our website. We do not use third-party advertising cookies, tracking pixels, behavioral analytics scripts, or any other third-party tracking technologies. Vercel Analytics is explicitly disabled on our deployment.
Cloudflare may set a __cf_bm cookie for bot management and security. This cookie does not track you across sites and is not used for advertising.
As of March 11, 2026, Adworth employs multiple layers of Cloudflare bot protection on adworth.app to prevent unauthorized AI training crawlers from scraping site content. These protections are purely defensive and do not collect, store, or process any user personal data:
robots.txt file at adworth.app/robots.txt includes explicit Disallow: / rules for 13 known AI training crawlers: GPTBot, ChatGPT-User, Google-Extended, CCBot, anthropic-ai, Claude-Web, Bytespider, cohere-ai, PerplexityBot, Amazonbot, FacebookBot, meta-externalagent, and Applebot-Extended.These protections apply only to the adworth.app domain. They do not affect Cloudflare Worker API endpoints, worker-to-worker Service Bindings, or any authenticated API traffic. Adworth’s content is proprietary and may not be used to train AI models without express written permission from Adworth LLC.
All Adworth dashboards (Consent API, Privacy Governance Engine, State-Persistence Monitor, Removal Payload Engine, Invisibility Ledger, Ingestion API, Regulation Rules Admin, Waitlist Admin, CCPA Enforcement Gap Admin) handle API keys identically: held in JavaScript memory for the active session only, never written to localStorage, sessionStorage, cookies, or any server-side log, transmitted only to the specific authenticated Worker endpoint over HTTPS, and discarded when the page is closed.
The Adworth consent token injector script, when deployed, may store consent state in localStorage under the key adworth_consent_state. This data stays entirely on your device and is never transmitted to our servers unless you explicitly initiate a consent action. You can clear this at any time through your browser settings.
No Adworth page or worker dashboard loads third-party scripts, advertising pixels, analytics services, or behavioral tracking technologies. This applies to adworth.app and all adworthllc.workers.dev subdomains.
Adworth’s services are not directed to children under 13. We do not knowingly collect personal information from children under 13. If you believe we have inadvertently collected such information, contact us and we will delete it promptly.
For users aged 13–17, the Minor Shield Protocol (Section 8) applies automatically. No advertising data access is permitted, no behavioral profile is built, and consent tokens for minor users cannot be used in the consent marketplace.
For terms of use, please see our Terms of Service.
To report a security vulnerability, see our responsible disclosure policy at adworth.app/.well-known/security.txt or email with the subject line “Security Disclosure.” We will respond within 72 hours.
Enterprise customers requiring a Data Processing Agreement (DPA) under GDPR Article 28 or other data governance documentation should contact with the subject line “DPA Request.” We will respond within five business days. Formal DPA templates are in development as part of our enterprise readiness roadmap.
We may update this Privacy Policy to reflect changes in our practices, technology, or legal requirements. When we make material changes, we will notify waitlist members by email at least 14 days before changes take effect. The “Last updated” date at the top of this page reflects the last revision. Continued use of Adworth services after the effective date constitutes acceptance of the updated policy.
In particular, this policy will be updated when: (1) the State-Persistence Monitor and Removal Payload Engine transition from simulated to live operation; (2) the Privacy Cockpit extension is published to the Chrome Web Store; (3) the consent marketplace launches; (4) the Nashville Offline Protocol or Biometric Gating features enter development; and (5) new regulations are added to the adworth-rules regulation rules table (planned: LGPD, UK GDPR, U.S. state laws including Virginia VCDPA, Colorado CPA, Connecticut CTDPA). We will notify users by email in advance of each of these transitions.
This Privacy Policy is governed by the laws of the State of South Carolina, United States. Any legal action shall be brought exclusively in the state or federal courts located in Charleston County, South Carolina.