Document Date: 2025-XX-XX
Intended Status: Informational or Standards Track (to be determined)
Expires: 2025-XX-XX
This document proposes a unified, category-based consent API that JavaScript libraries and frameworks can implement to handle various tracking, analytics, telemetry, AI interactions, and other user-data permissions. While modern browsers offer permissions for features like geolocation and notifications, there is no standard mechanism for user consent regarding cookies, local storage, session storage, performance metrics, AI-driven features, or marketing services. This draft addresses that gap by introducing a single point for checking and storing user consent states across multiple consent categories. The proposal can be polyfilled in existing browsers, with the possibility of eventual native browser support or standardization.
This document is an Internet-Draft submission or a community-driven proposal (not yet adopted by IETF/W3C/WHATWG). Distribution of this document is unlimited. Comments and contributions are welcomed and should be directed to the project’s public repository or mailing list.
- Introduction
- Terminology
- Consent Categories
- Proposed API and Naming Conventions
- Implementation Scenarios
- Security Considerations
- Privacy Considerations
- IANA Considerations
- Acknowledgments
- References
Websites increasingly rely on user data for analytics, performance monitoring, AI-driven features, telemetry, marketing, and more. Current approaches to obtaining and managing user consent are fragmented—each site or library presents its own banner, stores its own cookie or local-storage keys, and provides inconsistent interfaces to third-party scripts.
Goal: Introduce a standardized, JavaScript-based API that allows:
- A single consent check before a library logs performance metrics, sends data to AI services, or sets marketing cookies.
- Consistent naming conventions for various categories of data usage.
- Asynchronous prompts or checks to respect user decisions, including denial or delayed responses.
- Flexible design, enabling polyfills or advanced browser-level implementations.
- Consent: A user’s explicit or implied permission for data handling in one or more categories.
- Consent Category: A named type of data handling or purpose (e.g., "analytics", "marketing", "AI integration").
- Consent Object: A structured data object containing fields such as title, message, description, moreInfoURL, etc.
- User Agent (UA): A browser or environment capable of running JavaScript.
This draft defines common categories websites frequently present to users when requesting consent. Implementations MAY add or rename categories using the same API structure, depending on regulatory needs and service-specific data uses.
- Purpose: Strictly necessary for the site to function (e.g., session management, security tokens, basic infrastructure).
- Consent Handling: Often not subject to explicit user opt-in under certain privacy regulations (e.g., GDPR) because it is “strictly necessary.” However, it is still recommended to disclose this to ensure full transparency.
- Purpose: Enables user-friendly features such as remembering language preferences, site customizations (e.g., theme), or saved user profile details.
- Typical Use: Storing user’s choice of dark mode, custom layouts.
- Consent Handling: Usually optional, but many sites treat it as low-risk and sometimes group it with “essential.”
- Purpose: Collect usage statistics, typically anonymized or aggregated, measuring page views, session duration, navigation paths, etc.
- Typical Use: Tools like Google Analytics or internal site metrics.
- Consent Handling: Often requires explicit consent under stricter regulations.
- Purpose: Monitor site speed, resource loading, error rates, and other technical performance metrics.
- Typical Use: Monitoring largest contentful paint, time-to-first-byte, JavaScript error logs.
- Consent Handling: Some implementations treat it as distinct from analytics to let users opt in to performance metrics while declining broader analytics.
- Purpose: More detailed or continuous data gathering about user interactions, clicks, or advanced event logging to improve UX or develop features.
- Typical Use: Tracking in-app events, usage patterns, or advanced workflows in single-page applications.
- Consent Handling: Usually optional since it can involve more user-specific data than simple page view stats.
- Purpose: Personalized advertising, retargeting, or tracking conversions to measure campaign effectiveness.
- Typical Use: Ad network scripts, affiliate or retargeting pixels, data sharing with third-party ad platforms.
- Consent Handling: Commonly requires explicit user opt-in (e.g., GDPR). Often a separate toggle in consent banners.
- Purpose: Tailoring content or UI specifically to each user’s profile or behavior.
- Typical Use: Recommendation engines, customized feeds, dynamic content suggestions.
- Consent Handling: May or may not involve third parties. If personal user data is extensively collected or shared, a distinct consent toggle is recommended.
- Purpose: Storing raw data (including IP addresses, error traces, or server logs) that can contain personal information.
- Typical Use: Basic server logs, error tracking, security audits.
- Consent Handling: Part of operational needs, but long-term storage or sharing can raise privacy concerns if the logs are not purely “essential.”
- Purpose: Running experiments on different UI or feature variants, requiring user identifiers to track which variant was displayed.
- Typical Use: Growth experiments, feature rollouts, user experience tests.
- Consent Handling: Often combined with analytics or telemetry. If it collects personal info, a separate toggle might be appropriate.
- Purpose: Allow the website or application to send user-generated content or user data to an AI/LLM service (e.g., chatbots, content generation, advanced analytics).
- Typical Use: Chatbot interactions, personalized AI-driven responses, content moderation, or recommendation systems powered by machine learning.
- Data Handling: May involve sending personal or sensitive data to an external AI service, which could retain or analyze it.
- Consent Handling: Generally requires explicit user consent, especially if data is shared with a third-party AI provider. Must specify how AI data is stored or used.
- Purpose: Implementations MAY define any additional categories beyond the above (e.g., “socialMedia,” “thirdPartyDataSharing”). Ensure naming consistency and provide clear explanations to users.
// Request consent for "analytics"
navigator.consent.requestPermission("analytics", {
title: "Allow Analytics?",
message: "We collect usage data to improve site performance.",
description: "Anonymous metrics help us understand how users navigate our site.",
moreInfoURL: "https://example.com/privacy/analytics"
}).then(result => {
if (result === "granted") {
// Initialize analytics scripts
}
});
// Separately request AI features
navigator.consent.requestPermission("aiIntegration", {
title: "Enable AI Features?",
message: "We use AI to analyze your queries and provide tailored responses.",
description: "Your inputs may be sent to our AI service provider for processing.",
moreInfoURL: "https://example.com/privacy/ai"
}).then(aiResult => {
if (aiResult === "granted") {
// Enable AI-driven chat or features
}
});- All methods for requesting or checking consent SHOULD be asynchronous, typically returning a Promise.
- Possible outcomes include:
"granted","denied","undecided","dismissed", or an error.
When requesting consent, a metadata object can define:
- title: Short user-facing heading
- message: Brief explanation of the request
- description: Additional details or disclaimers
- moreInfoURL: Link to full policy or vendor list
- defaultValue (optional): Often
"undecided"until user action - labels (optional): Localized text for accept/deny buttons or disclaimers
navigator.consent.requestPermissions(["analytics", "telemetry", "aiIntegration"], {
analytics: {
title: "Analytics",
message: "We collect usage data for improving site content."
},
telemetry: {
title: "Telemetry",
message: "Detailed logs of feature usage to guide development."
},
aiIntegration: {
title: "AI Interaction",
message: "Send your queries to our AI service for custom responses."
}
}).then(results => {
// results example:
// { analytics: "granted", telemetry: "denied", aiIntegration: "granted" }
});- A JavaScript library could implement
navigator.consentfor older browsers, or expose a function likerequestUserConsent. - Frameworks (React, Vue, Angular) can hook into consent checks at initialization, conditionally loading scripts or modules only if consent is granted.
- A polyfill can store user decisions in a first-party cookie or localStorage.
- For tamper-resistance or more secure storage, additional measures would be needed, but full protection may require native support.
- In the future, browsers could adopt a standardized approach, storing user decisions securely to prevent tampering by scripts.
- This would simplify site logic and enhance privacy by letting the browser manage or revoke permissions at a higher privilege level.
- Tamper Resistance: A purely library-based approach can be manipulated by malicious scripts. Native browser support would be inherently more secure.
- Cross-Origin Restrictions: Ensure that only authorized domains or subdomains can read or modify consent states.
- AI Data Transfer: Transmitting user data to an AI service raises concerns about interception or unapproved processing.
- Regulatory Compliance: Must align with local laws (e.g., GDPR, CCPA) regarding explicit opt-in, data handling, and user rights.
- Granular vs. Bulk: Some regulations mandate granular consent, whereas others allow aggregated toggles if the purposes are clearly explained.
- AI Transparency: Especially for AI/LLM usage, inform users about how data might be stored or used to train models.
- Revocation: Allow users to change or revoke consent choices easily.
This document does not require any IANA actions. Future standardization could create a registry for recognized “consent categories,” potentially managed by relevant bodies or in cooperation with privacy regulators.
Special thanks to privacy advocates, open-source contributors, and developers who shaped this proposal through real-world challenges. Efforts around consent management platforms, cookie banners, AI-based services, and privacy regulations have provided valuable insights.
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
- RFC 8174: Clarification of RFC 2119
- GDPR (EU Regulation 2016/679)
- CCPA (California Consumer Privacy Act)
- W3C Permissions API
- Global Privacy Control (GPC)
- IAB Europe TCF
This draft introduces an API that allows libraries to define and request user consent across multiple well-known categories—essential, analytics, performance, AI integration, marketing, etc.—using consistent naming conventions. The design emphasizes asynchronous approval, robust metadata for each request, and the option to handle batch requests for improved user experience.
Next Steps:
- Gather community feedback via public repositories or forums.
- Build and test polyfill or partial implementations.
- Engage with standards bodies (IETF, W3C, WHATWG) if there is sufficient interest in a standardized consent API.
End of Draft