Originally published on ExtensionBooster.
The Chrome Web Store policy update 2026 is not just for new submissions: Google announced it on July 1, 2026, and enforcement started August 1, 2026 for listings that are already live. If your extension reads URLs, page content or form input, a line in your privacy policy no longer covers you. Here are the four changes, the code pattern that satisfies the consent rule, and a checklist you can run in about half an hour.
The 4 changes at a glance
| Area | What it means now |
|---|---|
| Limited Use | Collect only data that is strictly necessary for your single, disclosed purpose |
| Disclosure | Every data collection must be shown in the extension UI, before it happens |
| Regulated goods | Real-money trading on predicted outcomes is banned |
| Prohibited products | Tools that get around AI services' safeguards are banned |
Out-of-compliance extensions found after the enforcement date can face enforcement up to removal from the store.
1. "Strictly necessary" kills URL-level telemetry
Limited Use rules out personalized ads, selling data to ad platforms or data brokers, and using it for credit or lending decisions. The scope is wide: browsing activity, page content, form data, credentials, even data you only keep on the device.
The most common offender is analytics. Compare these two events:
// Before: browsing data leaves the browser
track('page_view', {
url: location.href,
title: document.title,
referrer: document.referrer,
timeOnPage: elapsedMs,
});
// After: feature-level counts only
track('feature_used', {
feature: 'group_tabs',
tabCount: tabs.length,
durationMs: elapsedMs,
version: chrome.runtime.getManifest().version,
});
The URL, title and referrer are gone. The same idea applies if you use GA4: drop page_location and page_title.
Before keeping any field, ask three questions:
- Does a core feature break without it?
- Is it covered by your single purpose description?
- Would a less identifying form (a domain, a count) do the job?
2. Disclosure has to live inside the extension
A privacy policy or terms page alone does not count. Users must see what you collect inside the product, before collection starts, and take an explicit action to agree. Pre-checked boxes and footer notices fail.
A simple pattern: store a consent version and gate every data path on it.
// background.js (service worker)
const DATA_PRACTICES_VERSION = 3;
async function hasConsent() {
const { consentVersion } = await chrome.storage.local.get('consentVersion');
return consentVersion === DATA_PRACTICES_VERSION;
}
chrome.runtime.onInstalled.addListener(async ({ reason }) => {
if (reason !== 'install' && reason !== 'update') return;
if (!(await hasConsent())) {
const changed = reason === 'update';
chrome.tabs.create({ url: `consent.html?changed=${changed}` });
}
});
On consent.html, the Agree button saves consentVersion: 3 plus a consentAt timestamp; Decline saves 0, and the extension falls back to a reduced mode with no collection where that is possible. Keep the hardcoded version on the page in sync with the service worker constant, and call hasConsent() before any code that reads or sends user data.
The page itself should say what you collect, why, where it goes (on-device or a named server), and which third parties (analytics, AI providers) receive it. Finally, your Developer Dashboard privacy declarations must match the code, the consent screen and the privacy policy.
3. Re-prompt only when your data practices change
Bump DATA_PRACTICES_VERSION only for a real change in data handling, not on every release; repeated prompts tend to drive uninstalls. When you do re-prompt, open with what is new, keep features the user already agreed to working, and leave the new feature off until they accept.
4. Two new banned categories
- Prediction markets: extensions that place or facilitate real-money trades on predicted outcomes.
- AI guardrail circumvention: jailbreak injection, or evading another service's rate limits or usage caps.
AI extensions in general are fine. Chrome's I/O 2026 extensions recap says 17% of extensions created for the store in the past year use AI; those that call official APIs and respect provider limits are not affected.
The 30-minute audit
- [ ] Inventory every piece of user data the code touches (URLs, page content, form input, clipboard, cookies, identity, storage)
- [ ] Mark each one necessary or not, then remove or reduce the rest (domains instead of URLs, counts instead of lists)
- [ ] List every endpoint you call: analytics, error reporting, AI providers
- [ ] Confirm nothing goes to ad networks or data brokers
- [ ] Show an in-product disclosure before collection, with an explicit agree action
- [ ] Gate every collection path on stored consent
- [ ] Align the Privacy practices tab and privacy policy with the code (including the Limited Use statement if you use Google APIs)
- [ ] Check that your single purpose description covers every feature's data needs
- [ ] Confirm you are outside both banned categories
Key takeaways
- Enforcement began August 1, 2026 and applies to existing listings.
- Send feature events and counts, not URLs, titles or referrers.
- Consent must be in the UI, explicit and given before collection; local-only data still needs disclosure.
- Analytics are allowed when reasonably necessary to maintain or measure the extension.
- Re-prompt on real data changes only.
The original post has the full FAQ and links to Google's policy pages in its Chrome Web Store Limited Use and data disclosure compliance guide. If you are also working on listing trust and ratings, ExtensionBooster's guides for extension and app developers cover that side.
Has your extension been flagged or rejected under the new Limited Use or disclosure rules yet, and what did the reviewer point to?
Top comments (0)