Permission types
Extensions can request different types of permissions:API permissions
These grant access to browser APIs:storage- Store and retrieve data locallytabs- Access basic information about all tabsactiveTab- Access the currently active tab when you click the extensionbookmarks- Read and modify your bookmarkshistory- Access your browsing historycookies- Access cookies for websiteswebNavigation- Monitor and analyze web page navigationscripting- Inject scripts into web pagesnotifications- Display system notifications
Host permissions
These control which websites an extension can access:- Specific domain -
https://github.com/*(only GitHub) - Subdomain wildcard -
https://*.google.com/*(all Google subdomains) - All URLs -
<all_urls>orhttps://*/*(every website)
Install-time vs runtime permissions
Nook follows Chrome’s permission model:Install-time permissions
Permissions in the manifestpermissions and host_permissions arrays are granted automatically when you install the extension.
- Shows you all requested permissions
- Asks you to approve them
- Grants them all if you click “Add Extension”
This matches Chrome’s behavior where installing an extension means consenting to all its manifest permissions.
Runtime permissions
Permissions in the manifestoptional_permissions and optional_host_permissions arrays require explicit user action at runtime.
chrome.permissions.request() in response to a user action (like clicking a button) to get these permissions.
Permission prompts
During installation
When you install an extension, Nook displays:Permission list
Lists each permission with a human-readable description:
- “Store and retrieve data locally” for
storage - “Access the currently active tab when you click the extension” for
activeTab - “Read and modify your bookmarks” for
bookmarks
During runtime
When an extension callschrome.permissions.request(), Nook shows a similar dialog:
- What changed - New permissions being requested
- Why - The extension should explain why it needs them
- Grant or deny - You can approve or reject the request
Runtime permission requests must be triggered by a user action. Extensions cannot request permissions automatically in the background.
How permissions are granted
Automatic grants
When you install or load an extension, Nook automatically grants:- All manifest
permissions - All manifest
host_permissions - All manifest
optional_permissions(for backwards compatibility) - All manifest
optional_host_permissions(for backwards compatibility)
Explicit URL grants
For content scripts to inject and extension messaging to work, Nook grants extensions explicit URL access when you navigate to matching pages. This is required because WKWebExtensionController uses Safari’s per-URL permission model, where granted match patterns don’t automatically give URL access.Managing permissions after installation
View current permissions
To see what permissions an extension has:Revoke permissions
Currently, Nook does not support revoking individual permissions after installation. To limit an extension’s access:- Disable the extension - Prevents it from running
- Uninstall and reinstall - If the extension adds optional permissions support
Fine-grained permission management (revoking individual permissions) may be added in a future version.
Extension permission behavior
Background workers
Extension background workers (service workers or background pages) have access to:- All granted API permissions
- The ability to inject content scripts into pages matching host permissions
- Communication with content scripts via
chrome.runtimemessaging
Content scripts
Content scripts run in web pages and can:- Access the page DOM
- Communicate with the background worker via
chrome.runtime.sendMessage() - Use granted host permissions to make cross-origin requests (in MAIN world)
Popup pages
Extension popups have the same permissions as background workers:- All API permissions
- Ability to query tabs and windows
- Access to
chrome.storage,chrome.runtime, etc.
Permission security
Principle of least privilege
Only grant permissions that extensions actually need:- Question broad permissions - Does a calculator extension really need access to all websites?
- Check match patterns -
<all_urls>is usually unnecessary - Review API usage - Does it need
historyor justactiveTab?
Extension trust
Before installing an extension:- Check the source - Install from trusted developers or stores
- Read reviews - See what other users say
- Examine permissions - Ensure they make sense for the extension’s purpose
- Test in a separate profile - Use a test profile first if you’re unsure
Permission isolation
Extension permissions are granted globally but storage is isolated per profile:- Installing an extension in one profile makes it available in all profiles
- Permission grants apply across all profiles
- Extension storage (cookies, localStorage) is separate per profile
- You can’t grant permissions to an extension in one profile but not another
- You can use the same extension with different user accounts in different profiles
- Extension data doesn’t leak between profiles
Debugging permission issues
If an extension isn’t working:Content scripts not injecting
Content scripts not injecting
- Check that the extension has
host_permissionsmatching the page URL - Verify the extension is enabled in Settings → Extensions
- Look for permission errors in Web Inspector console
API calls failing
API calls failing
- Ensure the extension requested the necessary API permission
- Check that the permission appears in the extension’s granted permissions
- Look for
chrome.runtime.lastErrorin the console
Cross-origin requests blocked
Cross-origin requests blocked
- Verify the extension has
host_permissionsfor the target domain - Content scripts in ISOLATED world use extension origin (may cause CORS errors)
- Consider if the content script should run in MAIN world instead