Set di siti web correlati: guida per gli sviluppatori

Correlazione di siti web (RWS) è un meccanismo di piattaforme web che aiuta i browser a comprendere le relazioni tra una raccolta di domini. Ciò consente ai browser di prendere decisioni chiave per attivare determinate funzioni del sito (ad esempio se consentire l'accesso ai cookie in più siti) e per presentare queste informazioni agli utenti.

Poiché Chrome ritira i cookie di terze parti, l'obiettivo è mantenere casi d'uso chiave sul web migliorando al contempo la privacy per gli utenti. Ad esempio, molti siti si basano su più domini per offrire un'esperienza utente unica. Le organizzazioni potrebbero voler mantenere diversi domini di primo livello per più casi d'uso, come domini specifici dei paesi o domini di servizio per l'hosting di immagini o video. L'insieme di siti web correlati consente ai siti di condividere dati tra domini, con controlli specifici.

A livello generale, un insieme di siti web correlati è una raccolta di domini per i quali è presente un solo "insieme di siti web principali" e potenzialmente più "membri dell'insieme".

Nell'esempio seguente, 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"]
}

L'elenco di insiemi di siti web correlati canonici è un elenco visibile pubblicamente in un formato file JSON ospitato nel repository GitHub di insiemi di siti web correlati, che funge da fonte attendibile per tutti gli insiemi. Chrome utilizza questo file per applicarlo al suo comportamento.

Solo gli utenti con controllo amministrativo su un dominio possono creare un insieme con quel dominio. I mittenti devono dichiarare la relazione tra ogni "membro dell'insieme" e il relativo valore di "insieme principale". I membri dell'insieme possono includere un intervallo di tipi di dominio diversi e devono far parte di un sottoinsieme in base a un caso d'uso.

Se la tua applicazione dipende dall'accesso ai cookie cross-site (chiamati anche cookie di terze parti) tra i siti nello stesso insieme di siti web correlati, puoi utilizzare l'API Storage Access (SAA) e l'API requestStorageAccessFor per richiedere l'accesso a questi cookie. A seconda del sottoinsieme di cui fa parte ciascun sito, il browser potrebbe gestire la richiesta in modo diverso.

Per scoprire di più sulla procedura e sui requisiti per l'invio degli insiemi, consulta le linee guida per l'invio. I gruppi inviati vengono sottoposti a vari controlli tecnici per convalidare gli invii.

Gli insiemi di siti web correlati sono ideali per i casi in cui un'organizzazione abbia bisogno di una forma di identità condivisa tra diversi siti di primo livello.

Di seguito sono riportati alcuni casi d'uso degli insiemi di siti web correlati:

  • Personalizzazione del paese. Utilizzo di siti localizzati utilizzando un'infrastruttura condivisa (example.co.uk potrebbe basarsi su un servizio ospitato da example.ca).
  • Integrazione del dominio del servizio. Sfruttare domini di servizio con cui gli utenti non interagiscono mai direttamente, ma che forniscono servizi sui siti della stessa organizzazione (example-cdn.com).
  • Separazione dei contenuti degli utenti. Accesso a dati su domini diversi che separano i contenuti caricati dagli utenti da altri contenuti del sito per motivi di sicurezza, consentendo al contempo al dominio sandbox di accedere ai cookie di autenticazione (e ad altri) cookie. Se pubblichi contenuti caricati da utenti inattivi, potresti anche riuscire a ospitarli in modo sicuro sullo stesso dominio seguendo le best practice.
  • Contenuti autenticati incorporati. Supportano contenuti incorporati da proprietà affiliate (video, documenti o risorse limitate all'utente che ha eseguito l'accesso sul sito di primo livello).
  • Accedi. Supporto dell'accesso tra proprietà affiliate. L'API FedCM può essere appropriata anche per alcuni casi d'uso.
  • Analytics. Implementazione di analisi e misurazioni dei percorsi degli utenti nelle proprietà affiliate per migliorare la qualità dei servizi.

API Storage Access

Supporto dei browser

  • 119
  • 85
  • 65
  • 11.1

Fonte

L'API Storage Access (SAA) consente ai contenuti multiorigine incorporati di accedere allo spazio di archiviazione a cui normalmente avrebbero accesso solo in un contesto proprietario.

Le risorse incorporate possono utilizzare i metodi SAA per verificare se attualmente hanno accesso allo spazio di archiviazione e per richiedere l'accesso allo user agent.

Quando i cookie di terze parti vengono bloccati ma gli insiemi di siti web correlati (RWS) sono attivi, Chrome concede automaticamente l'autorizzazione nei contesti RWS e mostra una richiesta all'utente, in caso contrario. Un "contesto intra-RWS" è un contesto, ad esempio un iframe, il cui sito incorporato e il sito di primo livello si trovano nello stesso RWS.

Verificare e richiedere l'accesso allo spazio di archiviazione

Per verificare se attualmente hanno accesso allo spazio di archiviazione, i siti incorporati possono utilizzare il metodo Document.hasStorageAccess().

Il metodo restituisce una promessa che si risolve con un valore booleano che indica se il documento ha già accesso o meno ai suoi cookie. La promessa restituisce true anche se l'iframe ha la stessa origine del frame principale.

Per richiedere l'accesso ai cookie in un contesto tra siti incorporati, i siti possono utilizzare Document.requestStorageAccess() (rSA).

L'API requestStorageAccess() deve essere chiamata dall'interno di un iframe. L'iframe deve avere appena ricevuto l'interazione dell'utente (un gesto dell'utente, richiesto da tutti i browser), ma Chrome richiede inoltre che in un determinato momento negli ultimi 30 giorni l'utente abbia visitato il sito proprietario dell'iframe e abbia interagito con quest'ultimo in modo specifico, come documento di primo livello, non in un iframe.

requestStorageAccess() restituisce una promessa che si risolve se è stato concesso l'accesso allo spazio di archiviazione. La promessa viene rifiutata, citando il motivo, se l'accesso è stato negato per qualsiasi motivo.

requestStorageAccessFor in Chrome

Supporto dei browser

  • 119
  • 119
  • x
  • x

Fonte

L'API Storage Access consente ai siti incorporati di richiedere l'accesso allo spazio di archiviazione solo dall'interno di elementi <iframe> che hanno ricevuto l'interazione da parte dell'utente.

Ciò pone difficoltà nell'adozione dell'API Storage Access per i siti di primo livello che utilizzano immagini cross-site o tag script che richiedono cookie.

Per risolvere questo problema, Chrome ha implementato un modo per consentire ai siti di primo livello di richiedere l'accesso allo spazio di archiviazione per conto di origini specifiche con Document.requestStorageAccessFor() (rSAFor).

 document.requestStorageAccessFor('https://target.site')

L'API requestStorageAccessFor() deve essere richiamata da un documento di primo livello. Il documento deve inoltre aver appena ricevuto un'interazione da parte dell'utente. Tuttavia, a differenza di requestStorageAccess(), Chrome non controlla se è presente un'interazione in un documento di primo livello negli ultimi 30 giorni perché l'utente è già sulla pagina.

Controlla le autorizzazioni di accesso allo spazio di archiviazione

L'accesso ad alcune funzionalità del browser, come la fotocamera o la geolocalizzazione, si basa sulle autorizzazioni concesse dall'utente. L'API Permissions consente di verificare lo stato dell'autorizzazione per accedere a un'API, ad esempio se è stata concessa, negata o richiede una qualche forma di interazione dell'utente, ad esempio un clic su una richiesta o l'interazione con la pagina.

Puoi eseguire query sullo stato delle autorizzazioni utilizzando navigator.permissions.query().

Per verificare l'autorizzazione di accesso allo spazio di archiviazione per il contesto corrente, devi trasmettere la stringa 'storage-access':

navigator.permissions.query({name: 'storage-access'})

Per controllare l'autorizzazione di accesso allo spazio di archiviazione per un'origine specificata, devi passare la stringa 'top-level-storage-access':

navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})

Tieni presente che, per proteggere l'integrità dell'origine incorporata, questa operazione controlla solo le autorizzazioni concesse dal documento di primo livello utilizzando document.requestStorageAccessFor.

A seconda che l'autorizzazione possa essere concessa automaticamente o che richieda un gesto dell'utente, l'autorizzazione restituirà prompt o granted.

Per modello di frame

Le concessioni rSA si applicano per frame. Le concessioni rSA e rSAFor vengono trattate come autorizzazioni separate.

Ogni nuovo frame dovrà richiedere l'accesso allo spazio di archiviazione singolarmente e gli verrà concesso automaticamente l'accesso. Solo la prima richiesta richiede un gesto dell'utente; tutte le richieste successive avviate dall'iframe, come la navigazione o le sottorisorse, non dovranno attendere il gesto dell'utente, che verrà concesso per la sessione di navigazione dalla richiesta iniziale.

Aggiornando, ricaricando o ricreando in altro modo l'iframe, sarà necessario richiedere di nuovo l'accesso.

I cookie devono specificare entrambi gli attributi SameSite=None e Secure, in quanto gli RSA forniscono l'accesso solo ai cookie già contrassegnati per l'utilizzo in contesti tra siti.

I cookie con SameSite=Lax, SameSite=Strict o senza un attributo SameSite sono solo per uso proprietario e non verranno mai condivisi in un contesto tra siti, indipendentemente da rSA.

Sicurezza

Per rSAFor, le richieste di sottorisorse richiedono intestazioni di condivisione delle risorse tra origini (CORS) o l'attributo crossorigin nelle risorse, garantendo un'attivazione esplicita.

Esempi di implementazione

Richiedi l'accesso allo spazio di archiviazione da un iframe multiorigine incorporato

Diagramma che mostra un sito incorporato in un sito di primo livello
Utilizzo di requestStorageAccess() in un incorporamento su un altro sito.

Verificare se hai accesso allo spazio di archiviazione

Per verificare se hai già accesso allo spazio di archiviazione, utilizza document.hasStorageAccess().

Se la promessa si risolve vera, puoi accedere allo spazio di archiviazione nel contesto tra siti. Se restituisce false, devi richiedere l'accesso allo spazio di archiviazione.

document.hasStorageAccess().then((hasAccess) => {
    if (hasAccess) {
      // You can access storage in this context
    } else {
      // You have to request storage access
    }
});

Richiedi accesso allo spazio di archiviazione

Se devi richiedere l'accesso allo spazio di archiviazione, controlla prima l'autorizzazione di accesso allo spazio di archiviazione navigator.permissions.query({name: 'storage-access'}) per verificare se richiede un gesto dell'utente o se può essere concessa automaticamente.

Se l'autorizzazione è granted, puoi chiamare document.requestStorageAccess() e l'operazione dovrebbe avere esito positivo senza un gesto dell'utente.

Se lo stato di autorizzazione è prompt, devi avviare la chiamata document.requestStorageAccess() dopo un gesto dell'utente, ad esempio il clic su un pulsante.

Esempio:

navigator.permissions.query({name: 'storage-access'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSA();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSA();
    });
    document.body.appendChild(btn);
  }
});

function rSA() {
  if ('requestStorageAccess' in document) {
    document.requestStorageAccess().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Le richieste successive dall'interno del frame, dalle navigazioni o dalle risorse secondarie avranno automaticamente l'autorizzazione per accedere ai cookie in più siti. hasStorageAccess() restituisce cookie veri e cross-site dallo stesso insieme di siti web correlati che verranno inviati su queste richieste senza chiamate JavaScript aggiuntive.

Diagramma che mostra l&#39;utilizzo di requestStorageAccessFor() su un sito di primo livello e non in un incorporamento
Utilizzo di requestStorageAccessFor() su un sito di primo livello per un'origine diversa

I siti di primo livello possono utilizzare requestStorageAccessFor() per richiedere l'accesso allo spazio di archiviazione per conto di origini specifiche.

hasStorageAccess() controlla soltanto se il sito che lo chiama ha accesso allo spazio di archiviazione, quindi un sito di primo livello può controllare le autorizzazioni per un'altra origine.

Per scoprire se all'utente verrà richiesta una richiesta o se l'accesso allo spazio di archiviazione è già stato concesso all'origine specificata, chiama navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}).

Se l'autorizzazione è granted, puoi chiamare document.requestStorageAccessFor('https://target.site'). L'operazione dovrebbe andare a buon fine senza un gesto dell'utente.

Se l'autorizzazione è prompt, dovrai agganciare la chiamata document.requestStorageAccessFor('https://target.site') dietro il gesto dell'utente, ad esempio il clic su un pulsante.

Esempio:

navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSAFor();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSAFor();
    });
    document.body.appendChild(btn);
  }
});

function rSAFor() {
  if ('requestStorageAccessFor' in document) {
    document.requestStorageAccessFor().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

Dopo una chiamata requestStorageAccessFor() riuscita, le richieste tra siti includeranno i cookie se includono CORS o l'attributo multiorigine, quindi i siti potrebbero voler attendere prima di attivare una richiesta.

Le richieste devono utilizzare l'opzione credentials: 'include' e le risorse devono includere l'attributo crossorigin="use-credentials".

function checkCookie() {
    fetch('https://related-website-sets.glitch.me/getcookies.json', {
        method: 'GET',
        credentials: 'include'
      })
      .then((response) => response.json())
      .then((json) => {
      // Do something
      });
  }

Come eseguire i test a livello locale

Prerequisiti

Per testare gli insiemi di siti web correlati a livello locale, utilizza Chrome 119 o versioni successive avviato dalla riga di comando e attiva il flag di Chrome test-third-party-cookie-phaseout.

Attiva il flag di Chrome

Per attivare il flag di Chrome necessario, vai su chrome://flags#test-third-party-cookie-phaseout dalla barra degli indirizzi e modifica il flag in Enabled. Assicurati di riavviare il browser dopo la modifica dei flag.

Per avviare Chrome con l'insieme di siti web correlati dichiarato localmente, crea un oggetto JSON che contenga gli URL membri di un insieme e trasmettilo a --use-related-website-set.

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

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Esempio

Per abilitare gli insiemi di siti web correlati a livello locale, devi abilitare test-third-party-cookie-phaseout in chrome://flags e avviare Chrome dalla riga di comando con il flag --use-related-website-set con l'oggetto JSON contenente gli URL membri di un insieme.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

Verificare di avere accesso ai cookie in più siti

Chiama le API (rSA o rSAFor) dai siti sottoposti a test e convalida l'accesso ai cookie in più siti.

Per dichiarare la relazione tra i domini e specificare di quale sottoinsieme fanno parte, segui questi passaggi:

  1. Identifica i domini pertinenti, inclusi i membri principali impostati e i membri impostati, che faranno parte dell'insieme di siti web correlati. Identifica anche il tipo di sottoinsieme a cui appartiene ogni membro dell'insieme.
  2. Assicurati che siano soddisfatti i requisiti per la formazione degli insiemi e i requisiti di convalida degli insiemi.
  3. Dichiara l'insieme di siti web correlati nel formato JSON corretto.
  4. Invia l'insieme di siti web correlati creando una richiesta di pull (PR) nella related_website_sets.JSON in cui Chrome ospiterà l'elenco canonico dell'insieme di siti web correlati. Per creare PR, è necessario un account GitHub e dovrai firmare un Contratto di licenza per collaboratori (CLA) per contribuire all'elenco.

Una volta creato il PR, verrà effettuata una serie di controlli per confermare che siano soddisfatti i requisiti del passaggio 2.

Se l'esito è positivo, il PR indicherà che i controlli sono stati superati. Le PR approvate verranno unite manualmente in gruppi nell'elenco canonico dell'insieme di siti web correlati una volta alla settimana (martedì alle 12:00 fuso orario della costa orientale).

Se uno qualsiasi dei controlli non va a buon fine, l'autore della richiesta riceverà una notifica tramite un errore di PR su GitHub. L'autore della richiesta può correggere gli errori e aggiornare il PR, tenendo presente quanto segue:

  • Se il PR ha esito negativo, un messaggio di errore fornirà ulteriori informazioni sul motivo per cui l'invio potrebbe non essere riuscito (esempio).
  • Tutti i controlli tecnici che regolano l'invio dei set vengono svolti su GitHub e, di conseguenza, tutti gli errori di invio derivanti da controlli tecnici saranno visibili su GitHub.

Criteri aziendali

Per soddisfare le esigenze degli utenti aziendali, Chrome dispone di un paio di criteri aziendali:

  • I sistemi che potrebbero non essere in grado di integrarsi con gli insiemi di siti web correlati possono disattivare la funzionalità di insiemi di siti web correlati in tutte le istanze aziendali di Chrome con il criterio RelatedWebsiteSetsEnabled.
  • Alcuni sistemi aziendali hanno siti solo per uso interno, ad esempio un'intranet, con domini registrabili diversi da quelli dell'insieme di siti web correlati. Se devono trattare questi siti come parte dell'insieme di siti web correlati senza esporli pubblicamente (in quanto i domini potrebbero essere riservati), possono aumentare o sostituire l'elenco pubblico di insiemi di siti web correlati con le norme di RelatedWebsiteSetsOverrides.

"Prompt dell'utente" e "Gesto dell'utente"

Un "prompt dell'utente" e un "gesto dell'utente" sono due cose diverse. Chrome non mostrerà una richiesta di autorizzazione agli utenti per i siti nello stesso insieme di siti web correlati, ma Chrome richiede comunque che l'utente abbia interagito con la pagina. Prima di concedere l'autorizzazione, Chrome richiede un gesto dell'utente, chiamato anche "interazione utente" o "attivazione utente". Questo perché l'utilizzo dell'API Storage Access al di fuori di un contesto di insiemi di siti web correlati (ovvero requestStorageAccess()) richiede anche un gesto dell'utente a causa dei principi di progettazione della piattaforma web.

Accesso ai cookie o allo spazio di archiviazione di altri siti

L'insieme di siti web correlati non unisce lo spazio di archiviazione per siti diversi, ma consente solo chiamate a requestStorageAccess() più semplici (senza messaggi). Gli insiemi di siti web correlati riducono solo l'attrito da parte degli utenti legati all'utilizzo dell'API Storage Access, ma non determinano cosa fare una volta ripristinato l'accesso. Se A e B sono siti diversi nello stesso insieme di siti web correlati e A incorpora B, B può chiamare requestStorageAccess() e accedere allo spazio di archiviazione proprietario senza chiedere conferma all'utente. Gli insiemi di siti web correlati non eseguono comunicazioni tra siti. Ad esempio, se imposti un insieme di siti web correlati, i cookie appartenenti a B non verranno inviati ad A. Se vuoi condividere questi dati, dovrai farlo tu stesso, ad esempio inviando un elemento window.postMessage da un iframe B a un frame A.

Gli insiemi di siti web correlati non consentono l'accesso implicito ai cookie non partizionati senza richiamare un'API. I cookie cross-site non vengono resi disponibili per impostazione predefinita nell'insieme; gli insiemi di siti web correlati consentono solo ai siti all'interno dell'insieme di saltare la richiesta di autorizzazione dell'API Storage Access. Un iframe deve chiamare document.requestStorageAccess() se vuole accedere ai propri cookie, altrimenti la pagina di primo livello può chiamare document.requestStorageAccessFor().

Condividi feedback

Inviare un set su GitHub e utilizzare l'API Storage Access e l'API requestStorageAccessFor sono opportunità per condividere la tua esperienza con la procedura e gli eventuali problemi riscontrati.

Per partecipare alle discussioni sugli insiemi di siti web correlati: