[OUTDATED] Insiemi proprietari e attributo SameParty

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

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 su cookie per funzionalità che richiedono la gestione e l'accesso allo stato tra 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 è in fase di test. Continua a leggere per scoprire come funziona e come puoi 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 corrente in cui sono inclusi. Può essere in una richiesta nell'cookie intestazione o utilizzando 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.

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

  • Il contesto stesso sito 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ì semplice. 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 rovescio della medaglia è che ora il cookie non ha protezione contro la falsificazione delle richieste cross-site (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.

Norme relative agli insiemi proprietari

Gli insiemi proprietari propongono un metodo per definire esplicitamente questa relazione 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 e drive-brandx.site.

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.

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.

Un aspetto importante della proposta degli 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 ai criteri, i browser possono recuperare gli elenchi di insiemi utilizzando un processo 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`, then thesession`cookie will be included on that request. If some other site which is not a part of the first-party set, for examplehotel.xyz, sends a request tobrandx.site`, il cookie non viene incluso.

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 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:

  • Domini 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 questi criteri, 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 dalle funzionalità esistenti e, in particolare, di testare la combinazioneSameSite=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 tra siti se i siti coinvolti sono nell'insieme e il browser è nella prova dell'origine. Considera questo approccio come il lancio simultaneo di una funzionalità aggiornata prima di disattivare la versione precedente.

Perché potresti non aver bisogno di un set proprietario?

Per la maggior parte dei siti, il confine del sito è un luogo accettabile per tracciare la partizione o il confine della privacy. Questo è il percorso proposto con CHIPS (Cookies Having Independent Partitioned State), che offrirebbe ai siti un percorso di attivazione che utilizza l'attributo Partitioned per continuare a disporre di risorse, API e servizi di incorporamento cross-site 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. In questo esempio, 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 offrire agli utenti un'esperienza di accesso più fluida. Si tratta di un caso d'uso valido, ma non è adatto per i set proprietari in quanto esiste una chiara differenza nelle organizzazioni. Le prime proposte come WebID stanno esplorando i modi per abilitare questi casi d'uso.