reference
Permissions
Every permission SessionCourier requests, why it needs it, and what it deliberately does not ask for.
Install-time permissions
SessionCourier requests three permissions when you install it:
| Permission | Why it’s needed |
|---|---|
cookies | Read, create, edit and delete cookies — the core of the product |
storage | Persist your settings (like your language choice) locally |
activeTab | Know which site the current tab shows, to display its cookies |
That’s the minimum set a cookie manager can function with: access to the cookie store, a place to keep its own settings, and awareness of the current tab so the popup can open on the right site’s cookies.
Optional host access
Working with cookies for sites beyond the active tab requires host access, and SessionCourier requests it optionally and on demand: you grant access per host when you first need it, through the browser’s own permission prompt.
Every grant is revocable at any time — open chrome://extensions, pick SessionCourier, and remove hosts under the site-access settings. The extension keeps working for the hosts you’ve kept.
What is not requested
Just as telling is what the install prompt does not ask for:
- No
<all_urls>at install. SessionCourier never gets blanket access to every site; host access is opt-in, per host, revocable. - No
tabs,history, orwebRequest. It cannot enumerate your open tabs, read your browsing history, or observe your network traffic. - No remote code. Everything the extension runs ships in the reviewed store package; nothing is loaded from a server at runtime.
The same minimal-footprint approach backs the trust story: no network requests of its own, no telemetry without opt-in, and reproducible builds you can verify against the store package. Details on the main page.