Terze parti

Che cos'è una terza parte?

È piuttosto raro che un sito web sia completamente autonomo. L'Almanacco web HTTP indica che la maggior parte dei siti web (circa il 95%) include alcuni contenuti di terze parti.

L'Almanacco definisce contenuti di terze parti come contenuti ospitati su un'origine pubblica e condivisa, ampiamente utilizzato da vari siti e non influenzato da un singolo proprietario del sito. Può trattarsi di immagini o altri elementi multimediali come video, caratteri o script. Immagini e script rappresentano molto di più di tutto il resto. I contenuti di terze parti non sono essenziali per lo sviluppo di un sito, ma potrebbe esserlo; quasi certamente utilizzerai qualcosa caricato da un server pubblico condiviso, che si tratti di caratteri web, iframe incorporati di video, annunci o librerie JavaScript. Ad esempio, potresti utilizzare caratteri web forniti da Google Fonts o misurare l'analisi con Google Analytics; avere aggiunto pulsanti Mi piace o pulsanti Accedi con dai social network; potresti incorporare mappe o video o gestire gli acquisti di shopping tramite servizi di terze parti; potresti tenere traccia degli errori e registrarti per i tuoi team di sviluppo tramite strumenti di monitoraggio di terze parti.

Per motivi di privacy, è utile considerare una definizione leggermente diversa e meno generica: una risorsa di terze parti, e in particolare uno script di terze parti, viene fornita da un'origine condivisa e pubblica e ampiamente utilizzata come illustrato, ma è anche preparata da qualcuno che non è il proprietario del sito. L'aspetto dell'attribuzione dei contenuti di terze parti è determinante quando devi valutare come proteggere la privacy dei tuoi utenti dagli altri. Questo ti porterà a considerare quali rischi sono presenti e quindi a decidere se o come utilizzare una risorsa di terze parti in base a tali rischi. Come già detto, questi elementi ti aiuteranno a comprendere il contesto e quindi a capire quali compromessi devi fare e che cosa significano.

Questo non è del tutto inteso quando si parla di "risorse di terze parti" in generale: la distinzione tra proprietario e terze parti riguarda in realtà il contesto in cui qualcosa viene utilizzato. Uno script caricato da un altro sito web è una risorsa di terze parti e la richiesta HTTP che lo carica può includere dei cookie, che però non sono "cookie di terze parti"; ma solo cookie e il fatto che si tratti di "terze parti" o "proprietari" dipende dal fatto che lo script venga caricato su una pagina del sito o su quella del proprietario dello script.

Perché utilizziamo risorse di terze parti?

Le terze parti sono un ottimo modo per aggiungere funzionalità al tuo sito. Potrebbe trattarsi di funzionalità esposte agli utenti o di funzioni invisibili per gli sviluppatori, come il monitoraggio degli errori, che però riducono il carico di sviluppo. Inoltre, gli script stessi vengono gestiti da qualcun altro, ovvero il team di sviluppo del servizio che stai includendo. Tutto questo funziona grazie alla componibilità del web: la possibilità di riunire le parti per formare un insieme che è maggiore della loro somma.

L'almanacco web dell'archivio HTTP fornisce una buona descrizione:

Le terze parti forniscono una raccolta infinita di immagini, video, caratteri, strumenti, raccolte, widget, tracker, annunci e qualsiasi altra informazione che puoi immaginare di incorporare nelle nostre pagine web. Ciò consente anche agli utenti più non tecnici di creare e pubblicare contenuti sul web. Senza terze parti, il web sarebbe probabilmente un mezzo accademico molto noioso, basato su testo, invece di una piattaforma ricca, immersiva e complessa che è così parte integrante della vita di molti di noi oggi.

Cosa possono fare le risorse di terze parti?

Accesso ad alcune informazioni

Quando utilizzi una risorsa di terze parti sul tuo sito web, indipendentemente da quale sia, alcune informazioni vengono trasmesse alla terza parte in questione. Ad esempio, se includi un'immagine proveniente da un altro sito, la richiesta HTTP inviata dal browser dell'utente trasmetterà un'intestazione referrer con l'URL della tua pagina e l'indirizzo IP dell'utente.

Monitoraggio tra siti

Continuando con lo stesso esempio, quando l'immagine viene caricata dal sito di terze parti, può includere un cookie che verrà inviato alla terza parte la volta successiva che l'utente richiederà l'immagine. Ciò significa che la terza parte può sapere che il suo servizio viene utilizzato sul tuo sito e può inviare un cookie, potenzialmente con un ID univoco per tale utente. Ciò significa che la prossima volta che l'utente visita il tuo sito o qualsiasi altro sito che includa una risorsa di quella terza parte, quel cookie dell'ID univoco verrà inviato di nuovo. Ciò consente alla terza parte di creare un log dei luoghi in cui l'utente visita il tuo sito: il tuo sito e altri siti che utilizzano la stessa risorsa di terze parti, su tutto il web.

Si tratta del monitoraggio tra siti: consente a una terza parte di raccogliere un log delle attività di un utente su molti siti web, a condizione che questi ultimi utilizzino tutti una risorsa della stessa terza parte. Potrebbe essere un carattere, un'immagine o un foglio di stile: tutte risorse statiche. Potrebbe anche essere una risorsa dinamica: uno script, un pulsante di social media, un annuncio. Lo script incluso può raccogliere ancora più informazioni in quanto è dinamico: può ispezionare il browser e l'ambiente dell'utente e ritrasmettere i dati all'autore. In una certa misura, qualunque script può farlo, così come le risorse dinamiche che non sono presentate sotto forma di script, come un incorporamento in un social media, un annuncio o un pulsante di condivisione. Se osservi i dettagli di un banner per i cookie sui siti web più visitati, puoi visualizzare un elenco delle organizzazioni che potrebbero aggiungere un cookie di monitoraggio ai tuoi utenti per creare un'immagine delle loro attività e creare un profilo di questo utente. Ce ne possono essere centinaia. Se una terza parte offre un servizio senza costi, un modo per farlo dal punto di vista economico è la raccolta e la monetizzazione di questi dati.

Una guida utile ai tipi di problemi di privacy da cui un browser deve proteggere i propri utenti è il Target Privacy Threat Model. Questo documento è ancora in discussione al momento della stesura di questo documento, ma fornisce alcune classificazioni di alto livello dei tipi di minacce alla privacy esistenti. I rischi derivanti dalle risorse di terze parti sono principalmente il "riconoscimento tra siti indesiderato", in cui un sito web può identificare lo stesso utente su più siti, e la "informativa sensibili", in cui un sito può raccogliere informazioni che un utente considera sensibili.

Questa è una distinzione chiave: il riconoscimento tra siti indesiderato è negativo anche se la terza parte non sta raccogliendo ulteriori informazioni sensibili da quest'ultimo, perché toglie il controllo dell'utente sulla sua identità. L'accesso al referrer e all'indirizzo IP e ai cookie di un utente è un'informativa indesiderata di per sé. L'utilizzo di risorse di terze parti è associato a un componente di pianificazione del modo in cui intendi utilizzarle con un approccio incentrato sulla tutela della privacy. Parte di questo lavoro è di tua competenza di sviluppatore del sito, mentre altre vengono svolte dal browser nel suo ruolo di user agent; in altre parole, l'agente che lavora per conto dell'utente al fine di evitare la divulgazione di informazioni sensibili e il riconoscimento tra siti indesiderato, ove possibile. Di seguito esamineremo più dettagliatamente le mitigazioni e gli approcci a livello di browser e di sviluppo del sito.

Codice di terze parti lato server

La nostra definizione precedente di "terza parte" ha deliberatamente modificato l'approccio lato client dell'almanacco HTTP (come appropriato per il suo report) per includere l'autore di terze parti, perché dal punto di vista della privacy, una terza parte è chiunque conosca qualcosa dei tuoi utenti diversi da te.

Sono inclusi i client e le terze parti che forniscono i servizi da te utilizzati sul server. Dal punto di vista della privacy, è importante comprendere anche una libreria di terze parti (ad esempio una libreria di NPM, Composer o NuGet). Le tue dipendenze trasmettono i dati al di fuori dei tuoi confini? Se passi i dati a un servizio di logging o a un database ospitato in remoto, se le librerie che includi anche "phone home" sono ai loro autori, queste potrebbero violare la privacy degli utenti e pertanto devono essere controllate. I dati utente devono in genere essere trasmessi da una terza parte basata su server, il che significa che i dati a cui è esposto sono maggiormente sotto il tuo controllo. Al contrario, una terza parte basata su client (ovvero uno script o una risorsa HTTP inclusa nel tuo sito web e recuperata dal browser dell'utente) può raccogliere alcuni dati direttamente dall'utente senza che questo processo di raccolta sia mediato da te. La maggior parte di questo modulo sarà incentrata su come identificare le terze parti lato client che hai scelto di includere ed esporre i tuoi utenti, esattamente perché hai meno possibilità di mediazione. Tuttavia, vale la pena valutare la protezione del codice lato server in modo da comprendere le comunicazioni in uscita e registrare o bloccare quelli imprevisti. I dettagli su come procedere esattamente non rientrano nel nostro ambito (e dipendono molto dalla configurazione del server), ma questa è un'altra parte della tua posizione in merito alla sicurezza e alla privacy.

Perché devi prestare attenzione alle terze parti?

Le funzionalità e gli script di terze parti sono molto importanti e il nostro obiettivo, in qualità di sviluppatori web, dovrebbe essere quello di integrare queste funzionalità, non distoglierle. Ma esistono problemi potenziali. I contenuti di terze parti possono creare problemi di prestazioni e di sicurezza perché stai importando un servizio esterno all'interno del tuo confine di attendibilità. Ma i contenuti di terze parti possono anche creare problemi di privacy.

Quando parliamo di risorse di terze parti sul Web, è utile pensare, tra le altre cose, ai problemi di sicurezza che riguardano, tra le altre cose, i casi in cui una terza parte può sottrarre dati dalla tua azienda, e confrontarli con i problemi di privacy, che sono (tra le altre cose) in cui una terza parte da te inclusa ruba o ottiene l'accesso ai dati dei tuoi utenti senza il tuo consenso (o l'utente stesso).

Un esempio di problema di sicurezza è il caso in cui i "web skimmer" rubano i dati delle carte di credito. Una risorsa di terze parti inclusa in una pagina in cui un utente inserisce i dati della carta di credito può, potenzialmente, rubare i dati della carta di credito e inviarli alla terza parte dannosa. Chi crea questi script dello skimmer è molto creativo nel trovare dove nasconderli. Un riepilogo descrive come gli script di skimmer siano stati nascosti nei contenuti di terze parti, ad esempio le immagini utilizzate per i loghi dei siti, i favicon e le reti di social media, le librerie popolari come jQuery, Modernizr e Google Tag Manager, i widget del sito come le finestre di chat dal vivo e i file CSS.

I problemi di privacy sono un po' diversi. Queste terze parti fanno parte della tua offerta. Per mantenere la fiducia degli utenti in te, devi avere la certezza che gli utenti possano fidarsi di loro. Se una terza parte che utilizzi raccoglie dati sui tuoi utenti e poi li utilizza in modo improprio oppure rende difficile l'eliminazione o la scoperta oppure subisce una violazione dei dati o viola le aspettative degli utenti, è probabile che questi ultimi percepiscano questo come un guasto della loro fiducia nei confronti del tuo servizio, non soltanto della terza parte. Si tratta della tua reputazione e del tuo rapporto in linea. Per questo è importante chiederti se ti fidi delle terze parti che stai utilizzando sul tuo sito?

Quali sono alcuni esempi di terze parti?

In generale, stiamo parlando di "terze parti", ma in realtà ne esistono di diversi tipi e con accesso a quantità diverse di dati utente. Ad esempio, se aggiungi un elemento <img> al codice HTML caricato da un server diverso, il server avrà informazioni sui tuoi utenti diverse rispetto all'aggiunta di un elemento <iframe> o di un elemento <script>. Si tratta di esempi e non di un elenco esaustivo, ma è utile capire le differenze tra i diversi tipi di elementi di terze parti che il tuo sito può utilizzare.

Richiesta di una risorsa cross-site

Una risorsa cross-site è qualsiasi elemento sul tuo sito che viene caricato da un altro sito e non è un <iframe> o un <script>. Tra gli esempi ci sono <img>, <audio>, <video>, caratteri web caricati da CSS e texture WebGL. Vengono tutte caricate tramite una richiesta HTTP e, come descritto in precedenza, tali richieste HTTP includeranno tutti i cookie precedentemente impostati dall'altro sito, l'indirizzo IP dell'utente richiedente e l'URL della pagina corrente come referrer. Tutte le richieste di terze parti hanno storicamente incluso questi dati per impostazione predefinita, anche se si sono impegnati a ridurre o isolare i dati trasmessi a terze parti da vari browser, come descritto più avanti nella sezione "Informazioni sulle protezioni dei browser di terze parti".

Incorporamento di un iframe tra siti

Un documento completo incorporato nelle tue pagine tramite un <iframe> può richiedere accesso aggiuntivo alle API del browser, oltre alla suddivisione di cookie, indirizzo IP e referrer. Le API disponibili esattamente per le pagine <iframe> e il modo in cui richiedono l'accesso sono specifiche del browser e sono attualmente in fase di modifica: consulta la sezione "Norme sulle autorizzazioni" di seguito per scoprire gli sforzi attuali per ridurre o monitorare l'accesso alle API nei documenti incorporati.

Esecuzione di JavaScript tra siti in corso...

Se includi un elemento <script>, viene caricato ed eseguito codice JavaScript cross-site nel contesto di primo livello della pagina. Ciò significa che lo script eseguito ha accesso completo a tutto ciò che fanno i tuoi script proprietari. Le autorizzazioni del browser continuano a gestire questi dati, quindi per richiedere la posizione dell'utente (ad esempio), sarà comunque necessario il contratto con l'utente. Tuttavia, qualsiasi informazione presente nella pagina o disponibile come variabili JavaScript può essere letta da uno script di questo tipo, il che include non solo i cookie trasmessi alla terza parte nell'ambito della richiesta, ma anche quelli destinati esclusivamente al tuo sito. Analogamente, uno script di terze parti caricato sulla tua pagina può effettuare le stesse richieste HTTP del tuo codice, il che significa che potrebbe effettuare richieste fetch() alle tue API di backend per ottenere dati.

Inclusione di librerie di terze parti nelle dipendenze

Come descritto in precedenza, è probabile che il codice lato server includa anche dipendenze di terze parti, che sono indistinguibili dal tuo codice nella loro potenza; il codice incluso da un repository GitHub o dalla libreria del tuo linguaggio di programmazione (npm, PyPI, Composer e così via) può leggere tutti gli stessi dati che può leggere l'altro codice.

Conoscere le terze parti

Ciò, quindi, richiede una certa comprensione del tuo elenco di fornitori di terze parti e delle loro norme in materia di privacy, raccolta dei dati e relative all'esperienza utente. Questa comprensione diventa quindi parte della tua serie di compromessi: quanto è utile e importante il servizio, bilanciato rispetto a quanto invadente, sconveniente o inquietante le loro richieste sono per i tuoi utenti. I contenuti di terze parti offrono un valore aggiunto prendendo il lavoro pesante da te in quanto proprietario del sito e ti consentono di concentrarti sulle tue competenze di base. Quindi è importante scendere a questo compromesso e sacrificare il comfort e la privacy degli utenti per un'esperienza utente migliore. Tuttavia, è importante non confondere l'esperienza utente con quella dello sviluppatore, anche se "è più facile per il nostro team di sviluppo creare il servizio" non è una storia avvincente per gli utenti.

Il modo in cui ottieni questa comprensione è il processo di audit.

Controlla le tue terze parti

Comprendere cosa fa una terza parte consiste nel processo di controllo. Puoi eseguire questa operazione sia a livello tecnico che non tecnico, per una singola terza parte e per l'intera collezione.

Eseguire un controllo non tecnico

Il primo passaggio non è di natura tecnica: leggi le norme sulla privacy dei tuoi fornitori. Se includi risorse di terze parti, consulta le norme sulla privacy. Saranno lunghi e pieni di testo legale e alcuni documenti potrebbero utilizzare alcuni degli approcci specificamente segnalati nei primi moduli, ad esempio dichiarazioni eccessivamente generiche e senza alcuna indicazione su come o quando i dati raccolti verranno rimossi. È importante capire che dal punto di vista dell'utente, tutti i dati raccolti sul tuo sito, anche da terze parti, saranno regolati dalle presenti norme sulla privacy. Anche se fai tutto correttamente, quando sei trasparente riguardo ai tuoi obiettivi e superi le aspettative degli utenti in termini di privacy e sensibilità dei dati, gli utenti potrebbero essere responsabili di qualsiasi attività svolta anche dalle terze parti che hai scelto. Se nelle loro norme sulla privacy sono presenti elementi che non vorresti comunicare loro, perché ridurrebbero la fiducia degli utenti, valuta se esiste un altro fornitore.

Questo aspetto può essere utile di pari passo con i controlli tecnici discussi più avanti, poiché si informano a vicenda. È opportuno conoscere le risorse di terze parti che utilizzi per scopi commerciali (ad esempio reti pubblicitarie o contenuti incorporati) in quanto verrà instaurato un rapporto commerciale. È un buon punto di inizio per un controllo non tecnico. È probabile che il controllo tecnico identifichi anche terze parti, in particolare quelle incluse per motivi tecnici anziché aziendali (componenti esterni, analisi, librerie di utilità), che possono essere aggiunte all'elenco di terze parti incentrate sull'attività. L'obiettivo qui è che tu, in qualità di proprietario del sito, abbia la sensazione di capire cosa fanno le terze parti che aggiungi al tuo sito e che tu, in qualità di azienda, sia in grado di presentare al tuo consulente legale questo inventario di terze parti per assicurarti di rispettare gli obblighi richiesti.

Eseguire un controllo tecnico

Per un controllo tecnico, è importante utilizzare le risorse in situ come parte del sito web, ovvero non caricare una dipendenza in un test imbracatura e ispezionarla in questo modo. Assicurati di vedere come le dipendenze agiscono nell'ambito del tuo sito web effettivo, di cui è stato eseguito il deployment sulla rete internet pubblica anziché in modalità di test o sviluppo. È molto istruttivo vedere il proprio sito web come un nuovo utente. Apri un browser in un nuovo profilo pulito, in modo da non aver eseguito l'accesso e non hai alcun contratto archiviato, quindi prova a visitare il sito.

Registrati sul tuo sito per creare un nuovo account, se fornisci account utente. Il tuo team di progettazione avrà orchestrato questo nuovo processo di acquisizione utenti dal punto di vista dell'esperienza utente, ma può essere illustrativo affrontarlo dal punto di vista della privacy. Non limitarti a fare clic su "Accetta" nei Termini e condizioni, sull'avviso relativo ai cookie o sulle norme sulla privacy. Definisci di utilizzare il tuo servizio senza divulgare informazioni personali o usare cookie di monitoraggio e verifica se puoi farlo e quanto è difficile farlo. Può anche essere utile cercare negli strumenti per sviluppatori dei browser per vedere quali siti vengono visitati e quali dati vengono trasmessi a tali siti. Gli Strumenti per sviluppatori forniscono un elenco di richieste HTTP separate (generalmente in una sezione denominata "Rete") e da qui puoi visualizzare le richieste raggruppate per tipo (HTML, CSS, immagini, caratteri, JavaScript, richieste avviate da JavaScript). Puoi anche aggiungere una nuova colonna per mostrare il dominio di ogni richiesta, la quale mostrerà quanti luoghi diversi vengono contattati. Inoltre, potrebbe essere presente una casella di controllo "Richieste di terze parti" per mostrare solo le terze parti. (Può anche essere utile utilizzare i report Content-Security-Policy per eseguire un controllo continuo, di cui parleremo più avanti.)

Lo strumento "Request Map Generator" di Simon Hearne può anche fornire una panoramica utile di tutte le richieste secondarie effettuate da una pagina disponibile pubblicamente.

In questa fase puoi anche includere le terze parti incentrate sulle attività commerciali identificate nell'ambito della revisione non tecnica, ovvero l'elenco delle società con cui hai un rapporto finanziario al fine di utilizzare le loro risorse. L'obiettivo è creare una corrispondenza tra l'elenco di terze parti che ritieni di utilizzare (da documenti finanziari e legali) e l'elenco effettivamente in uso (controllando quali richieste HTTP di terze parti vengono inviate dal tuo sito web). Dovresti riuscire a identificare per ogni terza parte aziendale quali richieste tecniche in uscita vengono effettuate. Se non riesci a identificare le richieste nel controllo tecnico per una terza parte identificata in base a una relazione commerciale, è importante capire il motivo e farti guidare il test: magari quella risorsa di terze parti viene caricata solo in un determinato paese o su un particolare tipo di dispositivo oppure per gli utenti che hanno eseguito l'accesso. In questo modo l'elenco delle aree del sito da controllare verrà ampliato e assicurati di vedere tutti gli accessi in uscita. (o forse identifica una risorsa di terze parti che paghi e non utilizzi, il che fa sempre presa sul reparto finanza.)

Dopo aver ristretto l'elenco delle richieste a terze parti che vorresti sottoporre al controllo, se fai clic su una singola richiesta verranno visualizzati tutti i dettagli della richiesta in questione e, in particolare, quali dati sono stati trasmessi a quella richiesta. Inoltre, molto comunemente, una richiesta di terze parti avviata dal tuo codice poi avvia molte altre richieste di terze parti. Anche queste terze parti aggiuntive vengono "importate" nelle tue norme sulla privacy. Questa attività è laboriosa ma preziosa e spesso può essere inserita nelle analisi esistenti; il team di sviluppo frontend dovrebbe già controllare le richieste per motivi di prestazioni (ad esempio con l'aiuto di strumenti esistenti come WebPageTest o Lighthouse) e l'integrazione di un controllo di dati e privacy in questo processo può semplificare il processo.

La mappa delle richieste web.dev.
Una mappa delle richieste (drammaticamente semplificata) per web.dev, che mostra i siti di terze parti che richiedono altri siti di terze parti e così via.

Cosa fare

Apri un browser con un nuovo profilo utente pulito, in modo da non aver eseguito l'accesso e non abbia un contratto archiviato; quindi apri il riquadro Rete degli strumenti di sviluppo del browser per visualizzare tutte le richieste in uscita. Aggiungi una nuova colonna per visualizzare il dominio di ogni richiesta e seleziona la casella di controllo "Richieste di terze parti" per mostrare solo le terze parti, se presenti. Quindi:

  • Visita il tuo sito.
  • Registrati per creare un nuovo account, se fornisci account utente.
  • Prova a eliminare l'account che hai creato.
  • Esegui una o due normali azioni sul sito (esattamente ciò che avviene dipende dalle operazioni del sito, ma scegli le azioni comuni eseguite dalla maggior parte degli utenti).
  • Esegui una o due azioni che coinvolgano in particolare dipendenze di terze parti. come la condivisione di contenuti sui social media, l'avvio di un flusso di pagamento o l'incorporamento di contenuti da un altro sito.

Quando esegui ognuna di queste attività, crea un record delle risorse richieste da domini non tuoi, esaminando il riquadro Rete come descritto. Queste sono alcune delle tue terze parti. Un buon modo per farlo è utilizzare gli strumenti di rete del browser per acquisire i log delle richieste di rete in un file HAR.

file HAR e acquisizione

Un file HAR è un formato JSON standardizzato di tutte le richieste di rete effettuate da una pagina. Per ottenere un file HAR per una determinata pagina, in:

Chrome

Apri DevTools del browser (Menu > Altri strumenti > Strumenti per sviluppatori), vai al riquadro Rete, carica (o aggiorna) la pagina e scegli il simbolo di salvataggio della Freccia giù in alto a destra, accanto al menu a discesa Nessuna limitazione.

Riquadro di rete Chrome DevTools con il simbolo Scarica HAR evidenziato.
Firefox

Apri gli strumenti per sviluppatori del browser (Menu > Altri strumenti > Strumenti per sviluppatori web), vai al riquadro Rete, carica (o aggiorna) la pagina e scegli il simbolo a forma di ingranaggio in alto a destra accanto al menu a discesa relativo alla limitazione. Dal menu, scegli Save All As HAR** (Salva tutti come HAR).

Riquadro di rete degli strumenti per sviluppatori di Firefox in cui è evidenziata l&#39;opzione Salva tutto con nome.
Safari

Apri gli strumenti per sviluppatori del browser (Menu > Sviluppo > Mostra ispettore web; se non hai un menu Sviluppo, abilitalo da Menu > Safari > Preferenze > Avanzate > Mostra menu Sviluppo nella barra dei menu), accedi al riquadro Rete, carica (o aggiorna) la pagina e scegli Esporta in alto a destra (a destra di Conserva log; potresti dover ingrandire la finestra).

Riquadro Network Inspector di Safari con l&#39;opzione di esportazione HAR evidenziata.

Per ulteriori dettagli, puoi anche registrare ciò che viene trasmesso a terze parti (nella sezione Richiesta), sebbene questi dati siano spesso offuscati e non siano utilmente interpretabili.

Best practice per l'integrazione di terze parti

Puoi impostare le tue norme sulle terze parti utilizzate dal tuo sito: cambiare il fornitore di annunci da utilizzare in base alle loro pratiche, a quanto fastidioso o invadente il popup di consenso all'uso dei cookie è fastidioso o invadente, oppure se vuoi usare pulsanti dei social media sul tuo sito o link di monitoraggio nelle email o link utm_campaign da monitorare in Google Analytics nei tuoi tweet. Un aspetto da considerare durante lo sviluppo di un sito è la strategia di privacy e sicurezza del tuo servizio di analisi. Alcuni servizi di analisi perdono esplicitamente la protezione della privacy. Spesso esistono anche modi per utilizzare uno script di terze parti che aggiunge la protezione della privacy: non sei il primo team a cercare di migliorare la privacy dei propri utenti e proteggerli dalla raccolta di dati di terze parti e potrebbero essere già disponibili soluzioni. Infine, molti provider di terze parti sono più sensibili ai problemi di raccolta dei dati ora rispetto al passato e spesso è possibile aggiungere funzionalità o parametri che consentono una modalità più protezione per gli utenti. Ecco alcuni esempi.

Quando aggiungi un pulsante di condivisione sui social media

Potresti incorporare direttamente i pulsanti HTML: il sito https://sharingbuttons.io/ contiene alcuni esempi ben strutturati. Potresti anche aggiungere link HTML semplici. Il compromesso qui è che perdi la statistica "conteggio condivisioni" e la tua capacità di classificare i tuoi clienti nelle analisi di Facebook. Questo è un esempio di compromesso tra l'utilizzo di un fornitore di terze parti e la ricezione di meno dati di analisi.

Più in generale, quando incorpora un widget interattivo di qualche tipo da una terza parte, spesso è possibile fornire invece un link che rimanda a tale terza parte. Ciò significa che il tuo sito non offre un'esperienza incorporata, ma la decisione di condividere i dati con la terza parte viene spostata da te all'utente, che può scegliere di interagire o meno come preferisce.

Ad esempio, potresti aggiungere link per Twitter e Facebook per condividere il tuo servizio su mysite.example.com, come segue:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Tieni presente che Facebook consente di specificare un URL da condividere, mentre Twitter consente di specificare un URL e del testo.

Quando incorpori un video

Quando incorpori video da siti di hosting di video, cerca nel codice di incorporamento delle opzioni incentrate sulla tutela della privacy. Ad esempio, per YouTube, sostituisci youtube.com nell'URL di incorporamento con www.youtube-nocookie.com per evitare che i cookie di monitoraggio vengano posizionati negli utenti che visualizzano la pagina di incorporamento. Puoi anche selezionare "Abilita modalità di privacy avanzata" quando generi il link Condividi/Incorpora da YouTube. Questo è un buon esempio di utilizzo di una modalità più protettiva per gli utenti fornita dalla terza parte. (https://support.google.com/youtube/answer/171780 la descrive in modo più dettagliato, e altre opzioni di incorporamento per YouTube nello specifico).

Altri siti di video hanno meno opzioni a questo proposito: ad esempio, TikTok, ad esempio, non dispone di un modo per incorporare video senza monitoraggio al momento della stesura di questo articolo. Puoi ospitare i video in autonomia (utilizzando un'alternativa), ma il lavoro potrebbe essere molto più impegnativo, soprattutto se si supporta molti dispositivi.

Come per i widget interattivi illustrati in precedenza, spesso è possibile sostituire un video incorporato con un link al sito web fornito. Questa opzione è meno interattiva perché il video non viene riprodotto in linea, ma lascia la scelta di guardarlo con l'utente. Può essere utilizzato come esempio di "pattern facade", ovvero il nome per la sostituzione dinamica dei contenuti interattivi con un elemento che richiede un'azione da parte dell'utente per l'attivazione. Un video di TikTok incorporato può essere sostituito con un semplice link alla pagina video di TikTok, ma con un po' di lavoro in più è possibile recuperare e visualizzare una miniatura per il video e trasformarla in un link. Anche se il fornitore di video scelto non supporta un modo semplice per incorporare video senza monitoraggio, molti host video supportano oEmbed, un'API che, quando viene fornito un link a un video o a contenuti incorporati, restituisce i dettagli programmatici relativi, ad esempio, una miniatura e un titolo. TikTok supporta oEmbed (visita la pagina https://developers.tiktok.com/doc/embed-videos per maggiori dettagli), il che significa che puoi (manualmente o in modo programmatico) trasformare un link a un video di TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 in metadati JSON relativi al video con https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173, quindi recuperare una miniatura da visualizzare. WordPress utilizza spesso questo metodo per richiedere, ad esempio, informazioni su oEmbed per i contenuti incorporati. Puoi utilizzarla in modo programmatico per mostrare una "facciata" che sembra interattiva e che poi incorpora o collega a un video interattivo quando l'utente sceglie di farci clic sopra.

Quando incorpori gli script di analisi

Analytics è progettato per raccogliere informazioni sui tuoi utenti in modo che possano essere analizzate: è a questo scopo. I sistemi di analisi sono essenzialmente servizi per la raccolta e la visualizzazione dei dati sugli accessi e sugli utenti, che vengono eseguiti su un server di terze parti, come Google Analytics, per facilitare l'implementazione. Esistono anche sistemi di analisi self-hosted come https://matomo.org/, anche se si tratta di un lavoro più impegnativo rispetto all'utilizzo di una soluzione di terze parti. Eseguire un sistema di questo tipo sulla tua infrastruttura ti aiuta a ridurre la raccolta dei dati, perché non lascia il tuo ecosistema. D'altra parte, la gestione dei dati, la loro rimozione e l'impostazione dei relativi criteri sono una tua responsabilità. Gran parte del problema del monitoraggio tra siti si verifica quando questo viene eseguito in modo segreto e nascosto o come effetto collaterale dell'utilizzo di un servizio che non deve necessariamente contenere la raccolta di dati. Il software di analisi è espressamente progettato per raccogliere dati al fine di informare i proprietari dei siti sui propri utenti.

Storicamente, c'è stato un approccio di raccolta di tutti i dati possibili su tutto, come una rete da pesca gigante, per poi analizzarli in seguito alla ricerca di schemi interessanti. Questa mentalità ha, in gran parte, creato un senso di inquietudine e di inquietudine nei confronti della raccolta dei dati di cui si è parlato nella prima parte di questo corso. Molti siti individuano innanzitutto le domande da porre, quindi raccolgono dati specifici e limitati per rispondere a queste domande.

Se un servizio di terze parti viene utilizzato dal tuo sito e da altri siti e funziona includendo il relativo codice JavaScript nel tuo sito e impostando i cookie per ogni utente, è importante tenere presente che tale servizio potrebbe effettuare un riconoscimento tra siti indesiderato, ovvero il monitoraggio degli utenti tra i siti. Alcuni potrebbero e altri no, ma la posizione per la tutela della privacy qui è presumere che un servizio di terze parti in questione stia effettivamente eseguendo il monitoraggio tra siti, a meno che tu non abbia un valido motivo per pensare o sapere diversamente. Questo non è di per sé un motivo per evitare questi servizi, ma è un aspetto da considerare nella tua valutazione dei compromessi relativi al loro utilizzo.

Un tempo il compromesso nell'analisi era unicamente per la scelta se usarli o meno: raccogliere tutti i dati e compromettere la privacy in cambio di approfondimenti e pianificazione, oppure di rinunciare completamente alle informazioni. Tuttavia, non è più così e spesso c'è una via di mezzo tra questi due estremi. Verifica le opzioni di configurazione del tuo provider di analisi per limitare i dati raccolti e ridurre la quantità e la durata del suo spazio di archiviazione. Poiché disponi dei record del controllo tecnico descritto in precedenza, puoi eseguire nuovamente le sezioni pertinenti del controllo per confermare che la modifica di queste configurazioni riduca effettivamente la quantità di dati raccolti. Se stai effettuando questa transizione su un sito esistente, questo può fornirti una misura quantificabile di cui puoi parlare per i tuoi utenti. Ad esempio, Google Analytics offre una serie di funzionalità per la privacy attivabili (quindi disattivate per impostazione predefinita), molte delle quali possono essere utili per rispettare le leggi locali in materia di protezione dei dati. Alcune opzioni da considerare durante la configurazione di Google Analytics includono l'impostazione di un periodo di conservazione dei dati raccolti (Amministrazione > Informazioni di monitoraggio > Conservazione dei dati) inferiore al valore predefinito di 26 mesi e l'attivazione di alcune soluzioni più tecniche, come l'anonimizzazione parziale degli indirizzi IP (per maggiori dettagli, consulta la pagina https://support.google.com/analytics/answer/9019185).

Utilizzo di terze parti con modalità incentrate sulla tutela della privacy

Finora abbiamo discusso di come proteggere gli utenti da terze parti durante la fase di progettazione dell'applicazione, mentre stai pianificando lo scopo dell'applicazione. La decisione di non utilizzare una determinata terza parte è parte integrante di questa pianificazione e anche il controllo dell'utilizzo rientra in questa categoria, che consiste nel prendere decisioni in merito alla tua posizione di privacy. Tuttavia, queste decisioni intrinsecamente non sono molto granulari; la scelta di ricorrere a una determinata terza parte o di non farlo non è una decisione complessa. È molto più probabile che tu voglia qualcosa di mezzo: avere bisogno o pianificare l'utilizzo di una determinata offerta di terze parti, ma attenuare qualsiasi tendenza che violi la privacy (intenzionale o accidentale). Si tratta del compito di proteggere gli utenti durante la fase di creazione, ovvero aggiungere misure di salvaguardia per ridurre i danni che non avevi previsto. Tutte queste sono nuove intestazioni HTTP che puoi fornire durante la pubblicazione delle pagine e che suggeriscono o comanderanno allo user agent di adottare determinate misure di privacy o sicurezza.

Norme sui referrer

Cosa fare

Imposta un criterio di strict-origin-when-cross-origin o noreferrer per impedire ad altri siti di ricevere un'intestazione referrer quando ti colleghi a questi siti o quando vengono caricati come risorse secondarie da una pagina:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

Oppure lato server, ad esempio in Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Se necessario, imposta criteri meno stringenti su richieste o elementi specifici.

Perché protegge la privacy degli utenti

Per impostazione predefinita, ogni richiesta HTTP inviata dal browser passa su un'intestazione Referer che contiene l'URL della pagina che ha avviato la richiesta, che si tratti di un link, di un'immagine incorporata o di uno script. Questo può costituire un problema di privacy perché gli URL possono contenere informazioni private e gli URL messi a disposizione di terze parti trasferiscono queste informazioni private. Web.dev elenca alcuni esempi di URL contenenti dati privati: sapendo che un utente è arrivato sul tuo sito da https://social.example.com/user/me@example.com, ti dice chi è, il che costituisce una fuga di informazioni. Ma anche un URL che non espone di per sé informazioni private espone che l'utente in questione (che potresti conoscere, se ha eseguito l'accesso) è arrivato qui da un altro sito e questo rivela, pertanto, che l'utente ha visitato l'altro sito. Si tratta di un'esposizione di informazioni che forse non dovresti conoscere sulla cronologia di navigazione dell'utente.

Specificare un'intestazione Referrer-Policy (con l'ortografia corretta) ti consente di modificare questa impostazione, in modo che l'URL di riferimento non venga trasmesso parzialmente o in parte. MDN elenca i dettagli completi, ma la maggior parte dei browser ha ora adottato un valore presunto di strict-origin-when-cross-origin per impostazione predefinita, il che significa che l'URL del referrer viene ora trasmesso a terze parti solo come origine (https://web.dev anziché https://web.dev/learn/privacy). Questa è un'utile protezione della privacy senza che devi fare nulla. Tuttavia, puoi perfezionare ulteriormente questo aspetto specificando Referrer-Policy: same-origin per evitare di trasmettere informazioni sui referrer a terze parti (oppure Referrer-Policy: no-referrer per evitare la trasmissione a chiunque, compresa la tua origine). Questo è un buon esempio di equilibrio tra privacy e utilità. La nuova impostazione predefinita garantisce maggiore tutela della privacy rispetto a prima, ma fornisce comunque informazioni di alto livello a terze parti scelte da te, ad esempio il tuo provider di analisi.

È utile anche specificare esplicitamente questa intestazione, perché in questo modo sai esattamente di cosa si tratta, invece di fare affidamento sulle impostazioni predefinite del browser. Se non riesci a impostare le intestazioni, puoi impostare una norma referrer per un'intera pagina HTML utilizzando un meta elemento in <head>: <meta name="referrer" content="same-origin">; se riguarda terze parti specifiche, è anche possibile impostare un attributo referrerpolicy su singoli elementi come <script>, <a> o <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Norme sulla sicurezza dei contenuti

L'intestazione Content-Security-Policy, spesso definita "CSP", determina da dove è possibile caricare le risorse esterne. Viene utilizzato principalmente per motivi di sicurezza, impedendo attacchi cross-site scripting e script injection, ma se utilizzato insieme ai regolari controlli, può anche limitare le destinazioni a cui le terze parti che hai scelto possono trasferire i dati.

Questa è potenzialmente un'esperienza utente non ottimale; se uno degli script di terze parti inizia a caricare una dipendenza da un'origine non presente nel tuo elenco, la richiesta verrà bloccata, lo script avrà esito negativo e la tua applicazione potrebbe generare un errore (o almeno essere ridotta alla sua versione di riserva con errore JavaScript). Questo è utile quando CSP viene implementato per la sicurezza, ovvero il suo scopo normale: proteggere da problemi di cross-site scripting (e, per farlo, utilizza un CSP rigoroso). Una volta che conosci tutti gli script incorporati utilizzati dalla tua pagina, puoi stilarne un elenco, calcolare un valore hash o aggiungere un valore casuale (chiamato "nonce") per ciascuno e poi aggiungere l'elenco di hash ai tuoi criteri di sicurezza del contenuto. In questo modo, gli script non presenti nell'elenco non verranno caricati. Questo deve essere integrato nel processo di produzione del sito: gli script delle pagine devono includere il nonce o avere un hash calcolato come parte della build. Per tutti i dettagli, consulta l'articolo sul livello rigido del fornitore di servizi.

Fortunatamente, i browser supportano un'intestazione correlata, Content-Security-Policy-Report-Only. Se viene fornita questa intestazione, le richieste che violano il criterio indicato non verranno bloccate, ma verrà inviato un report JSON a un URL fornito. Un'intestazione di questo tipo potrebbe essere simile alla seguente: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/ e, se il browser carica uno script da una qualsiasi località diversa da 3p.example.com, la richiesta avrà esito positivo, ma verrà inviato un report al report-uri fornito. Normalmente viene utilizzato per sperimentare un criterio prima di implementarlo, ma un'idea utile qui è utilizzarlo come un modo per eseguire un "controllo continuo". Oltre al normale controllo descritto in precedenza, puoi attivare i report CSP per vedere se vengono visualizzati domini imprevisti, il che potrebbe significare che le risorse di terze parti caricano risorse di terze parti proprie e che devi prendere in considerazione e valutare. (Può anche essere un segnale di exploit cross-site scripting che sono sfuggiti al limite di sicurezza, di cui è importante essere a conoscenza).

Content-Security-Policy è un'API complessa e complicata da usare. Questo è noto e stiamo lavorando per costruire la "nuova generazione" di CSP, che soddisferà gli stessi obiettivi, ma non sarà così complicato da usare.Non è ancora tutto pronto, ma se vuoi sapere a che punto si sta dirigendo la modifica (o se vuoi contribuire alla sua progettazione), consulta la pagina https://github.com/WICG/csp-next per i dettagli.

Cosa fare

Aggiungi questa intestazione HTTP alle pagine pubblicate: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. Archivialo quando viene pubblicato il codice JSON in quell'URL. Esamina i dati archiviati per raccogliere i domini di terze parti richiesti dal tuo sito web quando viene visitato da altri. Aggiorna l'intestazione Content-Security-Policy-Report-Only per elencare i domini previsti per vedere quando viene modificato l'elenco:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

Perché

Questo fa parte del controllo tecnico, in modo continuativo. Il controllo tecnico iniziale che hai eseguito ti fornirà un elenco delle terze parti che il tuo sito condivide o a cui trasmette i dati utente. Questa intestazione consentirà quindi alle richieste di pagina di indicare quali terze parti sono state contattate e potrai monitorare le modifiche nel tempo. In questo modo, non solo ti vengono segnalate le modifiche apportate da terze parti esistenti, ma vengono segnalate anche le terze parti aggiunte di recente che non sono state aggiunte al controllo tecnico. È importante aggiornare l'intestazione per interrompere la generazione di report sui domini previsti, ma è anche importante ripetere di tanto in tanto il controllo tecnico manuale (perché l'approccio Content-Security-Policy non segnala quali dati vengono passati, ma solo che è stata effettuata una richiesta).

Tieni presente che non è necessario aggiungerlo alle pagine pubblicate ogni volta o a ogni pagina. Ottimizza il numero di risposte di pagina che ricevono l'intestazione in modo da ricevere un campione rappresentativo di report non eccessivamente numerosi.

Norme relative alle autorizzazioni

L'intestazione Permissions-Policy (introdotta con il nome Feature-Policy) ha un concetto simile a Content-Security-Policy, ma limita l'accesso a potenti funzionalità del browser. Ad esempio, è possibile limitare l'uso dell'hardware del dispositivo come accelerometro, fotocamera o dispositivi USB oppure limitare le funzionalità non hardware, come l'autorizzazione allo schermo intero o all'uso di XMLHTTPRequest sincroni. Queste limitazioni possono essere applicate a una pagina di primo livello (per evitare che gli script caricati tentino di utilizzare queste funzionalità) o alle pagine con frame secondario caricate tramite un iframe. Questa restrizione all'utilizzo delle API non riguarda in realtà il fingerprinting del browser; significa impedire a terze parti di eseguire operazioni invasive (come l'utilizzo di API potenti, la visualizzazione di finestre di autorizzazione popup e così via). Questo viene definito dal Target Privacy Threat Model come "intrusione".

Un'intestazione Permissions-Policy è specificata come elenco di coppie (funzionalità, origini consentite), pertanto:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

Questo esempio consente a questa pagina ("self") e a <iframe> dell'origine example.com di utilizzare le API navigator.geolocation da JavaScript; consente a questa pagina e a tutti i frame secondari di utilizzare l'API a schermo intero e impedisce a qualsiasi pagina, inclusa questa pagina, di utilizzare una fotocamera per leggere le informazioni dei video. Trovi molti altri dettagli e un elenco di potenziali esempi qui.

L'elenco di funzionalità gestite dall'intestazionePermissions-Policy è molto lungo e potrebbe essere in continua evoluzione. Attualmente l'elenco viene gestito all'indirizzo https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

Cosa fare

I browser che supportano Permissions-Policy non consentono per impostazione predefinita funzionalità efficaci nei frame secondari e devi agire per attivarle. Questo approccio è privato per impostazione predefinita. Se ritieni che i frame secondari sul tuo sito richiedano queste autorizzazioni, puoi aggiungerli selettivamente. Tuttavia, per impostazione predefinita, alla pagina principale non vengono applicati criteri relativi alle autorizzazioni, quindi agli script (inclusi gli script di terze parti) caricati dalla pagina principale non viene impedito di utilizzare queste funzionalità. Per questo motivo è utile applicare un elemento Permissions-Policy restrittivo a tutte le pagine per impostazione predefinita e poi aggiungere gradualmente le funzionalità richieste dalle pagine.

Esempi di potenti funzionalità interessate da Permissions-Policy includono la richiesta della posizione dell'utente, l'accesso ai sensori (inclusi accelerometro, giroscopio e magnetometro), l'autorizzazione per la visualizzazione a schermo intero e la richiesta di accesso alla fotocamera e al microfono dell'utente. L'elenco completo (in continua evoluzione) delle funzionalità è disponibile al link qui sopra.

Purtroppo, per bloccare tutte le funzionalità per impostazione predefinita e poi riautorizzarle selettivamente, è necessario elencare tutte le funzionalità nell'intestazione, il che può sembrare piuttosto inelegante. Ciononostante, un'intestazione Permissions-Policy di questo tipo è un buon punto di partenza. permissionspolicy.com/ ha un generatore di intestazione molto pratico per poter creare un'intestazione di questo tipo: se la utilizzi per creare un'intestazione che disattivi tutte le funzionalità, si verifica quanto segue:

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Informazioni sulle funzionalità di privacy integrate nei browser web

Oltre alle protezioni in fase di creazione e progettazione, sono disponibili anche protezioni della privacy in fase di esecuzione, ovvero funzionalità per la privacy implementate nei browser stessi per proteggere gli utenti. Non si tratta di funzionalità che puoi controllare direttamente o a cui puoi attingere in qualità di sviluppatore di siti, ma sono funzionalità di prodotto. Tuttavia, si tratta di funzionalità che dovresti conoscere, perché queste decisioni sui prodotti nei browser potrebbero influire sui tuoi siti. Per fare un esempio del modo in cui queste protezioni del browser possono influire sul tuo sito, se è presente codice JavaScript lato client che attende il caricamento di una dipendenza di terze parti prima di continuare con la configurazione della pagina e questa dipendenza di terze parti non viene mai caricata, la configurazione della pagina potrebbe non essere mai completata e quindi all'utente viene visualizzata una pagina semicaricata.

tra cui la funzionalità Intelligent Tracking Prevention in Safari (e il motore WebKit sottostante) e la protezione antitracciamento avanzata in Firefox (e il suo motore, Gecko). Tutto questo rende difficile per terze parti creare profili dettagliati dei tuoi utenti.

L'approccio del browser alle funzionalità di privacy cambia di frequente ed è importante rimanere aggiornati; il seguente elenco di protezioni è corretto al momento della scrittura. I browser possono anche implementare altre protezioni; questi elenchi non sono esaustivi. Consulta il modulo sulle best practice per scoprire come stare al passo con le modifiche qui e assicurati di eseguire test con le versioni future del browser per rilevare eventuali modifiche che potrebbero interessare i tuoi progetti. Tieni presente che le modalità di navigazione in incognito/privata a volte implementano impostazioni diverse da quelle predefinite del browser (ad esempio, in queste modalità i cookie di terze parti potrebbero essere bloccati per impostazione predefinita). Pertanto, i test in modalità di navigazione in incognito potrebbero non riflettere sempre l'esperienza di navigazione tipica della maggior parte degli utenti, se non utilizzano la navigazione privata. Tieni inoltre presente che il blocco dei cookie in varie situazioni può comportare il blocco anche di altre soluzioni di archiviazione, ad esempio window.localStorage, non solo dei cookie.

Chrome

  • I cookie di terze parti sono destinati a essere bloccati in futuro. Al momento della stesura di questo messaggio, non sono bloccati per impostazione predefinita (ma questa impostazione può essere attivata da un utente): https://support.google.com/chrome/answer/95647 illustra i dettagli.
  • Le funzionalità per la privacy di Chrome, in particolare quelle di Chrome che comunicano con Google e i servizi di terze parti, sono descritte all'indirizzo privacysandbox.com/.

Perimetrale

  • I cookie di terze parti non sono bloccati per impostazione predefinita (ma questa impostazione può essere attivata da un utente).
  • La funzionalità Prevenzione del monitoraggio di Edge blocca i tracker dei siti non visitati e i tracker dannosi noti sono bloccati per impostazione predefinita.

Firefox

Per informazioni su cosa potrebbe essere bloccato e per facilitare il debug dei problemi, fai clic sull'icona a forma di scudo nella barra degli indirizzi o visita la pagina about:protections in Firefox (su computer).

Safari

  • I cookie di terze parti sono bloccati per impostazione predefinita.
  • Nell'ambito della sua funzionalità Intelligent Tracking Prevention, Safari riduce il referrer trasmesso ad altre pagine come sito di primo livello anziché come pagina specifica: (https://something.example.com, invece di https://something.example.com/this/specific/page).
  • I dati del browser localStorage vengono eliminati dopo sette giorni.

(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ riassume queste funzionalità).

Per ottenere informazioni su ciò che potrebbe essere bloccato e per facilitare il debug dei problemi, abilita la "modalità di debug di Intelligent Tracking Prevention" nel menu sviluppatori di Safari (su computer). Per maggiori dettagli, visita la pagina https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/.

Proposte API

Perché abbiamo bisogno di nuove API?

Le nuove funzionalità e norme nei prodotti browser, che garantiscono la tutela della privacy, contribuiscono a tutelare la privacy degli utenti, ma presentano anche delle sfide. Molte tecnologie web sono utilizzabili per il monitoraggio tra siti nonostante siano state progettate e utilizzate per altri scopi. Ad esempio, molti sistemi di federazione delle identità che utilizziamo quotidianamente si basano su cookie di terze parti. Molte soluzioni pubblicitarie su cui gli editori fanno affidamento oggi per generare entrate si basano sui cookie di terze parti. Molte soluzioni di rilevamento di attività fraudolente si basano sul fingerprinting. Cosa succede a questi casi d'uso quando i cookie di terze parti e il fingerprinting scompaiono?

Sarebbe difficile e soggetto a errori per i browser distinguere i casi d'uso e distinguere in modo affidabile gli usi che violano la privacy dagli altri. Questo è il motivo per cui la maggior parte dei principali browser ha bloccato i cookie di terze parti e il fingerprinting, oppure intende farlo, al fine di proteggere la privacy degli utenti.

È necessario un nuovo approccio: man mano che i cookie di terze parti vengono gradualmente eliminati e il fingerprinting viene ridotto, gli sviluppatori hanno bisogno di API create appositamente, che soddisfino i casi d'uso (che non sono scomparse), ma sono progettate nel rispetto della privacy. L'obiettivo è progettare e creare API che non possono essere usate per il monitoraggio tra siti. A differenza delle funzionalità dei browser descritte nella sezione precedente, queste tecnologie aspirano a diventare API cross-browser.

Esempi di proposte API

L'elenco che segue non è esaustivo: è solo un assaggio di alcuni degli argomenti di cui si è parlato.

Esempi di proposte API per sostituire le tecnologie basate su cookie di terze parti:

Esempi di proposte API per sostituire le tecnologie basate sul monitoraggio passivo:

Esempi di altre proposte su cui possono basarsi altre API in futuro senza cookie di terze parti:

Inoltre, sta emergendo un altro tipo di proposta API per cercare di attenuare finora il monitoraggio nascosto specifico del browser. Un esempio è Privacy Budget. In questi vari casi d'uso, le API proposte inizialmente da Chrome risiedono nel termine generale Privacy Sandbox.

Global-Privacy-Control è un'intestazione che intende comunicare a un sito che l'utente desidera che i dati personali raccolti non vengano condivisi con altri siti. Il suo scopo è simile a Do Not Track, che non è più disponibile.

Stato delle proposte API

La maggior parte di queste proposte API non è ancora stata implementata oppure viene eseguita solo dietro flag o in ambienti limitati per la sperimentazione.

Questa fase di incubazione pubblica è importante: i fornitori di browser e gli sviluppatori raccolgono discussioni ed esperienze per stabilire se queste API sono utili e se fanno effettivamente ciò per cui sono state progettate. Sviluppatori, fornitori di browser e altri soggetti dell'ecosistema utilizzano questa fase per eseguire l'iterazione del design dell'API.

Il modo migliore per tenerti al corrente sulle nuove API proposte è attualmente l'elenco di proposte del gruppo Privacy su GitHub.

Hai bisogno di utilizzare queste API?

Se il tuo prodotto è basato direttamente su cookie o tecniche di terze parti come il fingerprinting, dovresti partecipare a queste nuove API, sperimentarle e contribuire con le tue esperienze alle discussioni e alla progettazione delle API. In tutti gli altri casi, non è necessario conoscere tutti i dettagli su queste nuove API al momento della stesura di questo documento, ma è bene essere a conoscenza delle novità in arrivo.