Consent
Cookies, local storage och session storage: vad är skillnaden?
Cookies, local storage och session storage fungerar olika, men ingen är automatiskt undantagen från samtycke. Lär dig hur var och en fungerar, vilken du bör använda och hur du granskar dem i din samtyckesprocess.
Cookies, local storage och session storage: vad är skillnaden?
Cookies, local storage och session storage låter alla webbplatser komma ihåg information i besökarens webbläsare. De nämns ofta i samma andetag, och det är lätt att anta att de gör ungefär samma jobb. I praktiken beter de sig olika, de varar olika länge och väcker olika tekniska och integritetsmässiga frågor.
För webbplatsägare är skillnaden viktig även utanför utvecklingsteamet. Ett marknadsföringsverktyg kan lagra en annonsidentifierare i en cookie, en webbplats kan spara ett språkval i local storage, och ett kassaflöde kan spara tillfällig information i session storage. Lagringsmetoden påverkar hur webbplatsen fungerar, men den avgör inte automatiskt om samtycke krävs.
Vad betyder egentligen webbläsarlagring?
Webbläsarlagring är ett sätt för en webbplats att behålla information på en persons enhet. Utan den skulle många webbplatser glömma användbara uppgifter varje gång en sida laddas om eller besökaren går till en annan sida. Varukorgar, inloggade sessioner, sparade inställningar och vissa analysfunktioner kan alla vara beroende av information som lagras i eller läses från webbläsaren.
Det viktiga är inte bara om information lagras. Det är hur länge den finns kvar, var den är åtkomlig, om den skickas till en server automatiskt och varför webbplatsen använder den.
Vad är cookies och hur fungerar de?
En cookie är en liten datamängd som en webbplats kan be webbläsaren att lagra. När webbläsaren senare gör en förfrågan till en matchande webbadress kan den automatiskt skicka med cookien, beroende på webbläsarens inställningar och cookiens attribut.
Det automatiska utbytet gör cookies användbara för serverrelaterade uppgifter, som att upprätthålla inloggade sessioner. En server kan se att en serie förfrågningar tillhör samma inloggade session utan att användaren behöver logga in igen på varje sida.
Cookies kan vara sessionscookies, som i allmänhet varar under en surfsession, eller bestående cookies som har ett utgångsdatum eller en maximal livslängd. De kan också vara förstaparts- eller tredjepartscookies, beroende på förhållandet mellan webbplatsen som besöks och leverantören som sätter eller tar emot dem. Webbläsarens integritetsinställningar kan begränsa hur cookies fungerar, och vissa webbläsare återställer sessionscookies när sessioner återställs.
Cookiens säkerhetsattribut är bland annat Secure, som begränsar överföringen till säkra anslutningar, HttpOnly, som blockerar åtkomst via JavaScript, och SameSite, som hjälper till att begränsa förfrågningar mellan webbplatser. De bidrar till att skydda sessioner men tar inte bort alla risker.
En teknisk förklaring finns i MDN:s guide till HTTP-cookies.
Vad är local storage?
localStorage låter en webbplats spara nyckel–värde-data i besökarens webbläsare med hjälp av JavaScript. Till skillnad från cookies bifogar webbläsaren inte automatiskt dessa värden till varje HTTP-förfrågan. Om en applikation behöver skicka ett värde till en server måste dess kod göra det uttryckligen.
Local storage är normalt tillgängligt för sidor från samma origin, det vill säga samma protokoll, värd och port. Ett värde som lagrats av en origin är inte automatiskt tillgängligt för en helt annan webbplats. Skript som körs inom den originen kan dock läsa det, inklusive tredjepartsskript som har lagts in direkt på sidan.
Data som lagras i localStorage finns normalt kvar när webbläsarfliken eller fönstret stängs. Det har inget inbyggt utgångsdatum, även om användare kan rensa det och webbläsare i vissa fall kan ta bort det. I privat surfläge är lagringen i allmänhet tillfällig.
Vanliga användningsområden är att spara ett valt tema, komma ihåg en inställning i gränssnittet eller behålla icke-känslig applikationsstatus mellan besök. Det är ingen säker plats för hemligheter bara för att datan stannar i webbläsaren: JavaScript som körs på sidan kan oftast läsa den.
Vad är session storage?
sessionStorage använder ett liknande JavaScript-gränssnitt som local storage, men livslängden och räckvidden skiljer sig. Det lagrar information för en viss origin och en viss webbläsarflik eller surfkontext.
Informationen finns oftast kvar vid omladdning av sidor och navigering inom den fliken. När flikens sidsession tar slut rensas datan normalt. Om du öppnar en annan, oberoende flik får den inte bara samma pågående session storage. Det gör session storage användbart för tillfälliga framsteg i formulär, flerstegsflöden eller gränssnittsstatus som inte ska finnas kvar i det oändliga.
En detalj skapar ofta förvirring: session storage är inte samma sak som en sessionscookie. En sessionscookie är fortfarande en cookie och kan skickas till en server automatiskt. sessionStorage är ett lagringsområde i webbläsaren som nås via JavaScript, och dess data skickas inte automatiskt med i nätverksförfrågningar.
Du kan läsa mer i MDN:s dokumentation om Web Storage API.
Cookies, local storage och session storage: snabb jämförelse
| Egenskap | Cookies | Local storage | Session storage |
| --- | --- | --- | --- |
| Huvudsyfte | Komma ihåg små värden och stödja kommunikation mellan webbläsare och server | Behålla webbläsardata mellan besök | Behålla tillfällig data under en sidsession |
| Typisk livslängd | Tills sessionen tar slut eller ett inställt utgångsdatum | Tills den tas bort, rensas eller tvingas ut | Oftast tills flikens sidsession tar slut |
| Skickas automatiskt med HTTP-förfrågningar | Ja, för matchande förfrågningar när det tillåts | Nej | Nej |
| Åtkomlig via JavaScript | Oftast, om den inte är HttpOnly | Ja | Ja |
| Lagringens räckvidd | Styrs av domän, sökväg och andra attribut | Per origin | Per origin och flik/sidsession |
| Typiska exempel | Inloggningssession, samtycksval, analysidentifierare | Tema, sparade gränssnittsinställningar | Tillfälliga framsteg i formulär eller kassa |
| Automatiskt undantagen från reglerna om samtycke till cookies | Nej | Nej | Nej |
Vilken bör din webbplats använda?
För inloggningssessioner är en säker HttpOnly-cookie ofta ett bättre val än att lägga autentiseringstokens i local storage. Utvecklare måste ändå hantera risker som cross-site request forgery och cross-site scripting.
För en besökares tema eller visningsinställning kan local storage vara praktiskt, eftersom webbläsaren kan komma ihåg valet utan att skicka det till servern vid varje förfrågan. För tillfälliga framsteg i ett formulär eller ett flöde som oftast ska försvinna när fliken stängs kan session storage passa bättre.
Analys och marknadsföring är något annat. En annonsleverantör kan använda en cookie, local storage eller flera tekniker tillsammans för att känna igen en webbläsare eller mäta aktivitet. Att välja local storage i stället för cookies gör inte annonsspårning till en nödvändig webbplatsfunktion. Det underliggande syftet är fortfarande det som avgör.
Kräver local storage och session storage samtycke enligt GDPR?
I EU kommer reglerna om lagring på enheter i allmänhet från lagar som genomför ePrivacy-direktivet, och GDPR gäller dessutom för personuppgifter. I Storbritannien styr Privacy and Electronic Communications Regulations (PECR) många former av lagring på och åtkomst till enheter, och UK GDPR gäller när personuppgifter är inblandade.
Reglerna är bredare än traditionella HTTP-cookies. Brittiska Information Commissioner’s Office tar uttryckligen upp både local storage och session storage i sin vägledning om lagrings- och åtkomsttekniker.
Om samtycke behövs beror på tillämplig lag, syftet med lagringen eller åtkomsten och eventuella relevanta undantag. Lagring som är nödvändig för att tillhandahålla en tjänst som användaren har begärt kan omfattas av ett undantag. Vissa andra snäva undantag kan gälla i särskilda jurisdiktioner och omständigheter. Marknadsföring, beteendebaserad annonsering och liknande frivillig spårning kräver i allmänhet samtycke i EU och Storbritannien.
Att spara en tillfällig varukorgsidentifierare så att en kund kan slutföra sitt köp är till exempel något annat än att lagra en annonsidentifierare för att känna igen besökaren senare. Det första kan vara nödvändigt för att ge den shoppingupplevelse som efterfrågats. Det andra tjänar ett separat marknadsföringssyfte, oavsett om identifieraren finns i en cookie eller i local storage.
Därför räcker det inte alltid med cookieskanningar
Webbplatser kör ofta kod från analysleverantörer, annonsplattformar, chattwidgetar, videospelare och andra externa tjänster. Vissa skript använder cookies. Andra skriver till local storage, session storage eller till fler än en plats. Deras beteende kan också ändras beroende på om någon har loggat in, accepterat spårning eller slutfört en handling.
CookiePals efterlevnadsskanner för webbplatser är en bra startpunkt för att identifiera cookies och spårningstekniker på din webbplats. Kombinera den med kontroller av local storage och session storage när du undersöker specifika skript eller applikationsfunktioner. Utgå inte från att det räcker att identifiera cookies för att alla former av webbläsarlagring har gåtts igenom.
Så hanterar du webbläsarlagring i din samtyckesprocess
En praktisk samtyckesgranskning behöver inte bli ett enormt tekniskt projekt. Börja med de sidor och flöden som besökarna faktiskt använder: startsidan, landningssidor, registreringsflöden, kassan, kontoområdet och inbäddade verktyg. Gå sedan igenom följande kontroller:
- Identifiera vad som lagras. Gå igenom cookies, local storage, session storage och de skript som ansvarar för dem.
- Dokumentera syftet. Behövs informationen för en efterfrågad funktion, eller används den för analys, annonsering, personalisering eller något annat syfte?
- Kontrollera vilken samtyckesregel som gäller. Klassificera inte något som nödvändigt bara för att det är användbart för företaget.
- Testa samtyckesbeteendet. Bekräfta att frivillig lagring och spårning styrs på rätt sätt både före och efter att besökaren har gjort sitt val.
- Håll förklaringarna aktuella. Beskriv syften och leverantörer korrekt och granska dem när webbplatsen ändras.
En plattform för samtyckeshantering kan hjälpa till att koppla samtyckesval till cookiekontroller, bannerinställningar och loggar. För skript som använder andra lagringsmekanismer bör du kontrollera hur just den integrationen beter sig och om ytterligare konfiguration krävs.
Din cookiepolicy bör också vara begriplig för besökare utan teknisk bakgrund. I stället för att bara lista identifierare och livslängder bör du förklara varför teknikerna används, vad besökarna kan styra och var tredjepartstjänster är inblandade. Den övergripande integritetspolicyn bör också behandla relevant behandling av personuppgifter.
Sammanfattning: olika lagring, samma behov av transparens
Cookies, local storage och session storage löser olika tekniska problem. Cookies kan kommunicera automatiskt med servrar, local storage behåller webbläsardata mellan besök och session storage håller tillfällig data knuten till en sidsession. De här skillnaderna hjälper utvecklare att bygga bättre webbplatser, men de avgör inte i sig om du följer integritetsreglerna.
För webbplatsägare är den mest användbara frågan inte ”Använder vi cookies?” Den är ”Vilken information lagrar eller läser vi på besökarnas enheter, varför behöver vi den och speglar våra samtyckeskontroller det syftet?”
Börja med att granska din webbplats med CookiePals kostnadsfria efterlevnadsskanner och testa sedan den webbläsarlagring och de skript som är viktiga för dina besökare. En tydlig och korrekt inventering är grunden för en samtyckesupplevelse som människor kan förstå och lita på.
Var det här till hjälp?Tack för att du berättade.
