Permissions and privacy review
Chrome Extension Host Permissions Privacy Review Checklist
Review broad host permissions, sensitive Chrome APIs, privacy disclosures, and Chrome Web Store reviewer notes before publishing.
Run local ZIP scanPermission review preflight step
Scan permissions before you write the privacy explanation
The scanner cannot approve policy compliance, but it can surface broad host permissions, sensitive Chrome APIs, privacy-review reminders, and packaging context you should reconcile with your single-purpose and disclosure text.
Independent local static preflight only. This is not an official Chrome Web Store validation result.
Guide
What to check
Broad host permissions
Patterns such as <all_urls> and *://*/* may increase review scrutiny and user warning impact. Use narrower host patterns, optional permissions, or activeTab when they fit the extension purpose.
Sensitive APIs
Permissions such as tabs, cookies, history, debugger, identity, webRequest, and scripting should support the extension single purpose and should be explained clearly in user-facing copy.
Privacy disclosure reminder
The ZIP scanner cannot inspect Developer Dashboard privacy fields, so it provides reminders when permissions may involve user data, browsing activity, authentication, or host access.
Map every permission to current functionality
Permissions should match the extension's current single purpose, not possible future features. When broad host access is not required at install time, review optional permissions or activeTab-style flows before submission.
Practical notes
How to apply this before resubmission
Create a permission-to-feature map before resubmission
Broad permissions are not automatically wrong, but every requested scope should map to current user-facing functionality. Before resubmitting, list each Chrome API permission and host pattern, explain why it is needed now, and decide whether it can be narrowed, made optional, or triggered only after a user action. This manual map is also useful when completing Chrome Web Store privacy and permission justification fields.
- •Map each permission to one current feature.
- •Remove future-proof permissions that are not used.
- •Prefer narrower host patterns where the feature allows it.
Treat privacy review as a product explanation task
The scanner can detect permission and host-access signals, but it cannot fill out your Developer Dashboard fields. Your public listing and privacy answers should explain what data the extension handles, why that access is required, and how the behavior supports the extension’s single purpose. Avoid vague statements that do not match the manifest permissions.
- •Use plain-language feature explanations.
- •Keep privacy claims aligned with actual extension behavior.
- •Review analytics, remote APIs, and third-party SDKs separately from manifest permissions.
Start with a permission-to-user-action table
Broad host permissions are easiest to justify when every pattern maps to a visible user action. Before submission, list the feature, the URL pattern it needs, when the extension accesses the page, and what data is read or changed. If the table has vague rows such as future feature or convenience, narrow the permission or move it to an optional permission flow.
- •Map <all_urls> and wildcard hosts to specific product behavior.
- •Prefer optional permissions when access is not needed at install time.
- •Use activeTab where temporary user-triggered access is enough.
Align dashboard answers with the shipped package
Privacy review is not only a policy copywriting exercise. The Developer Dashboard answers, extension listing, privacy policy, and shipped permissions should describe the same product behavior. If the package requests tabs, scripting, storage, identity, host permissions, or external connections, make sure the user-facing explanation covers why that access is needed and when it occurs.
- •Do not claim that no data is accessed if a permission enables page or account access.
- •Update privacy text when a new permission or SDK changes data handling.
- •Keep the explanation specific to the extension purpose, not a generic privacy template.
What the scanner can only remind you about
A ZIP scanner can identify declared permissions, host patterns, sensitive API names, and missing privacy reminders. It cannot read your Developer Dashboard answers, verify your production server behavior, or determine whether a reviewer will accept a business justification. Treat permission findings as prompts for a human review, not as automatic pass/fail policy decisions.
- •Use Medium permission findings as review tasks.
- •Keep evidence for why each sensitive permission is necessary.
- •After changing manifest permissions, upload a new package version and update related listing text.
Checklist
Action checklist
- □ Remove unused permissions from manifest.json.
- □ Narrow host permissions to required domains when possible.
- □ Use optional permissions for features users can enable later.
- □ Check whether activeTab can replace broad host access.
- □ Prepare a privacy policy if the extension handles user data.
- □ Make Developer Dashboard data-use disclosures match the extension behavior.
- □ Add reviewer notes for permissions that are not obvious from the UI.
Examples
Common cases this page helps with
Unnecessary <all_urls>
A screenshot helper may only need access to the current active tab after user action, not every website all the time.
Sensitive API without explanation
A history or cookies permission can be valid, but the listing and privacy disclosures should explain why the permission is necessary.
Broad scripting access
If scripting is only used on one product domain, narrow host permissions to that domain instead of all HTTP and HTTPS pages.
FAQ
Frequently asked questions
Are broad host permissions always wrong?
No. They may be valid for some extensions, but they increase review scrutiny and user warning impact. Use the narrowest scope that supports the single purpose.
Can the scanner inspect Developer Dashboard disclosures?
No. It only reads the ZIP. You must separately check privacy fields, listing copy, and reviewer notes in the Chrome Web Store dashboard.
What should I do when a sensitive permission is required?
Keep it, but document why it is necessary, make the user-facing behavior clear, and ensure privacy disclosures match actual data use.
Official sources
Sources used for this page
These links are listed so scanner findings and page guidance can be checked against Chrome's source documentation. This site remains an independent preflight tool.
Chrome Web Store: Permissions policy
Describes using only the narrowest permissions required for the extension's current functionality.
Chrome Extensions: Declare permissions
Explains permission declarations, optional permissions, and permission warning implications.
Chrome Extensions: Permission warning guidelines
Explains that some extension permissions trigger install-time or runtime warnings.
Chrome Extensions: activeTab permission
Documents activeTab as temporary user-invoked access that can sometimes replace broad host access.
Chrome Web Store: Fill out the privacy fields
Explains the Developer Dashboard privacy practices tab, single purpose, and permission justification fields.
Chrome Web Store Developer Program Policies
Sets the broader user trust, transparency, and user data handling policy baseline for Chrome Web Store items.
Related guides