Är Vanilla CookieConsent GDPR-compliant?
Vanilla CookieConsent är ett JavaScript-bibliotek som kan användas för att bygga en cookie-dialog. Det är ett exempel på en gratis open source-lösning som kan vara en bra teknisk byggsten för webbplatser som vill bygga och förvalta sin egen lösning för cookies och samtycke.
Men ett bibliotek är inte samma sak som en komplett samtyckeslösning.
Frågan är därför inte om Vanilla CookieConsent kan användas på en webbplats. Det kan det. Frågan är om biblioteket i sig räcker för hela arbetet med information, samtycke, dokumentation och uppföljning.
Ett bibliotek löser inte hela samtyckeshanteringen
Ett cookie-bibliotek kan hjälpa till med den del av samtyckesflödet som besökaren möter i webbläsaren. Det kan till exempel handla om att visa en cookie-dialog, spara besökarens val lokalt och ge utvecklare tekniska möjligheter att reagera på valet.
Det är en viktig del av en samtyckeslösning. Men det löser inte automatiskt det som behöver finnas runt dialogen.
Webbplatsägaren behöver fortfarande ha kontroll över vilken information som visas, hur samtycke dokumenteras, hur cookielistan hålls uppdaterad och hur lösningen följs upp när webbplatsen förändras.
Cookie-regler och GDPR löser olika delar
Reglerna om cookies och elektronisk kommunikation styr när webbplatsen får sätta cookies. Nödvändiga cookies kan normalt sättas utan samtycke, men webbplatsägaren ska informera besökaren om att de sätts. För cookies som inte är nödvändiga ska webbplatsen invänta besökarens samtycke.
GDPR blir relevant när användningen av cookies eller tillhörande script innebär behandling av personuppgifter. När samtycke används behöver webbplatsägaren också kunna dokumentera och visa samtycket i efterhand.
Bevisbart samtycke behöver lösas utanför ett lokalt val
När samtycke används behöver webbplatsägaren kunna visa att samtycke har lämnats.
Ett värde i besökarens webbläsare kan användas för att komma ihåg valet eller koppla besöket till en samtyckeslogg. Men om själva samtycket bara finns lokalt i webbläsaren har webbplatsägaren ingen egen dokumentation att visa i efterhand.
För att samtycke ska kunna visas i efterhand behöver det dokumenteras på ett sätt som webbplatsägaren kan följa upp. Det innebär ofta att samtycket behöver kopplas till en serverbaserad logg eller annan dokumentationslösning.
Att bygga en egen samtyckeslogg är inte bara en fråga om att spara en rad i en databas. Loggen behöver fungera utan att göra cookie-dialogen långsam, klara trafiktoppar, ha god tillgänglighet och lagra samtycken på ett sätt som går att följa upp i efterhand.
Om den delen inte ingår i lösningen behöver den byggas, driftas och förvaltas separat.
Det är en av de viktigaste skillnaderna mellan en cookie-dialog och en komplett samtyckeslösning.
Cookielistan behöver hållas aktuell
En cookielista behöver spegla de cookies som webbplatsen faktiskt använder.
Ett JavaScript-bibliotek för cookie-dialogen håller inte automatiskt reda på vilka cookies som sätts på hela webbplatsen. Nya cookies kan tillkomma när webbplatsen förändras, till exempel genom nya formulär, inbäddade tjänster, kampanjer, plugins, analysverktyg eller marknadsföringstaggar.
Det behöver därför finnas en rutin för att upptäcka nya cookies, granska dem och uppdatera informationen till besökaren.
Utan en sådan rutin kan dialogen finnas på plats, samtidigt som informationen i cookielistan blir inaktuell. Det gör det svårare för besökaren att förstå vad valet faktiskt gäller.
Valet behöver vara tydligt och enkelt att ändra
En cookie-dialog ska hjälpa besökaren att göra ett medvetet val.
Det betyder att informationen behöver vara begriplig, att alternativen behöver vara tydliga och att det ska vara enkelt att förstå vad som händer om besökaren accepterar, nekar eller gör mer detaljerade inställningar.
Besökaren behöver också kunna ändra eller ta tillbaka sitt samtycke. Om den delen inte ingår i lösningen behöver den hanteras separat, till exempel genom en tydlig länk till cookieinställningar.
Det handlar inte bara om juridik. Det handlar också om förtroende, användarupplevelse och respekt för besökarens val.
Google Consent Mode behöver hanteras där det används
Om webbplatsen använder Google Analytics, Google Ads eller Google Tag Manager behöver besökarens val ofta skickas vidare som samtyckessignaler till Google.
Det är inte samma sak som att bara visa en cookie-dialog.
Om Google Consent Mode inte hanteras av cookielösningen behöver kopplingen mellan besökarens val och Googles samtyckessignaler byggas, testas och förvaltas separat.
Det kan fungera, men det blir ytterligare en del som webbplatsägaren behöver ta ansvar för.
Förvaltningen blir ert ansvar
Vanilla CookieConsent är flexibelt eftersom det är ett fristående JavaScript-bibliotek. Det gör att det kan användas i många olika typer av webbplatser och tekniska miljöer.
Samtidigt behöver det vara tydligt vem som äger helheten runt biblioteket.
Det handlar inte bara om att få dialogen att visas. Någon behöver också förvalta information, cookielista, samtyckesdokumentation, uppföljning, återkallelse och kopplingar till andra system.
För en organisation med rätt teknisk kompetens och tydliga rutiner kan det vara ett rimligt val. Men då är det viktigt att se Vanilla CookieConsent som en byggsten, inte som hela lösningen.
När kan Vanilla CookieConsent vara ett rimligt val?
Vanilla CookieConsent kan vara ett rimligt val om ni vill bygga och förvalta samtyckeslösningen själva.
För enklare webbplatser, eller för organisationer med teknisk kompetens och tydliga rutiner, kan ett fristående bibliotek vara en praktisk väg. Det viktiga är att ni också har kontroll över det som behöver hanteras runt biblioteket.
Ni behöver då själva säkerställa att:
- samtycke kan dokumenteras och visas i efterhand
- cookielistan hålls uppdaterad
- informationen till besökaren är korrekt och begriplig
- Google Consent Mode hanteras där det behövs
- besökaren kan ändra eller ta tillbaka sitt val
- lösningen följs upp när webbplatsen förändras
Sammanfattning
Vanilla CookieConsent kan vara en bra teknisk byggsten för att bygga en cookie-dialog.
Men ett JavaScript-bibliotek är inte automatiskt en komplett samtyckeslösning.
De viktigaste frågorna är vad som händer runt själva dialogen:
- Hur dokumenteras samtycket?
- Hur kan webbplatsägaren visa samtycket i efterhand?
- Hur hålls cookielistan uppdaterad?
- Hur upptäcks nya cookies när webbplatsen förändras?
- Hur hanteras Google Consent Mode där det behövs?
- Hur enkelt är det för besökaren att förstå, ändra eller ta tillbaka sitt val?
- Vem ansvarar för förvaltning och uppföljning?
Om ni har svar på de frågorna kan Vanilla CookieConsent vara en del av en egen lösning. Om de delarna saknas löser biblioteket främst den synliga dialogen — inte hela samtyckeshanteringen.
Mer om gratisverktyg och samtycke
Behöver ni hjälp att se över er cookie-banner?
CookieTractor hjälper er att hantera cookie-dialog, samtycke, cookielista, dokumentation och uppföljning. Om ni är osäkra på om er nuvarande lösning räcker kan vi hjälpa er att gå igenom hur cookies, samtycke och script fungerar på er webbplats.
Kontakta oss gärna på info@cookietractor.se.