Google Chrome SameSite-etikettändringar google-chrome-samesite-labelling-changes
Attributet SameSite talar om för webbläsare när och hur cookies ska aktiveras i första och tredje parts scenarier. Attributet SameSite kan ha ett av tre värden: strict
, lax
eller none
. Chrome, Firefox, Edge, Safari och Opera har stött strict
och lax
sedan november 2017, medan none
introducerades 2018. Vissa äldre webbläsare stöder dock inte den här inställningen.
I februari 2020 släppte Google Chrome 80 och ändrade standardinställningen från none
till lax
när en cookie inte har något angivet värde för attributet SameSite. Den här inställningen förhindrar att en cookie används i en tredjepartskontext, som också kallas för"cross-site". Alla efterföljande cookies från tredje part måste anges till SameSite=none
och märkas som säkra.
Cookies utan ett angivet SameSite-attributvärde blir som standard lax
.
Mer information om samma webbplatsattribut finns i cookie-standarddokumentet.
Attributvärden för SameSite
strict
lax
none
none
standardinställningen för SameSite för cookies, så om du använder den här inställningen fungerar en cookie på det sätt den traditionellt har fungerat. Google kräver dock att alla cookies med den här inställningen nu anger flaggan secure, vilket innebär att cookien bara skapas och skickas med begäranden via HTTPS. Alla cookies mellan webbplatser utan den säkra flaggan kommer att avvisas av Google.Vad ni behöver veta som Adobe Experience Cloud-kund
Inga JavaScript-uppdateringar krävs
Adobe-produkter har redan släppt uppdateringar på serversidan för att ange cookies från tredje part med lämpliga attribut. Våra kunder behöver inte uppdatera JavaScript-biblioteket.
Kontrollera att slutpunkter från tredje part använder HTTPS
Alla kunder bör bekräfta att deras JavaScript-konfiguration använder HTTPS för sina samtal till Adobe-tjänster. Target, Audience Manager och Experience Cloud Identity Service (ECID) dirigerar om HTTP-anrop från tredje part till sina respektive HTTPS-slutpunkter, vilket kan öka fördröjningen. Det innebär att du inte behöver ändra konfigurationen. Analyskunder bör uppdatera sina implementeringar så att enbart HTTPS används, eftersom omdirigeringar som är specifika för Analytics kan orsaka dataförlust.
Korrekt märkta cookies bör samla in data som avsett
Så länge cookies är korrekt märkta kommer webbläsarna inte att vidta några åtgärder för att blockera dem. Konsumenterna kan välja att blockera vissa typer av cookies, men för närvarande verkar detta bara vara en anmälningsinställning.
Befintliga cookies från tredje part utan de uppdaterade etiketterna ignoreras
Cookies från tredje part som skapades innan Chrome 80 började använda inställningarna för SameSite=none
och säkra flaggor ignoreras av Chrome 80 om dessa flaggor inte finns.
Många av de befintliga cookies från tredje part från Adobe har inte dessa flaggor och måste uppdateras av Edge-servrar innan användare uppgraderar till Chrome 80, annars går dessa cookies förlorade. Edge-servrarna uppdateras automatiskt när användare besöker en webbplats där cookien används.
De flesta Adobe-produkter har redan rätt flaggor för cookies. Undantaget är analysimplementationer som använder datainsamling från tredje part och inte använder ECID. Kunderna kan uppleva en liten tillfällig ökning av antalet nya besökare som annars skulle ha varit återkommande besökare.
Möjlig minskning av cookie-matchning för mål- och marknadspartners (endast Audience Manager)
Adobe har kontroll över uppdateringen av cookies, men Adobe kan inte tvinga sina partner att göra nödvändiga ändringar. Cookie-matchning kan minska för Audience Manager-kunder som använder målpartners eller marknadspartners som inte har gjort dessa uppdateringar.
Analysvänlig cookies från tredje part (endast analyser s_vi
cookies)
Vissa analysimplementeringar använder ett CNAME-alias för Analytics för att göra det möjligt att skapa cookien s_vi
i domänen för CNAME. Om CNAME finns i samma domän som din webbplats, kommer detta att anges som en cookie från första part. Om du däremot äger flera domäner och använder samma CNAME för datainsamling i alla dina domäner, kommer det att anges som en cookie från tredje part i dessa andra domäner.
När lax
har blivit den nya standardinställningen för SameSite i Chrome visas inte längre CNAME i andra domäner.
För att kunna hantera ändringen anger Analytics nu explicit värdet s_vi
-cookie till lax
för SameSite. Om du vill använda denna cookie i en användarvänlig tredjepartskontext anger du värdet för SameSite till none
, vilket även innebär att du alltid måste använda HTTPS. Kontakta kundtjänst om du vill ändra värdet för SameSite för dina säkra CNAME.
Cookies för Adobe standardbesökare
Endast vanliga cookies för besökarstandard listas i tabellen nedan. Om du vill ha fler cookie-konfigurationer läser du produktspecifik dokumentation eller kontaktar din Adobe-representant.
ECID
lax
inställninglax
inställninglax
Audience Manager
none
none
Analytics
- Första part på serversidan om
CNAME
används - Tredje part om du använder 2o7.net eller omtrdc.net
lax
om förstapartsleverantörnone
om tredje part
Kunder kan redigera inställningar via kundtjänst för förstahandsdomäner
none
- och HTTPS-begäran användslax
Target
lax
inställningAd Cloud
none
Endast i Google Chrome- och Chromium-baserade webbläsarenone
- och HTTPS-begäran användslax
inställningnone
Endast i Google Chrome- och Chromium-baserade webbläsarenone
- och HTTPS-begäran användsBizible
none
Marketo Munchkin
lax
inställningcookies från tredje part från Adobe har angetts på serversidan.
Mer information finns i dokumentet om Target's Google Chrome SameSite policies.