[OUTDATED] Insiemi proprietari e attributo SameParty

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

I browser si stanno orientando verso la creazione di cookie di terze parti obsoleto per migliorare la privacy sul web, ma siti come questi spesso si basano sui cookie per Funzionalità che richiedono la manutenzione e l'accesso allo stato in più domini (come Single Sign-On e gestione del consenso).

Gli insiemi proprietari possono consentire nomi di domini correlati di proprietà e gestiti da la stessa persona giuridica da trattare come proprietaria nei casi in cui i proprietari e terze parti sono altrimenti trattate in modo diverso. I nomi di dominio all'interno di un Gli insiemi proprietari sono considerati della stessa parte e possono etichettare quali cookie sono da impostare o inviare nel contesto della stessa parte. L'obiettivo è trovare un trovare un equilibrio tra l'impossibilità di eseguire il monitoraggio tra siti da parte di terzi gestire un percorso che non interrompa casi d'uso validi.

La proposta di insiemi proprietari è attualmente in fase di test , continua a leggere per scoprire come funziona e su come fare una prova.

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

I cookie non sono intrinsecamente proprietari o di terze parti, dipendono il contesto in cui è incluso il cookie. O su una richiesta nel cookie o tramite document.cookie in JavaScript.

Se, ad esempio, video.site ha un cookie theme=dark, mentre navighi video.site e viene inviata una richiesta a video.site, che è uno stesso sito contesto e il cookie incluso è proprietario.

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

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

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

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

Tuttavia, questo non è sempre così chiaro. Immagina che brandx.site sia un viaggio sito di prenotazione e utilizzano anche fly-brandx.site e drive-brandx.site per voli e noleggio auto separati. Nel corso della prenotazione di un viaggio, i visitatori visitano questi siti per selezionare le diverse opzioni, si aspettano che "carrello degli acquisti" di selezioni in modo che vengano mantenuti tra questi siti. brandx.site gestisce la sessione dell'utente con un cookie SameSite=None per consentire la i contesti tra siti. Lo svantaggio è che ora il cookie non ha più cross-site, Richiedi la protezione dalla falsificazione (CSRF). Se evil.site include una richiesta a brandx.site, includerà quel cookie.

Il cookie è cross-site, ma tutti questi siti sono di proprietà e gestiti dalla stessa dell'organizzazione. I visitatori comprendono inoltre che si tratta della stessa organizzazione e vogliono nella stessa sessione, ovvero un'identità condivisa, tra di loro.

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

Norme relative agli insiemi proprietari

Insiemi proprietari propone una metodo per definire esplicitamente questa relazione tra più siti che sono di proprietà e gestiti dalla stessa parte. Ciò consentirebbe a brandx.site di definisce la sua relazione proprietaria con fly-brandx.site, drive-brandx.site e così via.

Il modello di privacy che promuove le varie proposte di Privacy Sandbox si basano sul concetto di partizionamento per impedire il monitoraggio tra siti, tracciando un confine tra i siti limita l'accesso alle informazioni che possono essere utilizzate per identificare gli utenti.

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

Sebbene l'opzione predefinita sia la partizione per sito, risolve molti casi d'uso, l'esempio brandx.site mostra che i dati proprietari possono essere di un solo sito.

Diagramma che mostra come la stessa istanza di un cookie per un insieme può essere inclusa in contesti tra siti quando tutti quei siti fanno parte dello stesso insieme.

Una parte importante della proposta di insiemi proprietari è garantire che i criteri tra browser impedisce usi impropri. Ad esempio, gli insiemi proprietari non devono attivare lo scambio di informazioni sugli utenti tra siti non correlati, oppure il raggruppamento di siti che non sono di proprietà della stessa entità. L'idea è garantire che L'insieme proprietario è associato a qualcosa che una persona comprende come proprietario e che non vengono usati per condividere l'identità tra parti diverse.

Un modo in cui un sito può registrare un insieme proprietario potrebbe essere il sito di inviare il gruppo di domini proposto a un tracker pubblico (come un repository GitHub dedicato) oltre alle informazioni necessarie per soddisfare .

Una volta verificata l'asserzione impostata proprietaria secondo i criteri, i browser possono quindi recuperano elenchi di set tramite un processo di aggiornamento.

La prova dell'origine ha una norma definita che non è definitiva, ma i principi sono rimarranno invariati:

  • I domini di un insieme proprietario devono essere di proprietà e gestiti dallo stesso dell'organizzazione.
  • I domini devono essere riconoscibili agli utenti come gruppo.
  • I domini devono condividere le norme sulla privacy comuni.
di Gemini Advanced.

Come definire un insieme proprietario

Una volta identificati i membri e il proprietario del profilo proprietario dell'organizzazione impostato, un passaggio fondamentale consiste nell'inviare l'insieme proposto per l'approvazione. L'esatto è ancora in discussione.

Per dichiarare un set proprietario, risorse JSON statiche che elencano membri e proprietari deve essere ospitata all'indirizzo /.well-known/first-party-set nella parte superiore di ogni incluso.

Nell'esempio del set proprietario brandx, il dominio-proprietario ospita il segui alle 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 dell'insieme. Noi di 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 insieme può avere un solo proprietario.
  • Un membro può appartenere a un solo insieme, senza sovrapposizioni o combinazioni.
  • L'elenco dei membri deve rimanere relativamente leggibile e non eccessivamente grandi.
di Gemini Advanced.

In che modo gli insiemi proprietari influiscono sui cookie?

L'ingrediente corrispondente per i biscotti è la proposta SameParty . Specifica di SameParty indica al browser di includere il cookie quando il suo contesto fa parte dello stesso proprietario impostato come contesto di primo livello.

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

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

Poi, quando il visitatore si trova su 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 del set proprietario, ad esempio hotel.xyz, invia una richiesta a brandx.site, il cookie non verrà incluso.

Diagramma che mostra il cookie brandx.site consentito o bloccato in contesti tra siti come descritto.

Fino a quando SameParty non sarà ampiamente supportato, utilizza l'attributo SameSite insieme per per definire il comportamento di riserva per i cookie. Puoi pensare a SameParty assegnandoti un'impostazione compresa tra SameSite=Lax e SameSite=None.

  • SameSite=Lax; SameParty amplierà la funzionalità Lax in includere contesti della stessa parte se supportati, ma utilizza il criterio Lax limitazioni in caso contrario.
  • SameSite=None; SameParty limiterà la funzionalità di None a ove supportato, ma rientra nel contesto più ampio None autorizzazioni in caso contrario.

Sussistono 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 ridurre queste limitazioni i rischi assicurando connessioni sicure (HTTPS). Analogamente, poiché si tratta di un relazione tra siti, SameSite=Strict non è valido perché consente ancora 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 ideali per i casi in cui un'organizzazione ha bisogno di un tipo di e identità condivisa fra più siti di primo livello. Identità condivisa in questo caso significa una soluzione completa preferenza sui siti.

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

  • Domini di app: office.com,live.com, microsoft.com
  • Domini con brand: amazon.com, audible.com / disney.com, pixar.com
  • Domini specifici dei paesi per abilitare la localizzazione: google.co.in, google.co.uk
  • Domini di servizio con cui gli utenti non interagiscono mai direttamente, ma che forniscono nei siti della stessa organizzazione: gstatic.com, githubassets.com fbcdn.net
  • Domini sandbox con cui gli utenti non interagiscono mai direttamente, ma per i quali esistono. motivi di sicurezza: googleusercontent.com, githubusercontent.com

Come partecipare?

Se disponi di un insieme di siti che corrisponde ai criteri di cui sopra, c'è un di opzioni per partecipare. L'investimento minimo è leggere e partecipare la discussione sulle due proposte:

Durante la fase di test, puoi provare la funzionalità utilizzando la Flag della riga di comando --use-first-party-set e fornisce un elenco separato da virgole di siti.

Puoi fare una prova sul sito dimostrativo all'indirizzo https://fps-member1.glitch.me/ dopo l'inizio Chrome con il seguente flag:

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

È utile se vuoi eseguire test nel tuo ambiente di sviluppo o prova ad aggiungere l'attributo SameParty in un ambiente di pubblicazione per vedere come proprietario potrebbe influire sui cookie.

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

Come aggiornare i cookie per la prova dell'origine

Se ti unisci alla prova dell'origine e testerai l'attributo SameParty su cookie, ecco due pattern da considerare.

Opzione 1

Innanzitutto, se hai cookie che hai etichettato come SameSite=None, ma che limitare i contesti proprietari, puoi aggiungere SameParty a questi attributi. Nei browser in cui è attiva la prova dell'origine, il cookie non vengano inviate in contesti tra siti esterni all'insieme.

Tuttavia, per la maggior parte dei browser esterni alla prova dell'origine, il cookie continuerà a essere inviato tra siti come di consueto. Consideralo come 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 consente di separare completamente l'origine di prova delle funzionalità esistenti e consente in particolare di testare 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 vedere solo il cookie cname-fps in una richiesta tra siti se i siti coinvolti sono nel e il browser è in prova dell'origine. Considera questo approccio come un il lancio simultaneo di una funzionalità aggiornata prima di disattivare quella completamente gestita.

Perché potresti non aver bisogno di un insieme proprietario?

Per la maggior parte dei siti, i confini del sito sono un punto accettabile per il tracciamento la partizione o il confine di privacy. Questo è il percorso proposto con CHIPS (cookie che sono partizionati in modo indipendente) stato) che consentirebbe l'attivazione ai siti. percorso tramite l'attributo Partitioned per mantenere i incorporamenti, risorse, API e servizi, evitando le fughe di informazioni informazioni tra i siti.

Alcuni altri aspetti da considerare significano che il tuo sito potrebbe funzionare correttamente senza un insieme:

  • Hosting su origini diverse, non su siti diversi. Nell'esempio precedente, Se brandx.site avesse fly.brandx.site e drive.brandx.site, allora quelli sono sottodomini diversi all'interno dello stesso sito. I cookie possono utilizzare SameSite=Lax e non è necessario alcun set.
  • Fornisci incorporamenti di terze parti ad altri siti. Nell'introduzione, l'esempio un video di video.site incorporato in my-blog.site è chiaramente una terza parte dividere. I siti sono gestiti da organizzazioni diverse e gli utenti li visualizzano come entità separate. Questi due siti non devono essere uniti.
  • Fornisci servizi di accesso tramite social di terze parti. Provider di identità che utilizzano elementi come la connessione OAuth o OpenId spesso si basano su cookie di terze parti per un un'esperienza di accesso più fluida per gli utenti. È un caso d'uso valido, ma non adatti agli insiemi proprietari in quanto c'è una chiara differenza tra le organizzazioni. Le prime proposte come WebID vengono esplorare modi per abilitare questi casi d'uso.