[OUTDATED] Insiemi proprietari e attributo SameParty

Molte organizzazioni hanno siti correlati con nomi di dominio diversi, ad esempiobrandx.site e fly-brandx.site, oppure domini per paesi diversi, ad esempioexample.com, example.rs, example.co.uk e così via.

I browser stanno andando verso l'obsolescenza dei cookie di terze parti per migliorare la privacy sul web, ma siti come questi si basano spesso sui cookie per funzionalità che richiedono la gestione e l'accesso allo stato tra i domini (ad esempio l'accesso singolo e la gestione del consenso).

I set proprietari possono consentire di trattare come proprietari i nomi di dominio correlati di proprietà e gestiti dalla stessa entità in situazioni in cui i proprietari e le terze parti vengono trattati in modo diverso. I nomi di dominio all'interno di un insieme proprietario sono considerati proprietari e possono etichettare i cookie che devono essere impostati o inviati nel contesto proprietario. L'obiettivo è trovare un equilibrio tra l'impedire il monitoraggio tra siti da parte di terze parti e mantenere un percorso che non interrompa i casi d'uso validi.

La proposta relativa ai set proprietari è attualmente in fase di test. Continua a leggere per scoprire come funziona e come puoi provarla.

Qual è la differenza tra cookie proprietari e cookie di terze parti?

I cookie non sono intrinsecamente proprietari o di terze parti, ma dipendono dal contesto corrente in cui sono inclusi. Può essere in una richiesta nell'cookie o tramite document.cookie in JavaScript.

Se, ad esempio, video.site ha un cookie theme=dark, quando navighi su video.site e viene inviata una richiesta a video.site, si tratta di un contesto dello stesso sito e il cookie incluso è proprietario.

Tuttavia, se visiti my-blog.site, che incorpora un player iframe per video.site, quando la richiesta viene effettuata da my-blog.site a video.site si tratta di un contesto cross-site e il cookie theme è di terze parti.

Diagramma che mostra un cookie di video.site in due contesti. Il cookie è same-site quando il contesto di primo livello è anche video.site. Il cookie è cross-site quando il contesto di primo livello è mio-blog.site con video.site in un iframe.

L'inclusione dei cookie è determinata dall'attributo SameSite del cookie:

  • Il contesto su più siti con SameSite=Lax, Strict o None rende il cookie proprietario.
  • Il contesto cross-site con SameSite=None rende il cookie di terze parti.

Tuttavia, non è sempre così chiaro. Immagina che brandx.site sia un sito di prenotazione di viaggi e che utilizzi anche fly-brandx.site e drive-brandx.site per distinguere i voli e il noleggio auto. Durante la prenotazione di un viaggio, i visitatori si spostano tra questi siti per selezionare le diverse opzioni e si aspettano che il loro "carrello degli acquisti" di selezioni rimanga invariato su tutti i siti. brandx.site gestisce la sessione dell'utente con un cookie SameSite=None per consentirla in contesti cross-site. Il lato negativo è che ora il cookie non ha protezione contro la falsificazione delle richieste tra siti (CSRF). Se evil.site include una richiesta a brandx.site, includerà quel cookie.

Il cookie è cross-site, ma tutti i siti sono di proprietà e gestiti dalla stessa organizzazione. I visitatori comprendono anche che si tratta della stessa organizzazione e vogliono la stessa sessione, in altre parole un'identità condivisa.

Diagramma che mostra come un cookie possa essere comunque incluso in un contesto cross-site se i siti fanno parte dello stesso insieme proprietario, ma che verrebbe rifiutato per i contesti cross-site esterni all'insieme.

Norme relative agli insiemi proprietari

Gli insiemi proprietari propongono un metodo per definire esplicitamente questo rapporto su più siti di proprietà e gestiti dalla stessa parte. In questo modo, brandx.site potrà definire la sua relazione proprietaria con fly-brandx.site, drive-brandx.site e così via.

Il modello di privacy alla base delle varie proposte di Privacy Sandbox si basa sul concetto di suddivisione dell'identità per impedire il monitoraggio tra siti, tracciando un confine tra i siti che limita l'accesso a qualsiasi informazione che può essere utilizzata per identificare gli utenti.

Diagramma che mostra lo stato non partizionato in cui lo stesso cookie di terze parti è accessibile in più contesti cross-site, a differenza di un modello partizionato in cui ogni contesto di primo livello ha un'istanza separata del cookie cross-site che impedisce l'attività di collegamento tra questi siti.

Sebbene l'opzione predefinita sia la suddivisione per sito, che risolve molti casi d'uso proprietari, l'esempio brandx.site mostra che un proprietario può essere più grande di un solo sito.

Diagramma che mostra come la stessa istanza di un cookie per un insieme possa essere inclusa in contesti cross-site quando tutti i siti fanno parte dello stesso insieme.

Un aspetto importante della proposta relativa agli insiemi proprietari è garantire che le norme su tutti i browser impediscano abusi o usi impropri. Ad esempio, i set proprietari non devono consentire lo scambio di informazioni utente tra siti non correlati o il raggruppamento di siti non di proprietà della stessa entità. L'idea è assicurarsi che un insieme proprietario venga mappato a qualcosa che una persona considera proprietario e non venga utilizzato come mezzo per condividere l'identità tra parti diverse.

Un possibile modo per un sito di registrare un insieme proprietario potrebbe essere inviare il gruppo di domini proposto a un tracker pubblico (ad esempio un repository GitHub dedicato) insieme alle informazioni necessarie per soddisfare le norme del browser.

Una volta verificata l'affermazione dell'insieme proprietario in base alle norme, i browser possono recuperare gli elenchi di insiemi tramite una procedura di aggiornamento.

La prova dell'origine ha un criterio definito che non è definitivo, ma è probabile che i principi rimangano invariati:

  • I domini in un insieme proprietario devono essere di proprietà e gestiti dalla stessa organizzazione.
  • I domini devono essere riconoscibili dagli utenti come gruppo.
  • I domini devono condividere norme sulla privacy comuni.

Come definire un insieme proprietario

Dopo aver identificato i membri e il proprietario dell'insieme proprietario della tua organizzazione, un passaggio fondamentale sarà inviare l'insieme proposto per l'approvazione. La procedura esatta è ancora in discussione.

Per dichiarare un insieme proprietario, le risorse JSON statiche che elencano membri e proprietari devono essere ospitate in /.well-known/first-party-set a livello di primo livello di ogni dominio incluso.

Nell'esempio dell'insieme proprietario brandx, il dominio proprietario ospita quanto segue all'indirizzo https://brandx.site/.well-known/first-party-set:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

Ogni membro dell'insieme ospita anche una risorsa JSON statica che rimanda al proprietario dell'insieme. In https://fly-brandx.site/.well-known/first-party-set abbiamo:

{ "owner": "brandx.site" }

E alle ore https://drive-brandx.site/.well-known/first-party-set:

{ "owner": "brandx.site" }

Esistono alcuni vincoli per gli insiemi proprietari:

  • Un set può avere un solo proprietario.
  • Un membro può appartenere a un solo insieme, senza sovrapposizioni o mescolamenti.
  • L'elenco dei membri deve rimanere relativamente leggibile e non deve essere eccessivamente grande.

In che modo gli Insiemi proprietari influiscono sui cookie?

L'ingrediente corrispondente per i cookie è l'attributo SameParty proposto. La specifica di SameParty indica al browser di includere il cookie quando il relativo contesto fa parte dello stesso insieme proprietario del contesto di primo livello.

Ciò significa che se brandx.site imposta questo cookie:

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

Quando il visitatore è su fly-brandx.site e una richiesta viene inviata a brandx.site, il cookie session verrà incluso nella richiesta. Se un altro sito che non fa parte dell'insieme proprietario, ad esempiohotel.xyz, invia una richiesta a brandx.site, il cookie non verrà incluso.

Diagramma che mostra il cookie brandx.site consentito o bloccato nei contesti cross-site come descritto.

Finché SameParty non sarà ampiamente supportato, utilizza l'attributo SameSite per definire il comportamento di riserva per i cookie. Puoi considerare l'attributo SameParty come un'impostazione compresa tra SameSite=Lax e SameSite=None.

  • SameSite=Lax; SameParty espanderà la funzionalità Lax per includere i contesti proprietari, se supportati, ma tornerà alle limitazioni di Lax se non è così.
  • SameSite=None; SameParty limiterà la funzionalità None solo ai contesti proprietari, se supportati, ma in caso contrario tornerà alle autorizzazioni None più ampie.

Esistono alcuni requisiti aggiuntivi:

  • I cookie SameParty devono includere Secure.
  • I cookie SameParty non devono includere SameSite=Strict.

Secure è obbligatorio perché si tratta ancora di un cookie cross-site e devi mitigare questi rischi garantendo connessioni sicure (HTTPS). Analogamente, poiché si tratta di una relazione tra siti diversi, SameSite=Strict non è valido perché consente ancora una protezione CSRF strettamente basata sul sito all'interno di un insieme.

Quali casi d'uso sono adatti per gli insiemi proprietari?

Gli insiemi proprietari sono una buona soluzione per i casi in cui un'organizzazione ha bisogno di una forma di identità condivisa su diversi siti di primo livello. In questo caso, per identità condivisa si intende qualsiasi cosa, da una soluzione di accesso singolo completa alla semplice necessità di una preferenza condivisa tra i siti.

La tua organizzazione potrebbe avere domini di primo livello diversi per:

  • Domaini app: office.com,live.com, microsoft.com
  • Domini con nome del brand: amazon.com, audible.com / disney.com, pixar.com
  • Domini specifici per paese per attivare la localizzazione: google.co.in, google.co.uk
  • Domini di servizio con cui gli utenti non interagiscono mai direttamente, ma che forniscono servizi sui siti della stessa organizzazione: gstatic.com, githubassets.com, fbcdn.net
  • Domini sandbox con cui gli utenti non interagiscono mai direttamente, ma che esistono per motivi di sicurezza: googleusercontent.com, githubusercontent.com

Come puoi partecipare?

Se hai un insieme di siti che soddisfano i criteri sopra indicati, hai a disposizione diverse opzioni per partecipare. L'investimento più leggero è leggere e partecipare alla discussione sulle due proposte:

Durante la fase di test, puoi provare la funzionalità utilizzando il flag della riga di comando --use-first-party-set e fornendo un elenco di siti separati da virgole.

Puoi provare questa operazione sul sito dimostrativo all'indirizzo https://fps-member1.glitch.me/ dopo aver avviato Chrome con il seguente flag:

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

Questa opzione è utile se vuoi eseguire test nel tuo ambiente di sviluppo o se vuoi provare ad aggiungere l'attributo SameParty in un ambiente di produzione per vedere in che modo un insieme proprietario influirebbe sui cookie.

Se hai la larghezza di banda per la sperimentazione e il feedback, puoi anche registrarti per la prova dell'origine per gli insiemi proprietari e SameParty, disponibile in Chrome dalla versione 89 alla 93.

Come aggiornare i cookie per la prova dell'origine

Se partecipi alla prova dell'origine e stai testando l'attributo SameParty sui tuoi cookie, ecco due pattern da considerare.

Opzione 1

Innanzitutto, se hai cookie etichettati come SameSite=None, ma vuoi limitarli ai contesti proprietari, puoi aggiungere l'attributo SameParty. Nei browser in cui è attiva la prova dell'origine, il cookie non verrà inviato in contesti cross-site esterni all'insieme.

Tuttavia, per la maggior parte dei browser al di fuori della prova dell'origine, il cookie continuerà a essere inviato tra siti come di consueto. Consideralo un approccio di miglioramento progressivo.

Prima: set-cookie: cname=cval; SameSite=None; Secure

Dopo: set-cookie: cname=cval; SameSite=None; Secure; SameParty

Opzione 2

La seconda opzione richiede più lavoro, ma ti consente di separare completamente il trial di origine dalla funzionalità esistente e, in particolare, di testare la combinazione SameSite=Lax; SameParty.

Prima: set-cookie: cname=cval; SameSite=None; Secure

Dopo:

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

Quando controlli la presenza del cookie nelle richieste in arrivo, dovresti aspettarti di vedere il cookie cname-fps solo in una richiesta cross-site se i siti coinvolti sono nell'insieme e il browser è nella prova dell'origine. Considera questo approccio come un lanciamento simultaneo di una funzionalità aggiornata prima di disattivare la versione precedente.

Perché potresti non aver bisogno di un insieme proprietario?

Per la maggior parte dei siti, il confine del sito è un luogo accettabile per tracciare la partizione o il confine della privacy. Questo è l'approccio proposto con CHIPS (Cookies Having Independent Partitioned State), che offrirebbe ai siti un percorso di attivazione tramite l'attributo Partitioned per continuare a disporre di risorse, API e servizi di embedding tra siti critici, impedendo al contempo la fuga di informazioni di identificazione tra i siti.

Ecco altri aspetti da tenere in considerazione che indicano che il tuo sito potrebbe essere in regola senza bisogno di un set:

  • L'hosting avviene su origini diverse, non su siti diversi. Nell'esempio precedente, se brandx.site avesse fly.brandx.site e drive.brandx.site, si tratterebbe di sottodomini diversi all'interno dello stesso sito. I cookie possono utilizzareSameSite=Lax e non è necessario impostarli.
  • Fornisci incorporamenti di terze parti ad altri siti. Nell'introduzione, l'esempio di un video di video.site incorporato su my-blog.site è un chiaro elemento di terze parti. I siti sono gestiti da organizzazioni diverse e gli utenti li vedono come entità distinte. Questi due siti non devono essere inclusi nello stesso set.
  • Fornisci servizi di accesso social di terze parti. Gli identity provider che utilizzano OAuth o OpenID Connect spesso si basano su cookie di terze parti per un'esperienza di accesso più fluida per gli utenti. Si tratta di un caso d'uso valido, ma non è adatto per gli insiemi proprietari in quanto esiste una chiara differenza nelle organizzazioni. Le prime proposte come WebID stanno esplorando i modi per abilitare questi casi d'uso.