Istruzioni per il test degli insiemi proprietari

L'ultima iterazione degli insiemi proprietari è pronta per essere testata con i flag delle funzionalità degli sviluppatori da Chrome 108. Stiamo lavorando attivamente sugli insiemi proprietari con l'obiettivo di passare alla spedizione, quindi prenderemo in considerazione i feedback per questa fase dei test degli sviluppatori fino al rilascio di Chrome 111 all'inizio di marzo (7 marzo 2023).

Il feedback dell'ecosistema ha evidenziato casi d'uso tra siti che saranno interessati dalla mancata supporto dei cookie di terze parti in Chrome. La proposta Insiemi proprietari esamina e si rivolge a una classe di casi d'uso tra siti in cui i siti interdipendenti condividono una relazione che può essere espressa al browser in modo che quest'ultimo possa intraprendere l'azione appropriata per conto dell'utente e/o presentare efficacemente le informazioni all'utente.

La proposta aggiornata utilizza due API (l'API Storage Access e una nuova API denominata provvisoriamente requestStorageAccessForOrigin) per fornire ai siti un metodo attivo per richiedere l'accesso tra siti per i propri cookie all'interno di un insieme proprietario. Le istruzioni riportate di seguito dovrebbero consentirti di testare e convalidare gli insiemi che potresti voler creare per i tuoi siti e i punti giusti per chiamare le due diverse API.

Panoramica degli insiemi proprietari

Gli insiemi proprietari (FPS) sono un meccanismo di piattaforme web che consente agli sviluppatori di dichiarare relazioni tra siti, in modo che i browser possano utilizzare queste informazioni per consentire un accesso limitato ai cookie tra siti per scopi specifici rivolti agli utenti. Chrome utilizzerà queste relazioni dichiarate per decidere quando consentire o negare a un sito l'accesso ai propri cookie in un contesto di terze parti.

A livello generale, un insieme proprietario è una raccolta di domini per i quali è presente un singolo "insieme di membri principali" e potenzialmente più "membri dell'insieme". Solo gli autori dei siti possono inviare i propri domini in un insieme e dovranno dichiarare la relazione tra ogni "membro impostato" e l'elemento "imposta principale". I membri dell'insieme possono includere una gamma di tipi di dominio diversi con sottoinsiemi basati sui casi d'uso.

Per facilitare la gestione da parte del browser di ogni sottoinsieme in base alle implicazioni sulla privacy di ogni sottoinsieme, proponiamo di sfruttare l'API Storage Access (SAA) e requestStorageAccessForOrigin per abilitare l'accesso ai cookie in un FPS.

Con il SAA, i siti possono richiedere attivamente l'accesso ai cookie tra siti. Chrome concede automaticamente la richiesta se il sito richiedente e il sito web di primo livello si trovano nello stesso f/s. Consulta la documentazione relativa all'API Storage Access (SAA) per informazioni su come le chiamate ad SAA vengono elaborate da altri browser.

SAA al momento richiede che il documento ottenga l'attivazione dell'utente prima di chiamare i metodi dell'API.

Ciò può rendere l'adozione di FPS difficoltosa per i siti di primo livello che utilizzano immagini cross-site o tag di script che richiedono cookie. Per risolvere alcune di queste sfide, abbiamo proposto una nuova API, requestStorageAccessForOrigin, per facilitare l'adozione di questa modifica da parte degli sviluppatori. Questa API è disponibile anche per i test.

Imposta invio

L'elenco FPS canonico sarà un elenco visibile pubblicamente in un formato file JSON ospitato in un nuovo repository GitHub di FPS, che fungerà da fonte attendibile per tutti gli insiemi. Chrome utilizzerà questo file per applicarlo al suo comportamento.

Per scoprire di più sulla procedura proposta e sui requisiti per l'invio degli insiemi, consulta le linee guida per l'invio. Puoi anche provare a inviare un set per testare i vari controlli tecnici che convalideranno i contenuti inviati. Tieni presente che tutti i contenuti inviati verranno cancellati prima che l'FPS sia disponibile nelle versioni stabili di Chrome.

Poiché il processo di invio degli insiemi è ancora in fase di sviluppo attivo, per i test locali puoi creare gli insiemi solo dalla riga di comando e passarli direttamente al browser. Per i test locali, non è necessario inviare un set al repository GitHub per eseguire test con flag funzionalità.

Come eseguire i test a livello locale

Prerequisiti

Per testare gli FPS in locale, utilizza Chrome 108 o una versione successiva avviato dalla riga di comando.

Per visualizzare l'anteprima delle funzionalità di Chrome in arrivo prima del rilascio, scarica la versione beta o Canary di Chrome.

Esempio

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

Scopri di più su come eseguire Chromium con i flag.

Procedura

Per attivare FPS localmente, devi utilizzare l'opzione --enable-features di Chrome con un elenco di flag separati da virgole spiegati in questa sezione e dichiarare un insieme di siti correlati come oggetto JSON da passare a --use-first-party-set.

Attiva FPS

FirstPartySets attiva FPS in Chrome.

FirstPartySets

Abilita API Storage Access

StorageAccessAPI

Consente di attivare in Chrome l'API Storage Access (SAA), che consente agli iframe incorporati di utilizzare requestStorageAccess() per richiedere l'accesso ai cookie in un contesto tra siti, anche quando i cookie di terze parti sono bloccati dal browser.

Tieni presente che quando viene chiamato, requestStorageAccess() richiede un gesto dell'utente per risolvere il problema. Le versioni future di Chrome potrebbero imporre diversi insiemi di requisiti poiché la specifica SAA è ancora in evoluzione. Fai riferimento qui per un elenco di miglioramenti pianificati all'implementazione dell'SAA in Chrome.

StorageAccessAPIForOriginExtension

Consente ai siti di primo livello di utilizzare requestStorageAccessForOrigin() per richiedere l'accesso allo spazio di archiviazione per conto di origini specifiche. È utile per i siti di primo livello che utilizzano immagini cross-site o tag di script che richiedono cookie e risolve alcune delle sfide derivanti dall'adozione di SAA.

Dichiara un set a livello locale

Un insieme proprietario è una raccolta di domini per i quali è presente un singolo "insieme di membri principali" e potenzialmente più "membri impostati". I membri dell'insieme possono includere una gamma di tipi di dominio diversi con sottoinsiemi basati sui casi d'uso.

Crea un oggetto JSON che contenga gli URL membri di un insieme e trasmettilo a --use-first-party-set.

Nell'esempio riportato di seguito, primary elenca il dominio principale, mentre associatedSites elenca i domini che soddisfano i requisiti del sottoinsieme associato.

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

Esempio:

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

Per i test locali, puoi creare set solo dalla riga di comando e passarli direttamente al browser. A scopo di test locale non è prevista alcuna convalida, ma quando FPS viene spedito in versioni stabili, tutti i set dovranno essere inviati al repository GitHub di FPS ed essere soggetti a criteri di convalida.

Attiva UI FPS

PageInfoCookiesSubpage

Consente di attivare la visualizzazione degli FPS nella sezione Informazioni pagina accessibile dalla barra degli URL.

PrivacySandboxFirstPartySetsUI

Attiva l'opzione FPS dell'UI "Consenti ai siti correlati di vedere le tue attività nel gruppo" nelle impostazioni di Chrome, in Privacy e sicurezza → Cookie e altri dati dei siti (chrome://settings/cookies).

Verificare che i cookie di terze parti siano bloccati

  1. Nelle impostazioni di Chrome, vai a Privacy e sicurezza → Cookie e altri dati dei siti oppure chrome://settings/cookies.
  2. Nella sezione Impostazioni generali, assicurati che l'opzione "Blocca cookie di terze parti" sia attiva.
  3. Verifica che sia attiva anche l'opzione secondaria "Consenti ai siti correlati di vedere le tue attività nel gruppo".

Considerazioni sulla sicurezza

Poiché l'API Storage Access consente ai siti web di recuperare l'accesso ai cookie di terze parti in casi selezionati, potrebbe rendere le applicazioni web vulnerabili ad attacchi tra siti e fughe di informazioni. I siti che si basano sui cookie in contesti tra siti devono essere consapevoli dei rischi del CSRF e di altri attacchi.

Miglioramenti pianificati

Per migliorare questo aspetto, le future release di Chrome richiederanno controlli di sicurezza aggiuntivi, con l'obiettivo di garantire l'attivazione esplicita dell'incorporamento. I miglioramenti proposti: concederanno l'accesso solo in base al frame, richiederanno CORS sulle richieste con credenziali e manterranno l'ambito dell'accesso solo all'origine. Per saperne di più, consulta l'analisi recente della sicurezza.

Consulta l'elenco dei miglioramenti pianificati all'implementazione dell'SAA in Chrome.

Tieni presente che Chrome invia solo i cookie contrassegnati con SameSite=None in contesti incorporati tra siti, dove è pertinente l'API Storage Access. Tuttavia, finché tutti i browser non avranno ritirato l'accesso predefinito a questi cookie, non è possibile fare ipotesi su dove è possibile utilizzare i cookie. Non è sicuro dare per scontato che l'accesso venga consentito solo all'interno di un FPS e che i siti debbano continuare a utilizzare le best practice standard per la sicurezza.

Interagisci e condividi feedback

I test locali sono un'opportunità per provare il meccanismo dell'API Storage Access per attivare FPS e condividere feedback o eventuali problemi riscontrati. Inoltre, testare il processo di invio impostato su GitHub è un'opportunità per condividere la tua esperienza con la procedura e le fasi di convalida. Per partecipare e condividere il tuo feedback sulla proposta aggiornata: