Home › Resources

Chrome Extension Privacy Policy: What Google Requires and How to Create One

Published August 26, 2026 · Updated September 30, 2026

Every Chrome extension that handles user data needs a privacy policy URL before Google will approve it for the Chrome Web Store. The policy must be publicly accessible, describe exactly what data the extension collects and why, and match the data-use disclosures you certify in the Developer Dashboard's Privacy practices tab. Skip it and the extension fails review. Submit a vague or generic document and the review team rejects it anyway -- they read the policy, not just the URL field, and they cross-check it against the "Single purpose" description and permission justifications you filed alongside it.

This guide covers when the Chrome Web Store requires a policy, what Google's review process actually checks, how to fix the most common rejection emails, the data categories extension developers commonly overlook, how the "Single purpose" field and the Limited Use policy interact with your privacy policy, how to write permission justifications that pass review, how to complete the Data Usage certification, where to host the finished policy, and a complete sample policy you can copy. If you need a policy fast, you can generate a privacy policy for free and host it at no cost.

Why Google Requires a Privacy Policy for Chrome Extensions

Google treats the privacy policy as a gatekeeper for the Chrome Web Store, the same way Google Play and the Apple App Store require one for mobile apps. The requirement exists for three overlapping reasons, and understanding them helps explain why the review team is strict about wording, not just presence of a URL.

User trust at the point of install. A user deciding whether to add an extension has no way to inspect the code before clicking "Add to Chrome." The privacy policy -- along with the Data Usage disclosures Google surfaces directly on the listing page -- is the only document telling them what the extension can see, what it stores, and where data goes. Without it, a user is granting broad browser access to an unknown quantity.

Regulatory exposure across jurisdictions. Extensions published to the Chrome Web Store are available worldwide by default unless a developer restricts distribution by country. An extension with users in California, the EU, and the UK simultaneously falls under the CCPA, the EU GDPR, and the UK GDPR at once. Google cannot audit every extension's data practices against every regulation, so it shifts that responsibility onto the developer through a mandatory policy disclosure plus a certification you complete yourself.

Review as a quality and safety gate. Google's Chrome Web Store Developer Program Policies state plainly that any extension handling personal or sensitive user data must provide a privacy policy, and that the policy, together with the in-dashboard disclosures, must accurately reflect the extension's actual behavior. Google's own guidance for developers frames this as core to "maintaining user trust" in the extensions ecosystem -- an ecosystem that runs with elevated access to browsing activity, page content, and sometimes account data.

Three conditions trigger the requirement in practice:

• The extension requests permissions that access user data. Permissions like tabs, history, bookmarks, cookies, webRequest, identity, and any host permissions (e.g., *://*.example.com/* or <all_urls>) give the extension access to browsing data, authentication tokens, or page content. Requesting any of these means the extension can access user data, and Google treats that as handling it.
• The extension collects any information from the user. Form inputs, email addresses, preferences, usage analytics -- if the extension captures information a user provides or generates, the Privacy policy field in the Store listing tab is mandatory.
• The extension uses remote code or connects to external services. Extensions that fetch scripts, send data to an API, or communicate with a backend server are transmitting information outside the browser. Google requires disclosure of what data leaves the device and where it goes.

Extensions that request zero data-touching permissions (for example, a simple theme or a CSS-only modifier with no host permissions) can technically skip the privacy policy field. However, even these extensions benefit from having one -- Google's review moves faster when the data story is unambiguous, and users see the policy link directly on the extension's Chrome Web Store listing page. Other non-mobile platforms enforce the same pattern: Amazon requires a hosted policy before certifying an Alexa skill for the Alexa Skills Store, and Discord blocks bot verification past 100 servers without a working policy URL in the Developer Portal. The specifics differ; the gating mechanism -- no policy, no distribution -- is identical.

What the Chrome Web Store Review Checks

Google's Chrome Web Store review runs in two stages. An automated pipeline scans the submitted ZIP for known patterns -- permission usage, remote code references, manifest structure, obfuscated code -- and flags items for human review. A human reviewer then checks the flagged items against the Developer Program Policies. Extensions requesting sensitive permissions (webRequest, <all_urls>, tabs, identity, cookies, clipboardRead) are routed to human review far more often than extensions with narrow permissions like activeTab or storage. Reviewers check several specific conditions before approving an extension.

• The privacy policy URL loads to the actual policy text. The link entered in the Store listing tab's Privacy policy field must open directly to the policy content -- not a homepage, not a generic legal page, not a link that redirects through a login wall or returns a 404. Google's automated checks fetch the URL before human review begins and expect a 200 response that renders the policy immediately.
• The policy describes the extension's actual data practices. A boilerplate document about website cookies and server logs that never mentions browser extensions, permissions, or the specific data the extension accesses will be flagged. The content must be relevant to the extension being submitted, and it must name the extension.
• Declared permissions match the policy disclosures and the "Single purpose" description. If manifest.json requests activeTab, storage, and host permissions for specific domains, the privacy policy must explain why those permissions are needed and what data they access, and that explanation must be consistent with the single-sentence purpose you entered on the Privacy practices tab. Mismatches among the manifest, the policy, and the stated purpose trigger rejection.
• The Data usage certification on the Privacy practices tab is consistent with the policy. The dashboard asks you to certify which data types the extension collects (see the certification section below). If the certification says no personally identifiable information is collected but the policy mentions storing email addresses, the submission fails.
• Each permission has a specific, accurate justification. The Permission justification section requires a written explanation for every permission in the manifest. Reviewers read these justifications and compare them against what the extension's code actually does; see the justification-writing section below for what passes and what gets flagged.
• The extension does not collect more data than it needs. Google enforces a minimum-data principle: the extension must "collect and use the minimum amount of data needed" to fulfill its single purpose. A tab manager that requests <all_urls> and reads page content when it only needs tab titles will be questioned during review.
• No remote code execution. Manifest V3 requires all executable logic to be packaged inside the extension ZIP. Extensions that fetch and execute remote JavaScript, or that construct executable code strings from a remote config, are flagged regardless of what the privacy policy says.

Troubleshooting Chrome Web Store Rejections

When Google rejects a submission, the developer receives an email from Chrome Web Store Developer Support with a subject line reading "Your item was not published" or "Action required: Your extension [name]." The body cites a specific Developer Program Policy section and, in most cases, names the offending field in the dashboard. Below are the rejection patterns developers hit most often, what triggers each one, and the fix.

Privacy policy URL missing or broken

The rejection email reads: "Your extension does not comply with the following Chrome Web Store policy: User Data Privacy — Prominent Disclosure. Your extension must provide a privacy policy." This fires when the Privacy policy URL field on the Store listing tab is blank, or when the URL resolves to a non-200 status. Google's automated check fetches the URL before human review begins -- a 404, a redirect loop, or a login wall stops the process immediately.

Fix: Paste a fully qualified https:// URL that resolves directly to the policy text, and test it in an incognito window. If you do not have stable hosting, generate and host a policy for free at a permanent URL.

Policy does not match the extension's data practices

The email states: "Your extension's privacy policy does not adequately disclose how user data is collected, used, and shared." This fires when the policy is recycled from a mobile app or website and never mentions Chrome permissions, the extension name, or browser-specific data flows. Reviewers cross-check the manifest.json permissions, the "Single purpose" text, and the policy content against one another.

Fix: Rewrite the policy to name the extension explicitly and to describe each permission's actual data flow in plain language -- not just the permission's technical name. Align the wording with the "Single purpose" field so a reviewer sees one consistent story across all three surfaces.

Excessive permissions without justification

The rejection references the "Use of Permissions" policy and reads: "Your extension is requesting permission(s) that are not required for implementing its functionality." The permissions that trigger this most often are <all_urls>, webRequest, webRequestBlocking (Manifest V2), tabs when activeTab would suffice, clipboardRead on extensions with no paste feature, identity, cookies, and history.

Fix: Remove any permission the extension does not actively use, switch tabs to activeTab wherever the feature only needs the current tab, and move anything non-essential into optional_permissions so it is requested at runtime rather than declared upfront. See the permission justification section for detail on which permissions draw heightened scrutiny and how to word the justification field so it survives review.

Remote code or unreviewable logic

The email cites the "Code Readability Requirements" policy: "Your extension is loading and executing remote code or modules that are not included in the extension package." Manifest V3 banned remotely hosted code effective January 2023. Extensions that use chrome.scripting.executeScript with dynamically constructed code strings, or that fetch() JSON configuration that alters runtime behavior, still get flagged.

Fix: Bundle all executable logic inside the submitted ZIP. If the extension fetches remote data, make sure that data is used only as data (rendering content, populating a list) and never evaluated or injected as executable script.

Single-purpose violation

The email cites the "Single Purpose" policy: "Your extension does not have a single purpose" or a variant naming two unrelated functions bundled into one extension. This fires when the "Single purpose" text field on the Privacy practices tab describes multiple unrelated capabilities -- for example, a tab manager that also injects a shopping-coupon widget.

Fix: Narrow the extension to one core function, or split unrelated features into separate extensions. Rewrite the "Single purpose" field to state that one function in a single sentence, and make sure every requested permission maps back to it.

Limited Use violation

The email reads: "Your extension does not comply with the Chrome Web Store's Limited Use policy." This fires when an extension that accesses user data uses that data for something beyond its stated single purpose -- most commonly, transmitting browsing data to an advertising or analytics network, or transferring data for purposes unrelated to the extension's function. See the next section for exactly what Limited Use restricts and how the privacy policy needs to reflect it.

Fix: Audit every place the extension transmits data externally. If any transmission serves advertising, data brokering, or an unrelated purpose, remove it. Then update both the privacy policy and the Data usage certification to reflect the corrected, narrower data flow.

Data an Extension Collects That Developers Overlook

Most extension developers disclose the obvious inputs: an email address from a login form, a search query typed into the popup. But Chrome extensions handle several less obvious data categories that trip up review and violate privacy laws if undisclosed.

• Permissions-based browsing data. The tabs permission exposes the title and URL of every open tab. The history permission exposes the user's full browsing history. The bookmarks permission exposes saved bookmarks. Even if the extension only reads this data locally and never transmits it, the capability itself means the extension is handling personal data under GDPR and CCPA definitions -- disclose it.
• Host permissions and page content. Host permissions (specific domains or <all_urls>) allow content scripts to read and modify page content. If a content script reads form values, scrapes text, or captures DOM elements from pages the user visits, that is personal data collection. Even reading a page title for display in the extension popup counts if it is stored or transmitted.
• The storage API. Data saved with chrome.storage.local or chrome.storage.sync persists across sessions. If the extension stores user preferences, authentication tokens, cached page data, or usage counters, those are persistent attributes tied to a user profile -- especially storage.sync, which is linked to the user's Google account and synced across devices.
• Remote code and API calls. Any fetch() call, WebSocket connection, or external script load transmits data outside the browser. Even a simple analytics ping or crash-report payload contains metadata (extension version, browser version, possibly URLs or error contexts) that constitutes data transmission.
• The identity API and OAuth. Extensions that use chrome.identity to authenticate users via Google OAuth receive profile data -- name, email, profile photo URL. Extensions that authenticate with third-party services via custom OAuth flows collect tokens and profile data the same way.
• Web request interception. The webRequest or declarativeNetRequest permissions let extensions observe or modify network requests. Even if the extension uses this to block ads or modify headers, the capability to inspect request URLs and headers means it has access to browsing patterns.
• Cookies. The cookies permission grants read and write access to browser cookies for specified domains. Cookies frequently contain session tokens, user IDs, and tracking identifiers -- all personal data.

The rule is straightforward: if the extension can access, read, store, or transmit anything that traces back to a specific user or device, disclose it in the policy.

The Single-Purpose Policy and Limited Use Compliance

Two policy concepts sit underneath most Chrome Web Store rejections that are not simple URL problems: the Single Purpose requirement and the Limited Use policy. Both are enforced through the same "Privacy practices" tab where you complete the Data usage certification, and both must line up with what your privacy policy actually says.

The "Single purpose" field

On the Privacy practices tab, the first section asks a direct question in a text field: "What is the single purpose of your extension?" Google's Developer Program Policies require every extension to have exactly one narrow purpose, described clearly enough that a reviewer -- and a user reading the listing -- can understand what the extension does without inferring it from the permission list. An extension that reads "manages your tabs and also shows you shopping deals" names two unrelated functions and is a rejection candidate. "Groups and organizes your open tabs into named workspaces" names one.

This field is not decorative. Reviewers use it as the reference point for every other check: does the permission list map to this purpose, does the "Permission justification" text for each permission tie back to it, and does the privacy policy describe the same scope of function. If your policy discusses features or data uses that fall outside the single-purpose description, that is treated the same as an undisclosed feature.

Google's Limited Use policy

Since 2021, Google has enforced a Limited Use policy for any extension that accesses user data through its permissions. The policy restricts what you may do with that data to four allowed uses tied directly to the extension's single purpose:

• Providing or improving features that are prominently disclosed to the user as part of the extension's function.
• Complying with applicable law, or protecting against fraud, abuse, or security threats.

And it explicitly prohibits several uses regardless of user consent or disclosure:

• Using user data for serving advertisements of any kind, including personalized or interest-based advertising.
• Selling user data to third parties, data brokers, or advertising exchanges.
• Transferring user data for creditworthiness or lending purposes.
• Using or transferring user data for any purpose unrelated to the extension's single purpose -- even a purpose the developer considers benign, like cross-product analytics for an unrelated app in the same company's portfolio.

This is precisely what the two certification checkboxes on the Data usage section ask you to affirm: that the extension does not sell user data, and that it does not use or transfer user data for purposes unrelated to its single purpose. Checking those boxes without actually enforcing the restriction in your code and your third-party contracts is what produces the "Limited Use violation" rejection email described in the troubleshooting section above.

Keeping the privacy policy aligned

The single purpose you declare, the Limited Use restrictions you certify, and your privacy policy are three descriptions of the same underlying set of facts. They need to agree exactly:

• If the dashboard's single purpose is "block trackers on webpages," the policy should not describe an ad-personalization feature -- that would violate Limited Use even if disclosed.
• If the policy states that data "is never sold or shared with advertisers," the Data usage certification's "not sold" checkbox must actually be true in practice, not just checked.
• If a permission's data is used solely to power the single purpose, say so explicitly in the policy rather than leaving the reader to infer scope from a general statement like "we may use your data to improve our services," which reads as open-ended and inconsistent with Limited Use.

Practically, this means drafting the "Single purpose" field first, then writing permission justifications that trace back to it, then drafting a privacy policy whose data-use section repeats the same scope in fuller language. Do them in the reverse order and it is easy to end up with a policy that promises broader flexibility than the Limited Use policy allows.

Required Disclosures and the Data Usage Certification

Since 2021, the Chrome Web Store Developer Dashboard includes a Privacy practices tab where developers must certify their extension's data handling. This certification is separate from the privacy policy URL but must be consistent with it. Contradictions between the two are a fast path to rejection.

To reach the certification, open the Developer Dashboard at chrome.google.com/webstore/devconsole, select your extension, and click "Privacy practices" in the left sidebar (it sits between "Store listing" and "Distribution"). The page is divided into three sections that must all be completed before you can submit for review.

Section 1 — "Single purpose." A text field labeled "What is the single purpose of your extension?" requires a plain-language description. Google enforces single-purpose policy strictly: if your description names two unrelated functions, reviewers may reject it. State the core function in one sentence. See the section above for how this field anchors the rest of your submission.

Section 2 — "Permission justification." For each permission declared in your manifest.json, a row appears with the permission name and a text field labeled "Justification." Explain why the permission is needed in concrete terms. Generic justifications like "needed for the extension to work" are flagged by reviewers. The dedicated section below walks through exactly how to write these.

Section 3 — "Data usage." This section asks you to certify which data types the extension collects. The data categories appear as checkboxes with these exact labels:

• Personally identifiable information — name, address, email address, age, date of birth, phone number, or Social Security number
• Health information
• Financial and payment information
• Authentication information — credentials, security questions, or personal identification numbers
• Personal communications — emails, texts, or chat messages
• Location — region, IP address, GPS coordinates, or geolocation data
• Web history — list of web pages the user has visited
• User activity — network monitoring, clicks, mouse position, scroll, or keystroke logging
• Website content — text, images, sounds, videos, or hyperlinks from websites the user visits

For each checked category, a follow-up asks whether the data is "Used locally only" or "Transferred out of the user's device." If you select "Transferred," you must specify whether the destination is your own servers, third-party servers, or both.

Below the data categories, two certification statements appear as checkboxes that you must affirm or deny:

• "I certify that my extension doesn't sell user data to third parties, outside of the approved use cases described in the Chrome Web Store Developer Program Policies."
• "I certify that my extension doesn't use or transfer user data for purposes that are unrelated to the item's single purpose."

These pledges appear on the extension's Chrome Web Store listing under a "Privacy practices" section visible to users before they install. If your privacy policy says data may be shared with advertising partners but you certify that data is not sold or used for unrelated purposes, the inconsistency can lead to removal from the Web Store -- this is the Limited Use violation covered in the section above.

How the certification maps to your privacy policy

Think of the Developer Dashboard certification as a structured summary and the privacy policy as the full-text version. Every data type you check in the dashboard must have a corresponding section in the policy explaining what is collected, why, who receives it, and how long it is retained. The certification is the machine-readable declaration; the policy is the human-readable one. Both must tell the same story.

Writing a privacy policy that covers permissions, data types, and third-party transfers follows the same process as writing a privacy policy for any app: audit your data flows, map them to purposes, identify third parties, and draft each required section.

Host Permission Justifications: What to Write

The "Permission justification" section of the Privacy practices tab is one of the most-scrutinized parts of a Chrome Web Store submission, and it is also the section developers most often fill in carelessly. Each row corresponds to one permission or host permission pattern declared in manifest.json, with a text field asking why that specific access is required. Reviewers read every justification against the extension's actual behavior -- a generic answer is treated as a red flag even if the permission itself is legitimate.

Permissions that trigger heightened review

Google routes extensions requesting the following permissions to more thorough human review, because each one grants unusually broad access:

• <all_urls> or any broad host permission pattern -- grants the extension access to every website the user visits.
• webRequest / webRequestBlocking (Manifest V2) -- allows observing or altering every network request.
• tabs when the feature only needs the current tab -- exposes the URL and title of every open tab, versus activeTab, which limits access to the tab the user is actively interacting with.
• clipboardRead -- grants access to clipboard contents, which can include passwords or sensitive text copied for unrelated reasons.
• identity -- grants access to the signed-in Google account's profile data via OAuth.
• cookies -- grants read/write access to session tokens and tracking identifiers.
• history -- exposes the user's entire browsing history, not just the current session.

Declaring any of these does not automatically cause rejection, but it does mean the justification field for that row needs to be precise, specific, and verifiable against the extension's code -- vague language on a high-risk permission draws far more scrutiny than the same vague language on storage.

Good justification examples

• activeTab: "Reads the current tab's URL to check it against the user's saved blocklist when the user clicks the extension icon."
• Host permission for *://mail.example.com/*: "Injects a content script on the webmail inbox page to add a one-click archive button; does not read message bodies."
• storage: "Saves the user's blocklist and toggle preferences locally using chrome.storage.local so settings persist between browser sessions."
• cookies: "Reads the session cookie for the configured domain to detect whether the user is logged in, so the extension can show or hide the sync button; the cookie value itself is never transmitted or stored."

Each of these names the specific data touched, the specific action taken, and the specific reason -- a reviewer can verify the claim by reading the corresponding code path.

Bad justification examples

• "Needed for the extension to work." -- names nothing. This exact phrase, or close variants of it, is one of the most commonly flagged justification patterns.
• "Required for core functionality." -- restates that a permission is required without saying what it does.
• "To improve user experience." -- does not describe a data flow at all.
• "Standard permission for this type of extension." -- appeals to convention instead of explaining the actual use.

Generic justifications like these are flagged by reviewers regardless of whether the underlying permission use is legitimate, because the dashboard's purpose is to make the data flow legible, not just to confirm a checkbox was filled.

Narrowing permissions before you justify them

The easiest way to pass this section is to request less. Two changes eliminate the largest share of justification-related rejections:

• Use activeTab instead of tabs wherever the feature only needs to act on the tab the user is currently viewing. activeTab grants temporary access triggered by a user gesture (clicking the extension icon or a context-menu item) and does not expose the URLs or titles of other open tabs. tabs exposes that data for every tab, all the time, and is one of the permissions Google's review most frequently questions.
• Move non-core permissions into optional_permissions. Manifest V3 supports declaring permissions as optional and requesting them at runtime via chrome.permissions.request() only when the user enables the specific feature that needs them. An extension whose core function needs only storage and activeTab, but which has an optional "sync across devices" feature needing identity, should declare identity as optional rather than a required permission at install time. This narrows the install-time permission list, makes each remaining justification easier to write convincingly, and reduces the odds of being routed into heightened review at all.

How to Generate a Chrome Extension Privacy Policy

Writing a Chrome extension privacy policy from scratch means auditing every permission in your manifest, mapping each one to an actual data flow, checking that flow against the Limited Use policy, and formatting the result into a document that satisfies Google's review team. For an extension with host permissions, an OAuth flow, and a backend API, that process can take hours of research and drafting -- and getting the wording wrong produces exactly the kind of mismatch that triggers the rejection emails covered earlier.

A privacy policy generator compresses that work into a guided questionnaire. You select the platforms the extension runs on, the permissions it declares, the data types it handles, the third-party services it calls, and the regulations you need to cover. The generator produces a policy with the correct disclosure language for each selection -- no boilerplate guessing, no missed permission.

Generator vs. template vs. manual drafting

• Generator (fastest for extensions with several permissions). Best when your extension uses host permissions, OAuth via identity, or transmits data to a backend. A free privacy policy generator walks you through each permission and data category and produces a ready-to-submit, hosted policy. Use this path when you need to pass review quickly without hiring a lawyer.
• Template (good for simple extensions). If your extension has straightforward data practices -- activeTab and storage only, no external APIs -- the sample policy below works after you replace the bracketed placeholders. Remove sections that do not apply and verify the result against the review checklist above.
• Manual drafting (for edge cases). Extensions that process health data, financial information, or biometric identifiers, or that are directed at children, may need custom legal language that neither a generator nor a template covers. Consult a privacy attorney for these cases, using the certification categories list as a starting checklist.

Whichever approach you choose, verify the finished document against the Chrome Web Store checklist before submitting: correct extension name, every permission's data use disclosed, Data usage certification consistent with the policy text, and a URL that loads on mobile and desktop without authentication.

Sample Chrome Extension Privacy Policy You Can Copy

Below is a complete privacy policy written for a fictional Chrome extension called "[Your Extension Name]." It covers the data categories most extensions handle -- permissions-based browsing data, stored preferences, authentication, and external communications. Copy the entire block, replace the bracketed placeholders with your extension's details, and remove any sections that do not apply.

This sample covers the most common Chrome extension data flows. If your extension handles additional data -- such as health information, financial data, or biometric identifiers -- add dedicated disclosure sections for those categories. Need to generate a policy tailored to your exact permissions and data practices instead of editing a template? You can build one for free with the generator.

Hosting the URL and Where to Paste It

The privacy policy needs a permanent, publicly accessible URL that loads without authentication on any device. Three hosting approaches cover most Chrome extension developers.

Hosting options

• Your own domain. If you have a website, host the policy at a path like yoursite.com/chrome-extension-privacy-policy. This is the most professional option and gives you full control over updates.
• A free hosted policy. If you do not have a website or do not want to manage hosting, you can generate and host a privacy policy for free. The generated URL is permanent and loads without authentication, which satisfies Google's requirements.
• GitHub Pages or a static site. A free GitHub Pages site with a single HTML page works. The URL is stable and publicly accessible. Ensure the page renders on mobile -- Google's review checks across devices.

Do not use Google Docs, Notion pages, Pastebin links, or any URL that requires login, displays editing UI, or could change without a stable permalink. These are rejected during review.

Adding the URL in the Chrome Web Store Developer Dashboard

1. Open the Chrome Web Store Developer Dashboard and select your extension.
2. Click the Store listing tab in the left sidebar.
3. Scroll to the Privacy policy field. Paste your full URL including https://.
4. Click the Privacy practices tab. Fill in the Single purpose field, write a specific Justification for every permission row, and complete the Data usage certification by selecting the data types your extension handles and their purposes. Every selection must match what your privacy policy describes.
5. Save all changes and submit for review.

After approval, the privacy policy link appears on your extension's Chrome Web Store listing page under the "Additional Information" section, alongside the Data usage summary. Users can review both before installing. The Alexa Skills Store has a similar requirement for Alexa skills, and Discord blocks bot verification without a working policy in the Developer Portal -- the pattern of platform-mandated policies before distribution is standard across app ecosystems.

August 2026 Chrome Web Store Privacy Updates

In July 2026, Google announced four policy changes affecting every Chrome extension that handles user data, with enforcement starting August 1, 2026. If your extension was submitted or updated before August 2026, review your privacy policy and Developer Dashboard disclosures against these new rules before your next submission.

Stricter "strictly necessary" data collection standard

The Limited Use policy now requires that any user data collected by an extension be strictly necessary to the extension's disclosed single purpose. The previous standard already called for minimum data collection, but the updated language tightens enforcement: reviewers now reject extensions that collect data broadly and justify it as "useful" rather than "necessary." If your privacy policy describes data collection with open-ended language like "we may collect additional data to improve the service," replace it with a specific, permission-by-permission account of exactly what is collected and why each piece is required for the single purpose you declared.

Mandatory post-install disclosure of data practice changes

Extensions must now notify users of any changes to data practices after installation. Previously, updating the privacy policy and the Developer Dashboard was sufficient. Under the new rule, if an extension update adds a new permission, begins collecting a new data category, or changes how existing data is shared, the developer must prominently disclose the change to users -- not just update the policy document. The disclosure must be visible inside the extension itself (for example, a notification or a changelog prompt on the first run after the update), not buried in a policy revision.

AI safety circumvention ban

A new prohibited-products rule bars extensions designed to circumvent safety guardrails, usage restrictions, or other protective measures implemented by AI-powered services. Extensions that modify prompts, bypass rate limits, or remove content filters on AI platforms are now explicitly policy-violating regardless of what the privacy policy says. If your extension interacts with AI services, make sure its function respects the target service's usage restrictions and that your privacy policy does not describe behavior that would constitute circumvention.

What this means for your privacy policy

If your extension was published before August 2026, audit the policy against these three changes: (1) replace any open-ended data-collection language with strictly necessary, permission-specific disclosures; (2) add a mechanism inside the extension to notify users when data practices change in a future update; and (3) if the extension touches AI services, confirm that the policy does not describe guardrail-circumventing behavior. Then re-check that the Developer Dashboard's Data usage certification still matches the updated policy text.

Frequently Asked Questions