Nobody in this category publishes this post. I’ve looked. So here it is: every permission Second Bookmark Bar asks Chrome for, why it’s there, and what I could technically do with it that I deliberately don’t. If you’re evaluating whether to install a bookmark extension — this one or anyone else’s — the first half is useful regardless of which one you end up choosing.
One feature added since this was first published is worth naming here directly: Link check, which asks bookmarked sites whether they still answer — see that page for exactly what it does and doesn’t send.
How to audit any bookmark extension, not just this one
Before the specifics, the general method, because it applies to every extension you’ll ever consider installing:
- Read the permissions list on the Chrome Web Store listing page, not just the install prompt — the listing usually explains what each one is for in plainer language, and you can read it before committing to anything.
- “Read and change all your data on websites” (the
host_permissionswarning for broad<all_urls>access) is the one to actually pay attention to. It means the extension’s code can run on every page you visit. A narrow host permission scoped to one specific domain — the extension’s own backend, say — is a very different claim than unrestricted access to every site you browse. - A
bookmarkspermission grants read/write access to your entire bookmark tree. That’s inherently broad — there’s no way to ask Chrome for “just some bookmarks” — so the honest question isn’t whether the permission is broad, it’s what the extension does with that access once granted. - Since Manifest V3, “no remote code” is close to universal — extensions can no longer fetch and execute arbitrary JavaScript from a server at runtime, which closes off a category of quiet-scope-creep-after-install that used to be a real risk under Manifest V2. It’s worth checking an extension actually ships as Manifest V3, and most reputable ones now do; Chrome has been phasing out V2 support store-wide.
- A privacy policy that specifically names what’s collected matters more than one that just exists. “We may collect information to improve our services” is boilerplate. A policy that says exactly what leaves your device, and under what condition, is the one worth trusting.
Second Bookmark Bar’s actual manifest
Here’s the permissions block from the real manifest.json, not a paraphrase:
"permissions": [
"activeTab",
"bookmarks",
"storage",
"favicon",
"identity",
"alarms"
],
"optional_permissions": [
"tabGroups"
],
"host_permissions": [
"https://ughpzmmhthrcnwtpfkzr.supabase.co/*"
]Every entry, what it’s for:
| Permission | What it grants | What it’s actually used for |
|---|---|---|
bookmarks | Read and write your Chrome bookmark tree | The entire product. Every folder, slot, sort, dedupe, and rollback operation is a bookmarks API call. There’s no version of this extension that works without it. |
storage | Local and synced extension storage | Settings, folder-slot config, adaptive rules, saved-page memory ranks, restore-point snapshots. Nothing here is your browsing history — it’s the extension’s own configuration and backups. One short-lived exception: a temporary list of the address and title of each open web-page tab (up to 400, each removed when its tab closes), kept only so the Save all tabs panel can count tabs that have not finished loading. Chrome holds it in memory and clears it when the browser closes; it is never synced, never written to disk, and never sent to me. |
activeTab | Temporary access to the current tab, only after you interact with the extension’s UI | Powers the picker-first save flow and quick-save command — grabbing the current page’s URL, title, and thumbnail when you actually trigger a save, not passively in the background. |
favicon | Chrome’s built-in favicon API | Renders site icons next to bookmarks and folders so the bar reads visually instead of as plain text, without the extension having to fetch and cache icons from third-party servers itself. |
alarms | Schedule background timers in the service worker | Three honest uses: polling for a cloud-sync retry on a fixed interval, checking in during a Stripe checkout flow so the UI updates once payment completes, and a periodic cleanup of expired auth tokens (every six hours). All are cloud-sync-adjacent; none of them run if you never turn cloud sync on. |
identity | Chrome’s OAuth helper (launchWebAuthFlow) | The Google sign-in flow for cloud sync, and nothing else. This permission does not let the extension read your Google account data generally — it’s scoped to the sign-in handshake itself. |
tabGroups (optional) | Create and label Chrome tab groups | Not requested at install. Chrome prompts for it only if you use the specific “open this folder as a tab group” action — I’d rather ask for it exactly once, at the moment it’s needed, than request it up front for a feature most people won’t use every day. |
Host permission: ughpzmmhthrcnwtpfkzr.supabase.co | Network access to exactly one domain | The Supabase-hosted backend for cloud sync and account/billing state. Not <all_urls>. Not “all websites.” One specific domain, and traffic only goes there if you’ve signed in for cloud sync. |
That’s the whole permissions and host_permissions list. No analytics SDK, no ad network, no broad <all_urls> host permission for arbitrary network access — the manifest’s one host permission is scoped to exactly its own backend, the same Supabase project cloud sync depends on.
Two things worth naming explicitly, because they’re real and the point of this post is not to leave anything out:
The content script itself. The manifest also declares a content script that runs on every http:// and https:// page (document_start), which is what actually produces Chrome’s “Read and change all your data on the websites you visit” install warning — not the Supabase host permission. That warning is accurate: the script is what draws the bar and search UI directly inside every page you visit. What it does with that access is narrow — render the UI, and read the specific page elements needed to build the bookmark you ask it to create (for example, a video’s title, channel name, duration, and playback position when you drag it onto the bar) — but the access itself is broad, and the honest answer to “why does this need every website” is that warning, not a workaround.
Thumbnails for non-YouTube video folders. YouTube thumbnails are built from the video ID alone, so those never leave the browser as a network request. For video folder items from other sites, though, the extension does make outbound requests: it takes a short list of thumbnail-image URL candidates already present on the page you saved from, and fetches each one (image bytes only, credentials: 'omit') to confirm which one actually resolves to an image before using it as the card’s thumbnail. Those requests go to whatever domain hosted the page — not to Second Bookmark Bar’s own backend — so they don’t show up in the manifest’s host-permission list, but they are a second real network path beyond the Supabase one, and it would be inaccurate to describe this extension as only ever talking to one host.
What I could technically do that I don’t
Being honest about the ceiling of these permissions matters more than describing the floor. With bookmarks and storage, I could technically build a version of this extension that silently uploads your entire bookmark tree to a server on install. I don’t: the Supabase host permission only activates after you explicitly sign in for a paid cloud feature, and outside of that the only outbound requests are the thumbnail-verification fetches described above, which carry no bookmark or account data — just a check of whether a given image URL resolves. With activeTab, I could theoretically log every page you visit — except the permission is scoped so the extension only sees a tab when you actively invoke it, not on every navigation. There’s no listener wired up to passively record browsing. And with the content script running on every page, I could theoretically read anything on it — except the code that does isn’t hidden, it’s the same content.js shipped in the Chrome Web Store package, and it only acts when you interact with the bar or drag something onto it.
There’s also one automated report the extension can send even if you’ve never signed in: if it detects that its own license or install-integrity data has been tampered with, it sends a single anonymous alert (just an event type and severity, no bookmark or browsing data) to the same Supabase backend, to catch abuse of the paid tier. It doesn’t run during normal use.
Cloud sync: the explicit exception
Everything above is local by default — bookmark data and settings live in Chrome’s own bookmark storage and Chrome’s extension storage on your device. Cloud sync is the one deliberate exception, and it’s opt-in: it requires signing in with Google, and it requires a paid subscription. When it’s on, your bookmark roots, extension settings, and shared spaces sync to the Supabase backend using short-lived session tokens with automatic refresh, rate limiting, and token versioning — not a long-lived static key sitting in storage.
The sync direction matters too: by default the extension is local-first. Cloud reads only happen when you explicitly trigger them; writes push your changes up automatically so your data’s backed up, but nothing pulls down from the cloud silently in the background rewriting what’s on your device. If a subscription lapses, you keep read-only access during a grace period, and local export always works regardless of subscription state — cloud sync going away doesn’t mean your bookmarks go away.
The uninstall test
The test I’d apply to any extension with bookmarks access: what’s left after you remove it? Here, the answer is everything — because the extension never created a parallel, proprietary data store to begin with. It reads and writes standard Chrome bookmarks, the same tree Chrome itself manages. Uninstall the extension and your bookmarks are still there, still organized into the same folders, still exportable from chrome://bookmarks like any other bookmark. Nothing about removing the extension touches the underlying data, because the underlying data was never anything other than Chrome’s own. This — along with the shorter version of the sync-and-uninstall question — is also covered in the site FAQ, if you want the quick-reference version.
If you want the rollback and export mechanics that back that claim up in more detail, that’s its own post; if you’re weighing whether cloud sync specifically is worth paying for, the free-vs-Pro breakdown covers that separately. The privacy policy has the legal-language version of everything above — this post is the plain-language one, and I’d rather you read this one first.