Ingen i den här kategorin publicerar det här inlägget. Jag har letat. Så här är det: varje behörighet Second Bookmark Bar ber Chrome om, varför den finns, och vad jag tekniskt sett skulle kunna göra med den som jag medvetet inte gör. Om du utvärderar om du ska installera ett bokmärkestillägg — det här eller någon annans — är den första halvan användbar oavsett vilket du väljer.
Hur du granskar vilket bokmärkestillägg som helst, inte bara det här
Innan detaljerna, den generella metoden, för den gäller för varje tillägg du någonsin kommer överväga att installera:
- Läs behörighetslistan på Chrome Web Store-listningssidan, inte bara installationsprompten — listningen förklarar vanligtvis vad var och en är till för på klarare språk, och du kan läsa den innan du binder dig till något.
- “Läs och ändra all din data på webbplatser” (
host_permissions-varningen för bred<all_urls>-åtkomst) är den att faktiskt uppmärksamma. Den betyder att tilläggets kod kan köras på varje sida du besöker. En smal värdbehörighet avgränsad till en specifik domän — tilläggets egen backend, säg — är ett mycket annorlunda påstående än obegränsad åtkomst till varje sida du surfar till. - En
bookmarks-behörighet ger läs-/skrivåtkomst till hela ditt bokmärkesträd. Det är i sig brett — det finns inget sätt att be Chrome om “bara vissa bokmärken” — så den ärliga frågan är inte om behörigheten är bred, det är vad tillägget gör med den åtkomsten när den väl beviljats. - Sedan Manifest V3 är “ingen fjärrkod” nästan universellt — tillägg kan inte längre hämta och köra godtycklig JavaScript från en server vid körning, vilket stänger av en kategori av tyst-omfångskrypning-efter-installation som brukade vara en riktig risk under Manifest V2. Det är värt att kontrollera att ett tillägg faktiskt levereras som Manifest V3, och de flesta ansedda gör det numera; Chrome har fasat ut V2-stöd butiksomfattande.
- En integritetspolicy som specifikt namnger vad som samlas in spelar större roll än en som bara existerar. “Vi kan samla in information för att förbättra våra tjänster” är standardtext. En policy som säger exakt vad som lämnar din enhet, och under vilket villkor, är den värd att lita på.
Second Bookmark Bars faktiska manifest
Här är behörighetsblocket från det riktiga manifest.json, inte en omskrivning:
"permissions": [
"activeTab",
"bookmarks",
"storage",
"favicon",
"identity",
"alarms"
],
"optional_permissions": [
"tabGroups"
],
"host_permissions": [
"https://ughpzmmhthrcnwtpfkzr.supabase.co/*"
]Varje post, vad den är till för:
| Behörighet | Vad den ger | Vad den faktiskt används till |
|---|---|---|
bookmarks | Läs och skriv ditt Chrome-bokmärkesträd | Hela produkten. Varje mapp, plats, sortering, dedupe och återställningsåtgärd är ett bokmärkes-API-anrop. Det finns ingen version av det här tillägget som fungerar utan den. |
storage | Lokal och synkad tilläggslagring | Inställningar, mappplatskonfiguration, adaptiva regler, sparade-sida-minnesrankningar, återställningspunktsögonblicksbilder. Inget här är din surfhistorik — det är tilläggets egen konfiguration och säkerhetskopior. |
activeTab | Tillfällig åtkomst till aktuell flik, bara efter att du interagerar med tilläggets gränssnitt | Driver det väljarstyrda sparflödet och snabbsparakommandot — hämtar aktuell sidas URL, titel och miniatyr när du faktiskt utlöser ett sparande, inte passivt i bakgrunden. |
favicon | Chromes inbyggda favicon-API | Renderar sidikoner bredvid bokmärken och mappar så att fältet läses visuellt istället för som ren text, utan att tillägget behöver hämta och cacha ikoner från tredjepartsservrar själv. |
alarms | Schemalägg bakgrundstimers i service workern | Tre ärliga användningar: pollning för ett molnsynkroniseringsförsök med fast intervall, kontroll under ett Stripe-kassaflöde så att gränssnittet uppdateras när betalningen slutförts, och periodisk städning av utgångna autentiseringstoken (var sjätte timme). Alla är molnsynkroniseringsrelaterade; ingen av dem körs om du aldrig slår på molnsynkronisering. |
identity | Chromes inbyggda OAuth-hjälpare (launchWebAuthFlow) | Google-inloggningsflödet för molnsynkronisering, och inget annat. Den här behörigheten låter inte tillägget läsa ditt Google-konto allmänt — den är avgränsad till själva inloggningshandslaget. |
tabGroups (valfri) | Skapa och märka Chrome-flikgrupper | Begärs inte vid installation. Chrome frågar om den bara om du använder den specifika “öppna den här mappen som en flikgrupp”-åtgärden — jag skulle hellre be om den exakt en gång, i stunden den behövs, än begära den i förväg för en funktion de flesta inte använder varje dag. |
Värdbehörighet: ughpzmmhthrcnwtpfkzr.supabase.co | Nätverksåtkomst till exakt en domän | Den Supabase-hostade backenden för molnsynkronisering och konto-/faktureringsstatus. Inte <all_urls>. Inte “alla webbplatser”. En specifik domän, och trafik går bara dit om du loggat in för molnsynkronisering. |
Det är hela permissions- och host_permissions-listan. Ingen analys-SDK, inget annonsnätverk, ingen bred <all_urls>-värdbehörighet för godtycklig nätverksåtkomst — manifestets enda värdbehörighet är avgränsad till exakt sin egen backend, samma Supabase-projekt molnsynkronisering är beroende av.
Två saker värda att namnge uttryckligen, för de är verkliga och poängen med det här inlägget är att inte utelämna något:
Själva innehållsskriptet. Manifestet deklarerar också ett innehållsskript som körs på varje http://- och https://-sida (document_start), vilket är vad som faktiskt utlöser Chromes installationsvarning “Läs och ändra all din data på webbplatserna du besöker” — inte Supabase-värdbehörigheten. Den varningen är korrekt: skriptet är vad som ritar fältet och sökgränssnittet direkt inuti varje sida du besöker. Vad det gör med den åtkomsten är smalt — rendera gränssnittet, och läsa de specifika sidelementen som behövs för att bygga bokmärket du ber det skapa (till exempel en videos titel, kanalnamn, längd och uppspelningsposition när du drar den till fältet) — men själva åtkomsten är bred, och det ärliga svaret på “varför behöver det här varje webbplats” är den varningen, inte en kringgåendemetod.
Miniatyrer för icke-YouTube-videomappar. YouTube-miniatyrer byggs enbart från video-ID:t, så de lämnar aldrig webbläsaren som en nätverksbegäran. För videomappsobjekt från andra sidor gör tillägget dock utgående förfrågningar: det tar en kort lista med miniatyrbild-URL-kandidater som redan finns på sidan du sparade från, och hämtar var och en (bara bildbytes, credentials: 'omit') för att bekräfta vilken som faktiskt löser sig till en bild innan den används som kortets miniatyr. De förfrågningarna går till vilken domän som helst som hostade sidan — inte till Second Bookmark Bars egen backend — så de dyker inte upp i manifestets värdbehörighetslista, men de är en andra riktig nätverksväg utöver Supabase-vägen, och det vore missvisande att beskriva det här tillägget som att bara någonsin prata med en värd.
Vad jag tekniskt sett skulle kunna göra som jag inte gör
Att vara ärlig om taket för de här behörigheterna spelar större roll än att beskriva golvet. Med bookmarks och storage skulle jag tekniskt sett kunna bygga en version av det här tillägget som tyst laddar upp hela ditt bokmärkesträd till en server vid installation. Det gör jag inte: Supabase-värdbehörigheten aktiveras bara efter att du uttryckligen loggat in för en betald molnfunktion, och utanför det är de enda utgående förfrågningarna miniatyrverifieringshämtningarna beskrivna ovan, som inte bär någon bokmärkes- eller kontodata — bara en kontroll av om en given bild-URL löser sig. Med activeTab skulle jag teoretiskt kunna logga varje sida du besöker — förutom att behörigheten är avgränsad så att tillägget bara ser en flik när du aktivt anropar det, inte vid varje navigering. Det finns ingen lyssnare kopplad för att passivt registrera surfning. Och med innehållsskriptet som körs på varje sida skulle jag teoretiskt kunna läsa vad som helst på den — förutom att koden som gör det inte är dold, det är samma content.js som levereras i Chrome Web Store-paketet, och den agerar bara när du interagerar med fältet eller drar något till det.
Det finns också en automatiserad rapport tillägget kan skicka även om du aldrig loggat in: om det upptäcker att dess egen licens- eller installationsintegritetsdata har manipulerats skickar det en enda anonym varning (bara en händelsetyp och allvarlighetsgrad, ingen bokmärkes- eller surfdata) till samma Supabase-backend, för att fånga missbruk av den betalda nivån. Den körs inte under normal användning.
Molnsynkronisering: det uttryckliga undantaget
Allt ovan är lokalt som standard — bokmärkesdata och inställningar lever i Chromes egen bokmärkeslagring och Chromes tilläggslagring på din enhet. Molnsynkronisering är det enda medvetna undantaget, och det är opt-in: det kräver inloggning med Google, och det kräver en betald prenumeration. När den är på synkroniseras dina bokmärkesrötter, tilläggsinställningar och delade utrymmen till Supabase-backenden med kortlivade sessionstoken med automatisk förnyelse, hastighetsbegränsning och tokenversionering — inte en långlivad statisk nyckel som ligger i lagring.
Synkriktningen spelar också roll: som standard är tillägget lokal-först. Molnläsningar sker bara när du uttryckligen utlöser dem; skrivningar pushar upp dina ändringar automatiskt så att din data säkerhetskopieras, men inget hämtas ner från molnet tyst i bakgrunden och skriver om vad som finns på din enhet. Om en prenumeration upphör behåller du skrivskyddad åtkomst under en respitperiod, och lokal export fungerar alltid oavsett prenumerationsstatus — att molnsynkronisering försvinner betyder inte att dina bokmärken försvinner.
Avinstallationstestet
Testet jag skulle tillämpa på vilket tillägg som helst med bookmarks-åtkomst: vad blir kvar efter att du tar bort det? Här är svaret allt — för tillägget skapade aldrig en parallell, egen datalagring från början. Det läser och skriver vanliga Chrome-bokmärken, samma träd Chrome självt hanterar. Avinstallera tillägget och dina bokmärken finns fortfarande där, fortfarande organiserade i samma mappar, fortfarande exporterbara från chrome://bookmarks som vilket annat bokmärke som helst. Inget med att ta bort tillägget rör den underliggande datan, för den underliggande datan var aldrig något annat än Chromes egen. Det här — tillsammans med den kortare versionen av synk-och-avinstallations-frågan — täcks också i sidans vanliga frågor, om du vill ha snabbreferensversionen.
Om du vill ha återställnings- och exportmekaniken som backar upp det påståendet i mer detalj, är det ett eget inlägg; om du väger om molnsynkronisering specifikt är värt att betala för, täcker free-vs-Pro-genomgången det separat. Integritetspolicyn har den juridiska-språk-versionen av allt ovan — det här inlägget är det vanliga-språket-versionen, och jag skulle hellre att du läser det här först.