[OUTDATED] Insiemi proprietari e attributo SameParty

Avviso: la proposta di Insiemi proprietari è stata aggiornata e questo articolo non è più aggiornato. Per informazioni aggiornate, consulta il spiegatore e le istruzioni di test.

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

I browser stanno passando a rendere obsoleti i cookie di terze parti per migliorare la privacy sul web, ma siti come questi spesso si affidano ai cookie per funzionalità che richiedono la gestione e l'accesso allo stato tra i domini (come il Single Sign-On e la gestione del consenso).

Gli insiemi proprietari possono consentire i nomi di dominio correlati di proprietà e gestiti dalla stessa entità di essere trattati come proprietari nelle situazioni in cui la prima parte e la terza parte vengono altrimenti trattate diversamente. I nomi di dominio all'interno di un insieme proprietario sono considerati della stessa parte e possono etichettare i cookie che si intende impostare o inviare nel contesto della stessa parte. L'obiettivo è trovare un equilibrio tra impedire il monitoraggio tra siti da parte di terze parti, mantenendo al contempo un percorso che non infrange casi d'uso validi.

La proposta di insiemi proprietari è attualmente in fase di test. Continua a leggere per scoprire come funziona e come provarla.

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

I cookie non sono intrinsecamente proprietari o di terze parti, ma dipendono dal contesto attuale in cui sono inclusi. Ciò avviene su una richiesta nell'intestazione cookie o tramite document.cookie in JavaScript.

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

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

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

• Il contesto dello stesso sito con SameSite=Lax, Strict o None rende il cookie proprietario.
• Contesto tra siti con SameSite=None, il cookie diventa di terze parti.

Tuttavia, questo non è sempre un punto chiaro. Immagina brandx.site sia un sito per la prenotazione di viaggi che usa anche fly-brandx.site e drive-brandx.site per separare i voli e il noleggio auto. Durante la prenotazione di un percorso, i visitatori passano da un sito all'altro per selezionare le varie opzioni e si aspettano che il "carrello degli acquisti" delle selezioni persiste su questi siti. brandx.site gestisce la sessione dell'utente con un cookie SameSite=None per consentirla in contesti tra siti. Tuttavia, lo svantaggio ora è che i cookie non hanno una protezione cross-site Request Forgery (CSRF). Se evil.site include una richiesta a brandx.site, questo cookie verrà incluso.

Il cookie è cross-site, ma tutti i siti sono di proprietà e gestiti dalla stessa organizzazione. Anche i visitatori capiscono che si tratta della stessa organizzazione e vogliono che la stessa sessione, ovvero un'identità condivisa, tra di loro.

Nota: con gli insiemi proprietari esiste una route per definire le situazioni in cui un contesto cross-site è ancora proprietario. Il cookie può essere incluso all'interno dell'insieme proprietario ed escluso in contesti di terze parti.

Criterio degli insiemi proprietari

Insiemi proprietari propone un metodo per definire esplicitamente questa relazione su più siti di proprietà e gestiti dalla stessa parte. In questo modo, brandx.site potrebbe definire la relazione proprietaria con fly-brandx.site, drive-brandx.site e così via.

Il modello Privacy alla base delle varie proposte di Privacy Sandbox si basa sul concetto di partizionamento dell'identità per impedire il monitoraggio tra siti, tracciando un confine tra i siti che limiti l'accesso a qualsiasi informazione utilizzabile per identificare gli utenti.

Sebbene l'opzione predefinita sia il partizionamento per sito, il che risolve molti casi d'uso proprietari, l'esempio brandx.site mostra che una parte proprietaria può essere più grande di un solo sito.

Una parte importante della proposta di insiemi proprietari è garantire che i criteri di tutti i browser impediscano comportamenti illeciti o usi impropri. Ad esempio, gli insiemi proprietari non devono attivare lo scambio di informazioni sugli utenti tra siti non correlati o il raggruppamento di siti che non sono di proprietà della stessa entità. L'idea è garantire che un insieme proprietario sia mappato a qualcosa che una persona comprende come proprietario e non viene utilizzato come un modo per condividere l'identità tra diverse parti.

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

Nota: la procedura di accettazione di un nuovo set proprietario è attualmente in fase di discussione con W3C e una delle opzioni prese in considerazione prevede che la verifica venga gestita da un'entità indipendente, non da un'azienda di browser.

Una volta verificata l'asserzione del set proprietario in base al criterio, i browser possono recuperare gli elenchi di insiemi tramite una procedura di aggiornamento.

La prova dell'origine ha una norma definita che non è definitiva, ma è probabile che i principi rimangano gli stessi:

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

Nota: scopri di più sui criteri proposti per gli insiemi proprietari.

Come definire un insieme proprietario

Dopo aver identificato i membri e il proprietario del set proprietario della tua organizzazione, un passaggio fondamentale sarà inviare la proposta per l'approvazione. La procedura esatta è ancora in fase di discussione.

Attenzione: un insieme proprietario non deve essere un elenco esaustivo dei siti che appartengono alla stessa organizzazione. Devi creare un insieme solo tra siti se hai bisogno esplicitamente di autorizzare un cookie cross-site. Assicurati di consultare Quali casi d'uso sono adatti alla prova dell'origine degli insiemi proprietari? di seguito.

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

Nell'esempio di brandx insieme proprietario, il dominio del proprietario ospita quanto segue in https://brandx.site/.well-known/first-party-set:

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

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

{ "owner": "brandx.site" }

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

{ "owner": "brandx.site" }

Esistono alcuni limiti per gli insiemi proprietari:

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

Nota: potresti già ospitare un file simile se utilizzi Link ad asset digitali per collegare siti che condividono lo stesso backend di gestione dell'account. Ciò consente in particolare di consentire al gestore delle password di Chrome di suggerire le stesse credenziali sui siti affiliati.

In che modo gli insiemi proprietari influiscono sui cookie?

L'ingrediente per i cookie è l'attributo SameParty proposto. Se specifichi SameParty, indichi al browser di includere il cookie quando il suo 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

Se il visitatore accede a fly-brandx.site e la 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 esempio hotel.xyz, invia una richiesta a brandx.site, il cookie non viene incluso.

Finché SameParty non sarà ampiamente supportato, utilizza l'attributo SameSite insieme a questo per definire il comportamento di riserva per i cookie. L'attributo SameParty può essere considerato come un'impostazione compresa tra SameSite=Lax e SameSite=None.

• SameSite=Lax; SameParty amplierà la funzionalità Lax in modo da includere contesti delle stesse parti, se supportati, ma in caso contrario rientra nell'ambito delle restrizioni Lax.
• SameSite=None; SameParty limiterà la funzionalità None solo ai contesti della stessa parte, se supportati, ma, in caso contrario, utilizzerà le 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é è ancora cross-site e dovresti mitigare questi rischi garantendo connessioni sicure (HTTPS). Allo stesso modo, poiché si tratta di una relazione tra siti, SameSite=Strict non è valido in quanto consente ancora la massima protezione CSRF basata sul sito all'interno di un insieme.

Punto chiave: l'attributo SameParty influisce solo sui contesti in cui può essere inviato un cookie, non crea un barattolo di cookie condiviso. Un cookie di brandx.site è disponibile solo nelle richieste o nei documenti relativi a brandx.site; il cookie non è mai direttamente disponibile per fly-brandx.site. Questo può creare confusione, perché il nome dell'identità potrebbe essere condiviso, ma questo significa che il confine rilassato tra i siti consente loro di impostare o inviare cookie in contesti tra siti uguali e non che i cookie vengono condivisi direttamente.

Quali casi d'uso sono adatti agli insiemi proprietari?

Gli insiemi proprietari sono ideali per i casi in cui un'organizzazione ha bisogno di una forma di identità condivisa tra siti di primo livello diversi. In questo caso, l'identità condivisa significa qualsiasi soluzione, da una soluzione Single Sign-On completa alla semplice necessità di una preferenza condivisa tra più siti.

Nota: puoi identificare possibili candidati per questi casi d'uso perché si tratta di casi in cui hai già contrassegnato un cookie come SameSite=None, anche se è solo per contesti tra siti in cui possiedi tutti i siti coinvolti.

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

• Domini app: office.com,live.com, microsoft.com
• Domini con brand: amazon.com, audible.com / disney.com, pixar.com
• Domini specifici del paese per abilitare 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 corrisponde ai criteri precedenti, hai a disposizione varie opzioni per partecipare. L'investimento più semplice è leggere e partecipare alla discussione sulle due proposte:

• Discussione nel gruppo della community sulla privacy degli insiemi proprietari
• Discussione sugli attributi dei cookie SameParty

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 funzionalità 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

Ciò è utile se vuoi eseguire un test nel tuo ambiente di sviluppo o se vuoi provare ad aggiungere l'attributo SameParty in un ambiente dal vivo per vedere come un insieme proprietario potrebbe influire sui cookie.

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

Termine chiave: le prove rigin sono il modo in cui Chrome consente a sviluppatori esterni di testare le prime proposte in scenari reali per fornire il feedback necessario per evolversi e ottimizzare per soddisfare le esigenze della piattaforma web. Scopri di più nella Guida introduttiva alle prove dell'origine di Chrome.

Come aggiornare i cookie per la prova dell'origine

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

Opzione 1

Innanzitutto, se hai cookie che hai etichettato come SameSite=None ma vuoi limitare i contesti proprietari, puoi aggiungere loro l'attributo SameParty. Nei browser in cui è attiva la prova dell'origine, il cookie non verrà inviato in contesti tra siti al di fuori del set.

Tuttavia, per la maggior parte dei browser che non rientrano nella prova dell'origine, il cookie continuerà a essere inviato tra siti come al solito. Si tratta di 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 prevede un maggiore lavoro, ma consente di separare completamente la prova dell'origine dalla funzionalità esistente e consente in modo specifico 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 il cookie nelle richieste in arrivo, dovresti aspettarti di vedere il cookie cname-fps in una richiesta cross-site solo se i siti coinvolti sono nel set e il browser si trova nella prova dell'origine. Considera questo approccio come il lancio simultaneo di una funzionalità aggiornata prima di ritirare la versione precedente.

Perché potresti non aver bisogno di un set proprietario?

Per la maggior parte dei siti, i confini del sito sono un luogo accettabile per tracciare la partizione o il confine della privacy. Questa è la route proposta con CHIPS (Cookie Having Independent Partitioned State) che offrirebbe ai siti una route di attivazione tramite l'attributo Partitioned per mantenere gli incorporamenti tra siti critici, le risorse, le API e i servizi, evitando la perdita di informazioni identificative tra i siti.

Ecco altri aspetti da considerare per capire che il tuo sito potrebbe funzionare senza bisogno di un set:

• Esegui l'hosting su origini diverse, non su siti diversi. Nell'esempio precedente, se brandx.site ha fly.brandx.site e drive.brandx.site, si tratta di sottodomini diversi, tutti all'interno dello stesso sito. I cookie possono utilizzare SameSite=Lax e non è necessario impostarli.
• Fornisci incorporamenti di terze parti su altri siti. Nell'introduzione, l'esempio di un video di video.site incorporato in my-blog.site è una chiara suddivisione di terze parti. I siti sono gestiti da organizzazioni diverse e gli utenti li vedono come entità separate. Questi due siti non devono essere nello stesso insieme.
• Fornisci servizi di accesso tramite social di terze parti. I provider di identità che utilizzano funzionalità come OAuth o OpenID Connect spesso si basano sui cookie di terze parti per garantire un'esperienza di accesso più fluida per gli utenti. È un caso d'uso valido, ma non è adatto per gli insiemi proprietari perché c'è una chiara differenza tra le organizzazioni. Le prime proposte come WebID stanno esplorando il modo di abilitare questi casi d'uso.