Permissions, Consent, and Privacy

Draft 0.1 — 2 August 2026
This document is a product and architecture baseline, not a privacy notice or jurisdiction-specific legal opinion.

Objective

ANUKA’s distribution model is powerful because it can appear inside a website and inside a participant’s browser. That power must be constrained deliberately.

The default rule is:

Collect less, ask later, explain clearly, and make revocation real.

ANUKA should earn broad distribution by requiring less trust than competing tools, not by quietly demanding more access.

Separate permission domains

ANUKA permissions come from different authorities and must never be collapsed into one vague allowed state.

Website-owner authorization

The website owner authorizes installation of the Site SDK, GTM template, package, or plugin and chooses which product capabilities are enabled.

Visitor consent

The website visitor grants or denies consent for data uses where consent is required by the site’s policy or applicable law.

Browser-extension permission

The participant grants the extension access to the current tab, selected origins, browser storage, notifications, or other extension capabilities.

ANUKA account authorization

The authenticated participant or organization authorizes ANUKA API actions under their account and role.

Project and network policy

The resident product and ANUKA Network determine whether an authenticated actor may perform the requested action.

All five layers may be required for one operation. Permission at one layer does not override denial at another.

Data classes

Every event and field SHOULD declare one data class.

Class 0 — No collection

UI behavior that remains local to the browser or page and sends no data to ANUKA.

Examples:

• opening or closing a local panel;
• changing a local display preference;
• rendering static product information already delivered with the page.

Class 1 — Operational

Data necessary to deliver a user-requested service safely.

Examples:

• project identifier;
• protocol version;
• capability request;
• authentication and security events;
• rate-limit state;
• error diagnostics with minimized context.

Operational data must not be reused for unrelated advertising merely because it was technically collected.

Class 2 — Product analytics

Events used to understand adoption and improve ANUKA.

Examples:

• widget opened;
• feedback flow completed;
• installation step completed;
• module enabled;
• aggregate feature usage.

Product analytics should avoid page content and personal identifiers unless justified and disclosed.

Class 3 — Community content

Content intentionally submitted by participants.

Examples:

• feedback;
• votes;
• comments;
• proposals;
• test reports;
• public profile information.

The interface must state the intended audience before submission.

Class 4 — Business evidence

Company data used to support metrics, claims, experiments, diligence, or attestations.

Examples:

• revenue events;
• conversion data;
• support metrics;
• release records;
• experiment assignments and outcomes.

Business evidence requires source, scope, retention, access, and publication rules.

Class 5 — Sensitive or restricted

Data requiring heightened controls or exclusion from the initial product.

Examples may include:

• precise financial account data;
• government identifiers;
• health data;
• private communications;
• authentication secrets;
• children’s data;
• employee performance records;
• data revealing protected or highly sensitive traits.

The MVP SHOULD avoid Class 5 data unless a dedicated, reviewed product requirement exists.

Module-level collection

The widget is not one indivisible consent object. Modules have separate purposes.

Module	Default data posture
Static trust badge	No collection or operational-only request
Public Backstage view	Operational delivery; analytics optional
Feedback submission	User-requested community content
Voting	Account or anti-abuse identifier may be required
Sponsored feature	Payment, contract, fraud, and tax data under separate terms
Public live activity	Aggregate or de-identified display only
Business analytics connector	Explicit organization authorization and evidence policy
Browser extension exploration	activeTab and user-invoked access first
Investor data room	Explicit organization sharing and recipient access control

A site owner must be able to enable a useful low-data mode.

Consent modes

ANUKA SHOULD support three implementation profiles.

Essential-only

• no nonessential cookies or local identifiers;
• no product analytics before consent where required;
• only data necessary for the requested interaction;
• suitable as the safest default for public informational Backstage pages.

Basic consent-gated

• nonessential modules do not load or transmit until the site’s consent solution reports permission;
• denied consent means no analytics or personalization events are sent;
• user-requested operations may still function when legally and technically appropriate.

Advanced policy-aware

• the adapter loads in a restricted state;
• collection and storage behavior change according to granular consent signals;
• any limited or cookieless transmission must be documented accurately;
• the site remains responsible for choosing a lawful configuration.

Google Consent Mode distinguishes basic and advanced implementations for Google tags. ANUKA may map to compatible consent signals, but must not imply that Google’s mechanism alone establishes legal compliance for ANUKA or the host site.

GTM consent integration

The GTM template SHOULD:

• declare built-in consent checks where appropriate;
• allow site owners to require additional consent types;
• read consent state through supported GTM template APIs;
• default nonessential collection to denied until configured;
• expose preview diagnostics explaining why a tag did or did not run;
• avoid attempting to become the site’s consent-management platform in the initial release.

The adapter should integrate with an existing CMP or site consent solution rather than silently inventing consent.

Extension permission ladder

Level 0 — Extension shell

No page access. The extension can show account status, saved items, and instructions.

Level 1 — User-invoked current tab

Use activeTab after an explicit action such as clicking the extension button.

Chrome documents activeTab as temporary access to the current tab that ends when the user navigates to another origin or closes the tab. It avoids the installation warning associated with persistent broad host access.

Level 2 — Selected-site access

Request optional host permission for a specific origin after explaining a feature that benefits from persistence.

Level 3 — Pattern access

Request a limited set of domain patterns only for a clear, active product requirement.

Level 4 — Broad access

<all_urls> is not an MVP default. It requires a separately reviewed use case, store-policy justification, security assessment, and clear participant choice.

Browser data minimization

The extension MUST NOT collect generalized browsing history merely because it can observe tabs or pages.

The MVP SHOULD send the current origin only when:

• the participant invokes ANUKA;
• the participant enabled persistent access for that origin;
• a clearly enabled feature requires it.

Avoid sending:

• full URL query strings by default;
• page text;
• form values;
• passwords or authentication fields;
• private dashboard contents;
• unrelated tab lists;
• full browsing timelines;
• screenshots without an explicit capture action.

URL paths should be stripped or normalized unless required by the current feature.

Public versus permissioned display

A company’s decision to display data publicly must be specific.

Publication controls SHOULD support:

• exact metric;
• aggregation level;
• date range;
• update frequency;
• comparison baseline;
• delay window;
• minimum cohort size;
• source label;
• whether absolute values or only trends are shown;
• revocation or replacement policy.

Public data must not expose individuals through small cohorts or unique event combinations.

Live activity visualization

A live map or activity stream must be designed as aggregate visualization, not surveillance theater.

Rules:

• do not show IP addresses;
• do not expose exact visitor locations;
• use coarse geographic aggregation;
• apply minimum cohort thresholds;
• add time delay where re-identification is plausible;
• avoid displaying unique user paths;
• label modeled or sampled activity;
• do not imply real-time precision if the feed is batched;
• provide an owner kill switch.

Visual beauty is not a justification for collecting more data.

Feedback publication

Feedback begins private to the intended recipient unless the participant knowingly chooses a public audience.

Publication workflow SHOULD distinguish:

1. private feedback;
2. organization-visible feedback;
3. community-visible feedback;
4. publicly attributable feedback;
5. publicly anonymous or pseudonymous feedback where supported.

When a company requests permission to publish feedback, the participant should see the exact content, attribution, destination, and revocation policy.

Reputation and privacy

Portable reputation does not require universal exposure.

A participant SHOULD be able to:

• keep raw work records private;
• present selected credentials;
• disclose a derived capability claim without every underlying detail where supported;
• separate public identity from a qualified pseudonym when policy permits;
• challenge, correct, or contextualize records;
• see who accessed permissioned records where practical;
• revoke optional presentations without rewriting historical truth.

ANUKA must distinguish deletion, revocation, correction, and loss of public visibility.

Employee and worker data

Performance analytics concerning identifiable workers create heightened legal, ethical, and organizational risks.

The public Presence MVP MUST NOT expose individual employee KPIs.

Any later workforce module requires:

• a legitimate and documented purpose;
• role-based access;
• notice and applicable consent or legal basis;
• anti-discrimination review;
• contest and correction rights;
• protection against context collapse;
• retention limits;
• separation from public contributor reputation unless deliberately linked by the participant.

A company quality network must not become covert worker surveillance.

AI-agent access

AI agents receive no implicit data rights.

Every agent request must resolve:

• principal;
• purpose;
• tool and version;
• requested scope;
• data class;
• consent or authorization state;
• retention behavior;
• whether the output may be published or used for training.

Sensitive inputs should not be included in prompts unless the selected provider, contract, configuration, and policy permit it.

Storage and identifiers

The adapter SHOULD avoid persistent browser identifiers until needed.

Where storage is used:

• state the purpose;
• scope keys to the project and environment;
• set retention or expiration;
• separate security storage from analytics storage;
• avoid cross-site identifiers;
• support reset and deletion;
• encrypt secrets appropriately;
• never treat local storage as secure credential storage on the host page.

Data retention

Every stored category needs a retention rule.

Default direction:

• transient handshake data: minutes or hours;
• security logs: risk-based, access-controlled period;
• raw product analytics: short retention followed by aggregation;
• feedback: until resolved, withdrawn where applicable, or policy expiry;
• financial and contractual records: according to legal and accounting obligations;
• verified evidence: versioned and retained with correction or revocation status;
• browser permission telemetry: aggregate where possible.

Keep forever because reputation is not an acceptable policy.

Data sharing

The product must name the role of each recipient:

• service provider or processor;
• independent product or resident company;
• public audience;
• investor or diligence recipient;
• payment provider;
• identity or attestation provider;
• AI model provider;
• analytics provider.

ANUKA should not present the network as one data controller when multiple independent entities determine purposes and means.

Security controls

Minimum controls include:

• HTTPS;
• scoped API tokens;
• server-side authorization;
• content-security guidance;
• dependency and supply-chain monitoring;
• SRI for pinned remote assets where supported;
• origin and schema validation;
• rate limiting and abuse detection;
• encryption in transit and appropriate encryption at rest;
• secret rotation;
• audit logs;
• incident and revocation procedures.

Transparency interface

Every ANUKA surface SHOULD provide a compact Why am I seeing this? view showing:

• whether the site installed ANUKA;
• presence state;
• which module is active;
• what data the current interaction uses;
• whether data leaves the device;
• the relevant organization and ANUKA policy links;
• current permission and consent state;
• how to disconnect or report a problem.

Prohibited patterns

ANUKA adapters MUST NOT:

• hide collection inside a decorative badge;
• request broad permissions before demonstrating value;
• scrape authenticated pages by default;
• sell browsing history;
• combine participant reputation with unrelated surveillance data;
• represent public-source inference as company verification;
• use dark patterns to obtain consent;
• continue nonessential collection after denial;
• publish sensitive business metrics without authorized configuration;
• use consent as a blanket waiver of security or fairness duties.

MVP privacy acceptance criteria

The first release is ready only when:

• the extension works with activeTab and without broad host permissions;
• the widget has an essential-only mode;
• GTM consent behavior is documented and testable;
• all outbound event schemas are documented;
• page paths and content are excluded by default;
• public metrics require owner selection;
• unclaimed profiles are unmistakable;
• feedback audience is selected before submission;
• data deletion and project disconnect flows exist;
• the privacy notice accurately matches production behavior.

Sources

• Chrome — Declare permissions
• Chrome — Permission warning guidelines
• Chrome — Protect user privacy
• Mozilla — Permissions API
• Google — Consent mode overview
• Google — Set up consent mode on websites
• Google — GTM custom template permissions
• NIST Privacy Framework

Verification record

• Sources opened and checked: 2 August 2026
• Privacy baseline: Product draft
• Jurisdiction-specific legal review required: Yes
• Production data inventory required: Yes