🍕 feat(permissions): user-controlled per-site host access (v2.1.0)#7
Open
jjpaulino wants to merge 1 commit into
Open
🍕 feat(permissions): user-controlled per-site host access (v2.1.0)#7jjpaulino wants to merge 1 commit into
jjpaulino wants to merge 1 commit into
Conversation
Drops the broad `host_permissions: ["<all_urls>"]` install grant — the one that was triggering Chrome Web Store's "Broad Host Permissions" review delay — and replaces it with a per-site model the user controls at runtime. Changes - Manifest: `host_permissions: []`, `optional_host_permissions: ["<all_urls>"]`. The static content_scripts entry keeps its `<all_urls>` matcher as the upper bound; Chrome only auto-injects on origins the user has granted. - New `src/lib/permissions.ts` wrapping `chrome.permissions` with a clean bare-hostname API (request / remove / list / has) plus URL helpers. - Options page: new "Allowed sites" section at the top — list current granted hosts with a Revoke button, add new ones via a text input that triggers the native Chrome consent prompt, and a "Pending" strip that surfaces hostnames referenced by site mappings but not yet granted (with a one-click "Grant all" button). - Popup: detects the active tab's host and shows either "Allow Clay Slip on this site" (with reload after grant) or "Not a Clay page" + Revoke, depending on whether the host is already granted. - README and PRIVACY.md updated to describe the new permission model and per-permission justification table (required vs runtime-granted). - Version bumped to 2.1.0. Tests: 16 new unit tests for the permissions module; full suite stays green at 100/100. Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Chrome Web Store flagged our last upload with Broad Host Permissions:
We can't ship a hard-coded site list — Clay Slip needs to work on whatever Clay deployments the install owner happens to use. The fix is to drop the broad install grant entirely and let the user opt in per-site at runtime.
What
host_permissionsis now[]. Broad access lives inoptional_host_permissions: ["<all_urls>"], which is gated behind a Chrome consent prompt the user triggers themselves. The staticcontent_scripts.matcheskeeps<all_urls>as the upper bound, but Chrome only auto-injects on origins the user has granted — i.e. nothing on a fresh install.src/lib/permissions.ts(new): clean wrapper aroundchrome.permissionsthat talks bare hostnames (www.thecut.com) instead of origin patterns. Handles request / remove / list / has + helpers for popup/SW callers. 16 unit tests.Migration story for existing users
Existing v2.0.x installs already have
<all_urls>granted from when it was a required permission. Per Chrome's MV3 docs, when an extension update drops a required permission, Chrome keeps the previously-granted access in place (the user doesn't get re-prompted, and they don't lose anything).For new installs the flow is:
Why this should clear the review flag
The reviewer's two suggested alternatives are:
We're effectively combining both: the install-time permission set is minimal (no
host_permissions), and the user explicitly grants each origin via Chrome's own permission UI before any content script ever runs there. `optional_host_permissions` is the documented MV3 mechanism for exactly this pattern.Test plan
Files
Made with Cursor