Terze parti

È piuttosto raro che un sito web sia del tutto indipendente. HTTP Web Almanac mostra che la maggior parte dei siti web, circa il 95%, include alcuni contenuti di terze parti.

Per The Almanac i contenuti di terze parti sono definiti come contenuti ospitati su un'origine pubblica e condivisa, ampiamente utilizzato da una varietà di siti e non è influenzato da un singolo proprietario del sito. Possono essere immagini o altri contenuti multimediali come video, caratteri o script. Le immagini e gli script rappresentano più di tutto il resto. I contenuti di terze parti non sono essenziali per lo sviluppo di un sito, ma potrebbe esserlo: è quasi certo che utilizzerai qualcosa di caricato da un server condiviso pubblico, che si tratti di caratteri web, iframe incorporati di video, annunci o librerie JavaScript. Ad esempio, potresti usare i caratteri web pubblicati da Google Fonts, o misurare dati e analisi con Google Analytics; potresti aver aggiunto pulsanti Mi piace o Accedi con dai social network; potresti incorporare mappe o video, oppure gestire gli acquisti tramite servizi di terze parti; è possibile che tu stia monitorando errori il logging per i tuoi team di sviluppo tramite strumenti di monitoraggio di terze parti.

Per motivi di privacy, è utile prendere in considerazione una definizione leggermente diversa e meno generica: risorsa di terze parti, mentre particolare uno script di terze parti, è fornito da un'origine condivisa e pubblica e ampiamente usato come illustrato, ma è anche autore da parte di un utente diverso dal proprietario del sito. L'aspetto dell'attribuzione dei contenuti di terze parti è l'aspetto fondamentale quando si valuta come proteggere i propri utente la privacy altrui. Questo ti porterà a valutare quali sono i rischi e a decidere come o se utilizzare un risorsa di terze parti in base a questi rischi. Come già detto, questi aspetti ti aiuteranno a comprendere il contesto e per capire quali compromessi devi fare e cosa significano.

Non è esattamente ciò di cui si parla quando si parla di "risorse di terze parti" in generale: la distinzione tra proprietari e la terza parte riguarda in realtà il contesto in cui viene usato qualcosa. Uno script caricato da un altro sito web è uno script di terze parti e la richiesta HTTP che carica lo script potrebbe includere cookie, ma in realtà questi cookie non sono "cookie di terze parti"; sono solo cookie e sono di "terze parti" o "proprietari" dipende dal fatto che lo script venga caricato su una pagina del tuo sito o una pagina sul sito 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 invisibili funzioni per sviluppatori, come il monitoraggio degli errori, ma riducono il carico per lo sviluppo e gli script stessi vengono mantenuti da un altro utente, ovvero il team di sviluppo del servizio che hai incluso. Tutto questo funziona grazie alla componibilità del web: essere in grado di unire le parti per formare un tutto maggiore della loro somma.

Web Almanac di HTTP Archive fornisce una bella descrizione:

Le terze parti offrono una raccolta infinita di immagini, video caratteri, strumenti, librerie, widget, tracker, annunci e qualsiasi altra cosa si possa immaginare incorporando nelle nostre pagine web. Ciò consente anche i più non tecnici in grado di creare e pubblicare contenuti sul web. Senza terze parti, il web probabilmente una piattaforma accademica molto noiosa, basata su testi, al posto di una piattaforma ricca, immersiva e complessa che è parte integrante delle vite di molti di noi oggi.

Che 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 di un altro sito, la richiesta HTTP effettuata dal browser dell'utente trasmetterà a un referer con l'URL della 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 essere rimandato alla terza parte quando l'utente richiederà nuovamente l'immagine. Ciò significa che la terza parte può sapere che la sua è in uso sul tuo sito e può inviare un cookie, potenzialmente con un ID univoco per quell'utente. Ciò significa che La volta successiva che l'utente visita il tuo sito o qualsiasi altro sito che includa una risorsa di quella terza parte, l'unico Il cookie dell'ID verrà inviato di nuovo. In questo modo, la terza parte può creare un log dei luoghi visitati dall'utente: il tuo sito, altri siti che usano la stessa risorsa di terze parti su tutto il web.

Si tratta del monitoraggio tra siti, che consente a una terza parte di raccogliere un log dell'attività di un utente su molti siti web, a condizione che Tutti i siti web utilizzano una risorsa proveniente dalla stessa terza parte. Può trattarsi di un carattere, un'immagine o un foglio di stile: tutte risorse statiche. Potrebbe anche essere una risorsa dinamica: uno script, un pulsante per un social media o un annuncio. Lo script incluso può raccogliere ancora più dati perché sono dinamiche: possono esaminare il browser e l'ambiente dell'utente e ritrasmetterli all'origine. Qualsiasi script può farlo in una certa misura, così come le risorse dinamiche che non sono presenti come script, come un incorporamento di social media o un annuncio o un pulsante di condivisione. Se osservi i dettagli di un banner dei cookie sui siti web più visitati, puoi vedere un elenco delle organizzazioni che potrebbero aggiungere un cookie di monitoraggio agli utenti per creare un'immagine delle loro attività al fine di creare un profilo per quegli utenti. Là possono essere centinaia. Se una terza parte offre un servizio senza costi, un modo per poterlo fare economicamente di è che raccolgono e monetizzano 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. Si tratta di un documento ancora in discussione al momento della stesura, ma fornisce alcune classificazioni di alto livello di tipi di di eventuali minacce alla privacy. I rischi derivanti da risorse di terze parti sono principalmente un "riconoscimento tra siti indesiderato", in cui un sito web può identificare lo stesso utente su più siti e "divulgare informazioni sensibili", laddove un sito può raccogliere le informazioni che un utente considera sensibili.

Questa è una distinzione fondamentale: il riconoscimento tra siti indesiderato è negativo anche se la terza parte non sta raccogliendo informazioni sensibili aggiuntive perché sottrae il controllo dell'utente sulla propria identità. Ottenere l'accesso al referrer e all'indirizzo IP di un utente e cookie è di per sé un'informativa indesiderata. L'utilizzo di risorse di terze parti comporta anche una componente di pianificazione delle modalità di utilizzo in modo da garantire la tutela della privacy. Parte del lavoro è di tua competenza in qualità di sviluppatore del sito, mentre un'altra viene svolta dal browser. nel suo ruolo di user agent; ovvero l'agente lavora per conto dell'utente per evitare la divulgazione di informazioni sensibili e il riconoscimento tra siti indesiderato, ove possibile. Di seguito esamineremo più in dettaglio le mitigazioni e gli approcci su un browser e a un livello di sviluppo del sito.

Codice di terze parti lato server

La nostra precedente definizione di terza parte ha deliberatamente modificato l'approccio lato client di HTTP Almanac (secondo il caso per il report!), per includere l'attribuzione di contenuti di terze parti, perché dal punto di vista della privacy, una terza parte è chiunque sappia qualcosa. sugli utenti che non sono tu.

Sono incluse le terze parti che forniscono i servizi che utilizzi sul server, nonché il client. Da un profilo punto di vista, una libreria di terze parti (come un elemento incluso da NPM, Composer o NuGet) è importante da capire. Le tue dipendenze trasmettono dati al di fuori dei confini? Se passi i dati a un servizio di logging o a un database ospitato in remoto, se nelle raccolte includi anche "telefono home" ai loro autori, questi contenuti potrebbero violare le norme privacy e perciò devono essere controllati. Generalmente i dati utente devono essere trasferiti da una terza parte basata su server, il che significa i dati a cui è esposto sono più sotto il tuo controllo. Al contrario, una terza parte basata sul client, ovvero uno script o una risorsa HTTP inclusi nel tuo sito web e recuperati dal browser dell'utente, puoi raccogliere alcuni dati direttamente dall'utente senza questa procedura. di raccolta mediata da te. La maggior parte di questo modulo riguarderà come identificare queste terze parti lato client che hai scelto di includere ed esporre gli utenti, esattamente perché la mediazione è minore possibile per te. Ma vale la pena prendere in considerazione la possibilità di proteggere il codice lato server in modo da comprendere le comunicazioni in uscita che lo inviano e registrare o bloccare quelle inaspettate. I dettagli su come effettuare esattamente questa operazione non rientrano nel nostro ambito (e dipendono molto dalla configurazione del server), ma anche questa è un'altra parte della tua posizione in materia di sicurezza e privacy.

Perché occorre prestare attenzione alle terze parti?

Gli script e le funzionalità di terze parti sono molto importanti e il nostro obiettivo, come sviluppatori web, dovrebbe essere quello di integrarli, per non allontanarsi da loro! Esistono però dei problemi potenziali. I contenuti di terze parti potrebbero creare problemi di prestazioni e possono creano problemi di sicurezza anche perché stai importando un servizio esterno all'interno del tuo confine di attendibilità. Ma le terze parti contenuti possono anche creare problemi di privacy.

Quando parliamo di risorse di terze parti sul web, è utile pensare ai problemi di sicurezza, tra le altre cose. in cui una terza parte può rubare dati dalla tua azienda e in contrasto con i problemi di privacy, che sono, tra le altre cose, i casi in cui la terza parte che hai incluso ruba o ottiene l'accesso ai dati dei tuoi utenti senza il tuo consenso.

Un esempio di problema di sicurezza è rappresentato dagli "skimmer web" rubare 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, potrebbe, potenzialmente, sottrarli e inviarli a la terza parte dannosa. Coloro che creano questi script skimmer sono molto creativi nell'elaborare dei punti per nasconderli. Un riepilogo descrive come gli script skimmer Sono stati nascosti in contenuti di terze parti, come le immagini utilizzate per i loghi dei siti, le favicon e le reti di social media, librerie note come jQuery, Modernizr e Google Tag Manager, widget di siti come finestre di chat live e file CSS.

I problemi di privacy sono leggermente diversi. Queste terze parti fanno parte della tua offerta. per mantenere il controllo devi avere la certezza che gli utenti possano fidarsi di loro. Se la terza parte che utilizzi raccoglie dati su i tuoi utenti e quindi ne fa un uso improprio, oppure rende difficile l'eliminazione o il rilevamento, subisce una violazione dei dati o viola le le aspettative dei tuoi utenti, probabilmente lo percepiranno come un'analisi dettagliata della fiducia che ripongono nel tuo servizio e non solo di terze parti. Sono la tua reputazione e la tua relazione in linea. Per questo è importante chiederti se ti fidi le terze parti che stai utilizzando sul tuo sito?

Quali sono alcuni esempi di terze parti?

Stiamo parlando di "terze parti" in generale, ma in realtà esistono tipi diversi e hanno accesso a quantità diverse di dati utente. Ad esempio, l'aggiunta di un elemento <img> al codice HTML, caricato da un server diverso, fornirà al server informazioni diverse sui tuoi utenti rispetto all'aggiunta di un elemento <iframe> o di un elemento <script>. Si tratta di esempi più che di un elenco completo, per capire le differenze tra i diversi tipi di elementi di terze parti che possono essere utilizzati sul tuo sito.

Richiesta di una risorsa tra siti

Una risorsa cross-site è qualsiasi elemento sul tuo sito caricato da un sito diverso e che non sia <iframe> o <script>. Esempi includono <img>, <audio>, <video>, caratteri web caricati da CSS e texture WebGL. Questi vengono caricati tramite una richiesta HTTP e, descritti in precedenza, queste richieste HTTP includeranno gli eventuali 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 in passato includevano questi dati per impostazione predefinita, sebbene ci sono sforzi per ridurre o isolare i dati trasmessi a terze parti da vari browser, come descritto nella sezione Protezioni del browser di terze parti più avanti.

Incorporare un iframe tra siti

Un documento completo incorporato nelle tue pagine tramite un <iframe> può richiedere accesso aggiuntivo alle API del browser, oltre alla di cookie, indirizzo IP e referrer. Esattamente quali API sono disponibili per le <iframe>pagine e le modalità di richiesta di accesso sono specifiche per il browser. ed è attualmente in fase di modifica, consulta le "Norme sulle autorizzazioni" di seguito per gli attuali sforzi per ridurre o monitorare l'accesso API nelle documenti.

Esecuzione di JavaScript tra siti

L'inclusione di un elemento <script> consente di caricare ed eseguire JavaScript cross-site nel contesto di primo livello della pagina. Ciò significa che eseguito ha accesso completo a tutto ciò che fanno i tuoi script proprietari. Le autorizzazioni del browser continuano a gestire questi dati pertanto, per richiedere la posizione dell'utente (ad esempio), sarà comunque necessario il contratto con l'utente. Ma qualsiasi informazione presente nella pagina o disponibili perché le variabili JavaScript possono essere lette da uno script di questo tipo, e questo include non solo i cookie che vengono passati alla terza parte nell'ambito della richiesta, ma anche i cookie destinati esclusivamente al tuo sito. Analogamente, uno script di terze parti caricato può effettuare le stesse richieste HTTP del tuo codice, il che significa che potrebbe effettuare richieste fetch() alle tue API 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 non sono distinguibili dalle tue il codice in loro potere; che includi da un repository GitHub o dalla libreria del tuo linguaggio di programmazione (npm, PyPI, Composer e così via) leggere gli stessi dati dell'altro codice.

Conoscere le terze parti

A questo punto, è necessario comprendere il tuo elenco di fornitori di terze parti e la loro privacy, la raccolta dei dati e i dati le posizioni e le norme relative all'esperienza. Questa comprensione diventa quindi parte dei tuoi compromessi: quanto utile e importante è il servizio, bilanciato in base a quanto le loro richieste siano invadenti, scomodi o inquietanti per gli utenti. Di terze parti i contenuti apportano un valore aggiunto prendendo il lavoro pesante da te come proprietario del sito e ti consentono di concentrarti sulle tue competenze principali; È quindi importante scendere a compromessi e sacrificare il comfort e la privacy dell'utente per offrire una migliore esperienza utente. Tuttavia, è importante non confondere l'esperienza utente con quella di sviluppatore: "Per il nostro team di sviluppo è più facile creare il servizio" non è una storia accattivante per gli utenti.

Il processo di revisione è il processo di verifica.

Controlla le terze parti

Comprendere le attività di una terza parte è la procedura di controllo. Puoi farlo sia dal punto di vista tecnico che non tecnico. per una singola terza parte e per l'intera raccolta.

Esegui un controllo non tecnico

Il primo passaggio non è tecnico: 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 metodi messo in guardia in modo specifico contro nei moduli precedenti, ad esempio con dichiarazioni eccessivamente generiche e senza alcuna indicazione che illustra come e quando verranno rimossi i dati raccolti. È importante capire che dal punto di vista dell'utente, tutti i dati che vengono raccolte sul tuo sito, incluse quelle di terze parti, saranno regolate dalle presenti Norme sulla privacy. Anche se lo fai tutto correttamente, quando si comunica chiaramente gli obiettivi e si supera il limite previsto le aspettative in materia di privacy dei dati gli utenti potrebbero ritenere l'utente responsabile di qualsiasi attività svolta dalle terze parti scelte. Se c'è qualcosa in sulle loro norme sulla privacy, che non vorresti indicare nelle tue norme, perché ridurrebbero fidarsi, valuta se esiste un fornitore alternativo.

Questo è un aspetto che può andare di pari passo con la revisione tecnica discussa più avanti, in quanto informa una un'altra. Dovresti conoscere le risorse di terze parti che stai incorporando per motivi commerciali (come le reti pubblicitarie) o contenuti incorporati) perché è previsto un rapporto commerciale. Questo è un buon punto di partenza per una per la revisione contabile. È anche probabile che il controllo tecnico identifichi terze parti, in particolare quelle incluse per che per motivi aziendali (componenti esterni, analisi, librerie di utilità) e questo elenco può essere unito all'elenco di di terze parti incentrate sull'attività. L'obiettivo è che tu, in qualità di proprietario del sito, tu voglia capire quale sia la terza le parti aggiunte al sito e, in qualità di azienda, essere in grado di presentare il proprio consulente legale con questo inventario di terze parti per assicurarti di adempiere a tutti gli obblighi richiesti.

Esegui 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'imbracatura di prova e ispezionarla in questo modo. Assicurati di vedere come agiscono le dipendenze all'interno del tuo sito web effettivo. disponibili sulla rete internet pubblica anziché in modalità di test o sviluppo. È molto istruttivo visualizzare il proprio sito web un nuovo utente. Apri il browser in un nuovo profilo pulito, in modo da non avere effettuato l'accesso e non avere alcun contratto memorizzato, quindi prova a visitare il tuo sito.

Creare un nuovo account sul tuo sito, se fornisci account utente. Il tuo team di progettazione avrà orchestrato questo nuovo utente di acquisizione di contenuti dal punto di vista della UX, ma può essere indicativo affrontarlo dal punto di vista della privacy. Non fare clic "Accetta" sui termini e condizioni, sull'avviso sui cookie o sulle norme sulla privacy; impostare te stesso l'attività di utilizzare il tuo servizio senza comunicare informazioni personali o avere cookie di monitoraggio, per capire se ci riesci e quanto è difficile farlo. Può anche essere utile cercare negli strumenti per sviluppatori del browser per vedere a quali siti si accede e quali dati vengono trasmessi. tali siti. Gli Strumenti per sviluppatori forniscono un elenco di richieste HTTP separate (di solito in una sezione chiamata "Rete") e puoi vedere da qui le richieste raggruppate per tipo (HTML, CSS, immagini, caratteri, JavaScript, richieste avviate da JavaScript). È inoltre possibile per aggiungere una nuova colonna che mostri il dominio di ogni richiesta, che indicherà quanti luoghi diversi sono stati contattati, e potrebbero esserci "richieste di terze parti" casella di controllo per mostrare solo le terze parti. Può essere utile anche usare Content-Security-Policy per eseguire una verifica continua, il cui scopo è approfondire la questione.)

Anche lo strumento "Request Map Builder" di Simon Hearne può essere una utile panoramica di tutti le richieste secondarie rese pubbliche da una pagina.

Questo è anche il punto in cui puoi includere le terze parti incentrate sull'attività, identificate nell'ambito dell'audit non tecnico ovvero l'elenco delle aziende con cui hai un rapporto finanziario per poter utilizzare le loro risorse. L'obiettivo è per far corrispondere l'elenco di terze parti che ritieni di utilizzare (da documenti finanziari e legali) con l'elenco che stai effettivamente osservando quali richieste HTTP di terze parti vengono effettuate dal tuo sito web. Dovresti essere in grado di identificare ogni terza attività le richieste tecniche in uscita effettuate. Se non riesci a identificare le richieste nel controllo tecnico per una terza parte identificati da una relazione commerciale, è importante capire perché e guidare il test, magari La risorsa viene caricata solo in un determinato paese, su un determinato tipo di dispositivo o per gli utenti che hanno eseguito l'accesso. In questo modo la tua delle aree del sito da controllare e verificare di visualizzare tutti gli accessi in uscita. (In alternativa, identificherà una terza parte risorsa che stai pagando e non utilizzi, il che rallegra sempre il reparto finanza).

Una volta ristretto l'elenco di richieste alle terze parti da includere nel controllo, fai clic su un singola richiesta ne mostrerà tutti i dettagli e, in particolare, i dati trasmessi alla richiesta. È inoltre molto comune che una richiesta di terze parti avviata dal codice prosegue poi ad avviare molte altre richieste di terze parti. Anche queste terze parti aggiuntive vengono "importate" nelle tue norme sulla privacy. Si tratta di un'attività laboriosa ma preziosa spesso possono essere inserite in analisi esistenti; il team di sviluppo del frontend dovrebbe già controllare le richieste per motivi legati alle prestazioni (magari con l'aiuto di strumenti esistenti come WebPageTest o Lighthouse) e dell'integrazione di dati e il controllo della privacy possono semplificare il processo.

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

Cosa fare

Aprire un browser con un nuovo profilo utente pulito, in modo da non avere effettuato l'accesso e non avere alcun contratto memorizzato. apri il browser strumenti di sviluppo Network per vedere tutte le richieste in uscita. Aggiungi una nuova colonna per mostrare il dominio di ciascuna richiesta e controlla "richieste di terze parti" casella di controllo per mostrare solo terze parti, se presenti. Quindi:

  • Visita il tuo sito.
  • Creare un nuovo account, se fornisci gli account utente.
  • Prova a eliminare l'account che hai creato.
  • Esegui una o due normali azioni sul sito (esattamente come dipende dalle funzioni del sito, ma scegli le azioni comuni eseguite dalla maggior parte degli utenti).
  • Esegui una o due azioni che sai che coinvolgono in particolare dipendenze di terze parti. Potrebbero essere incluse la condivisione di contenuti con social media, avviare un flusso di pagamento o incorporare contenuti da un altro sito.

Quando esegui ciascuna di queste attività, registra le risorse richieste da domini diversi dal tuo osservando 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 la rete dei log delle richieste 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 pagina specifica, in:

Chrome

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

Il riquadro Rete Chrome DevTools con il simbolo di download 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 dell'ingranaggio in alto a destra accanto al menu a discesa della limitazione. Dal relativo menu, scegli Salva tutto come HAR**.

Il riquadro Rete degli strumenti per sviluppatori di Firefox in cui è evidenziata l&#39;opzione Salva tutto come Harry.
Safari

Apri gli strumenti per sviluppatori del browser (Menu > Sviluppo > Mostra controllo web. Se il menu Sviluppo non è disponibile, attivalo da Menu > Safari > Preferenze > Avanzate > mostra il menu Sviluppo nella barra dei menu), vai 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 Rete dell&#39;inspector web di Safari in cui è evidenziata l&#39;opzione di esportazione HAR.

Per maggiori dettagli, puoi anche registrare ciò che viene trasmesso a terze parti (nella sezione Richiesta), anche se questi dati sono spesso offuscate e non utilmente interpretabili.

Best practice per l'integrazione di terze parti

Puoi impostare le tue norme relative alle terze parti utilizzate dal tuo sito: cambiare il fornitore di annunci che utilizzi in base alle loro prassi o quanto sia fastidioso o invasivo il loro popup per il consenso all'uso dei cookie o se vuoi usare i 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 quando lo sviluppo di un sito rappresenta il livello di privacy e sicurezza del servizio di analisi. Alcuni servizi di analisi vengono esplicitamente scambiati nel rispetto della privacy. Spesso, esistono anche modi per utilizzare uno script di terze parti che aggiunge di per sé la protezione della privacy: Non sei il primo team che vuole migliorare le prestazioni privacy e dalla raccolta di dati di terze parti; potrebbero essere già soluzioni. Infine, molti fornitori di terze parti sono più sensibili ai problemi di raccolta dei dati oggi che in passato. Inoltre, spesso è possibile aggiungere funzionalità o parametri che consentono una modalità di protezione maggiore per l'utente. Di seguito sono riportati alcuni esempi.

Quando aggiungi un pulsante di condivisione sui social media

Valuta la possibilità di incorporare direttamente i pulsanti HTML: il sito https://sharingbuttons.io/ offre alcuni esempi ben strutturati. In alternativa, puoi aggiungere semplici link HTML. Lo svantaggio qui è che perderai il "conteggio delle condivisioni" e la tua capacità di classificare i clienti nelle tue 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 incorpori un widget interattivo di qualche tipo di una terza parte, spesso è possibile fornire un'immagine rimandino alla terza parte in questione. Ciò significa che il tuo sito non offre l'esperienza in linea, ma cambia la decisione sulla condivisione dati con la terza parte dall'utente 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 in questo modo:

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

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

Durante l'incorporamento di un video

Quando incorpori video da siti di hosting video, cerca le opzioni che tutelano la privacy nel codice di incorporamento. Ad esempio, per YouTube, sostituisci youtube.com nell'URL incorporato con www.youtube-nocookie.com per evitare di monitorare i cookie essere posizionati agli utenti che visualizzano la pagina di incorporamento. Puoi anche selezionare "Abilita modalità di privacy avanzata". quando generi Condividi/incorpora link dalla pagina di YouTube. Questo è un buon esempio di utilizzo di una modalità di protezione maggiore per l'utente fornita da terze parti. (https://support.google.com/youtube/answer/171780 descrive questo argomento più dettagliatamente, e altre opzioni di incorporamento specifiche per YouTube).

Altri siti di video hanno meno opzioni al riguardo: TikTok, ad esempio, non ha un modo per incorporare i video senza monitoraggio. al momento della stesura del presente documento. Puoi ospitare i video personalmente (si tratta di un'alternativa), ma può trattarsi di una molto più lavoro, soprattutto per supportare molti dispositivi.

Come per i widget interattivi discussi in precedenza, spesso è possibile sostituire un video incorporato con un link al sito web che fornisce il servizio. Questa azione è meno interattiva perché il video non viene riprodotto in linea, ma lascia la possibilità di scegliere se guardarlo o meno con l'utente. Può essere utilizzato come esempio del "facade pattern", il nome per sostituire dinamicamente i contenuti interattivi con qualcosa che richiede all'utente per attivarlo. Un video di TikTok incorporato può essere sostituito con un link semplice alla pagina del video di TikTok, ma con altre informazioni puoi recuperare e visualizzare la miniatura del video e trasformarlo in un link. Anche se il fornitore di video prescelto non supportano un modo semplice per incorporare i video senza il tracciamento, molti host video supportano oEmbed, un'API che, quando fornita un link a un video o a dei contenuti incorporati, verranno restituiti dettagli programmatici, come una miniatura e un titolo. TikTok supporta oEmbed (consulta la pagina https://developers.tiktok.com/doc/embed-videos per i dettagli), il che significa che puoi trasformare (manualmente o in modo programmatico) un link a un video di TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 in metadati JSON relativi a quel video utilizzando https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173, quindi recupera una miniatura da visualizzare. WordPress lo utilizza spesso per richiedere la funzione oEmbed informazioni per i contenuti incorporati, ad esempio. Puoi utilizzare questo modello in modo programmatico per mostrare una "facade" che sembra interattivo e passa all'incorporamento di un video interattivo o al suo link quando l'utente sceglie di farci clic sopra.

Quando incorpori gli script di analisi

Analytics è progettato per raccogliere informazioni sugli utenti in modo che possano essere analizzate: questo è lo scopo. I sistemi di analisi sono essenzialmente per raccogliere e visualizzare i dati relativi ad accessi e utenti, operazione che viene eseguita su un server di terze parti come Google Analytics dell'implementazione. Esistono anche sistemi di analisi self-hosted come https://matomo.org/, anche se si tratta di un approccio più impegnativo rispetto all'utilizzo di una soluzione di terze parti. L'esecuzione di un sistema di questo tipo sulla tua infrastruttura ti aiuta a ridurre la raccolta dei dati, perché non esce dal tuo ecosistema. Gestione e rimozione dei dati, oltre all'impostazione dei relativi criteri. diventa una tua responsabilità. Gran parte delle preoccupazioni relative al monitoraggio tra siti si verifica quando i dati vengono eseguiti in modo subdolo, in modo segreto o come effetto collaterale dell'utilizzo di un servizio che non deve contenere alcuna raccolta di dati. Il software di analisi è apertamente progettati per raccogliere dati al fine di informare i proprietari dei siti riguardo ai loro utenti.

Storicamente, c'è stato un approccio alla raccolta di tutti i dati possibili su tutto, come una gigantesca rete da pesca. per poi analizzarli in seguito per trovare pattern interessanti. Questo approccio ha creato in gran parte il senso di disagio e inquietudine sulla raccolta dei dati di cui abbiamo parlato nella parte 1 di questo corso. Molti siti riconoscono per primi le domande da porre e e raccogliere 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 da te includendo il suo codice JavaScript nel sito, e imposta cookie per ciascun utente, è importante considerare che quest'ultimo potrebbe effettuare un riconoscimento cross-site indesiderato; ossia monitorare gli utenti su più siti. Alcuni potrebbero e altri no, ma la posizione di tutela della privacy qui è ipotizzare che tale servizio di terze parti esegue infatti il monitoraggio tra siti, a meno che tu non abbia un buon motivo per pensare o sapere altrimenti. Questo non è di per sé un motivo per evitare questi servizi, ma è un aspetto da considerare nella valutazione dei compromessi del loro utilizzo.

In passato, il compromesso raggiunto nell'analisi era la sola scelta se usarlo o meno: raccogliere tutti i dati e compromettere la privacy in cambio per ottenere insight e pianificare o di rinunciare del tutto a queste informazioni. Tuttavia, ora non è più così e spesso c'è spesso un tra questi due estremi. Verifica le opzioni di configurazione da limitare al tuo provider di analisi ridurre la quantità e la durata dell'archiviazione dei dati. Dal momento che hai i record dei controlli tecnici descritti in precedenza, puoi eseguire nuovamente le sezioni pertinenti del controllo per confermare che la modifica di queste configurazioni ridurre la quantità di dati raccolti. Se stai eseguendo la transizione su un sito esistente, puoi ottenere una misura quantificabile che puoi scrivere per i tuoi utenti. Ad esempio, Google Analytics prevede una serie di opzioni di attivazione (disattivate quindi per impostazione predefinita). funzionalità per la privacy, 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 include l'impostazione di un periodo di conservazione dei dati raccolti (Amministrazione > Informazioni sul monitoraggio > Conservazione dei dati) su un periodo inferiore al valore predefinito di 26 mesi. e l'attivazione di alcune delle soluzioni più tecniche, come l'anonimizzazione parziale degli IP (per maggiori dettagli, consulta la pagina https://support.google.com/analytics/answer/9019185).

Utilizzo di terze parti in un modo incentrato sulla tutela della privacy

Finora abbiamo parlato di come proteggere gli utenti da terze parti durante la fase di progettazione dell'applicazione, mentre stai pianificando cosa farà l'applicazione. La decisione di non utilizzare una terza parte specifica è parte integrante di questa pianificazione, e anche il controllo degli utilizzi rientra in questa categoria: si tratta di prendere decisioni in merito alla propria posizione sulla privacy. Tuttavia, questi le decisioni sono intrinsecamente poco granulari; la scelta di rivolgersi a una determinata terza parte o di non farlo non è una decisione complessa. È molto più probabile che tu voglia una via di mezzo: avere bisogno o avere intenzione di utilizzare una particolare offerta di terze parti, ma mitigare eventuali tendenze che violano la privacy (intenzionali o accidentali). Questa è l'attività per proteggere gli utenti al momento della creazione: aggiungendo misure di protezione per ridurre i danni non previsti. Tutte queste sono nuove intestazioni HTTP che puoi fornire durante la pubblicazione pagine e che suggeriranno o comanderanno allo user agent di assumere determinate posizioni relative alla privacy o alla sicurezza.

Norme sui referrer

Cosa fare

Imposta il criterio strict-origin-when-cross-origin o noreferrer per impedire ad altri siti di ricevere un'intestazione referrer quando crei link che rimandano a queste pagine o quando vengono caricate come risorse secondarie da una pagina:

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

Sul lato server, ad esempio in Express:

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

Se necessario, imposta un criterio più permissivo su richieste o elementi specifici.

Perché questa misura protegge la privacy degli utenti

Per impostazione predefinita, ogni richiesta HTTP che il browser effettua su un'intestazione Referer contenente l'URL della pagina che avvia la richiesta, che sia un link, un'immagine incorporata o uno script. Questo può essere un problema di privacy perché gli URL possono contenere informazioni private e tali URL essere disponibili a terze parti trasmette loro tali 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 è, che è una fuga di notizie. Ma anche un URL che non espone di per sé informazioni private espone che questo particolare utente (che potreste conoscere, se ha eseguito l'accesso) proviene da un altro sito, rivelando quindi che l'utente ha visitato l'altro sito. Si tratta di per sé l'esposizione informazioni che forse non dovresti conoscere sulla cronologia di navigazione dell'utente.

Fornire un'intestazione Referrer-Policy (con ortografia corretta) ti consente di modificare questa impostazione, in modo che alcuni o nessuno degli URL di riferimento vengano trasmessi. MDN elenca i dettagli completi, ma la maggior parte dei browser ora ha adottato un valore presunto strict-origin-when-cross-origin per impostazione predefinita, il che significa che l'URL del referrer viene trasmesso alla terza parti come origine (https://web.dev anziché https://web.dev/learn/privacy). Si tratta di una protezione della privacy utile senza devi fare qualsiasi cosa. Ma puoi rafforzare ulteriormente il problema specificando Referrer-Policy: same-origin per evitare di trasmettere informazioni di referrer a terze parti (o Referrer-Policy: no-referrer per evitare di trasmetterle a nessuno, inclusa la tua origine). (Questo è un buon esempio di equilibrio tra privacy e utilità; il nuovo valore predefinito è molto più incentrato sulla tutela della privacy rispetto a prima, ma fornisce comunque informazioni di alto livello a terze parti di tua scelta, come il tuo fornitore di analisi.

È utile anche specificare esplicitamente questa intestazione perché sai esattamente qual è il criterio e non devi fare affidamento sulle impostazioni predefinite del browser. Se non sei in grado di impostare le intestazioni, è possibile impostare un criterio referrer per un'intera pagina HTML utilizzando un metaelemento in <head>: <meta name="referrer" content="same-origin">; e, se il problema riguarda terze parti specifiche, è anche possibile impostare un referrerpolicy su singoli elementi come <script>, <a> o <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Content-Security-Policy

L'intestazione Content-Security-Policy, spesso chiamata "CSP", indica da dove è possibile caricare le risorse esterne. Viene usato principalmente per motivi di sicurezza, evitando attacchi di cross-site scripting (XSS) e script injection, ma quando viene usato oltre ai normali controlli, può anche limitare i casi in cui le terze parti che hai scelto possono trasferire i dati.

Si tratta potenzialmente di un'esperienza utente non ottimale; se uno dei tuoi script di terze parti inizia a caricare una dipendenza da un non presente nell'elenco, la richiesta verrà bloccata, lo script non andrà a buon fine e la tua applicazione potrebbe non andare a buon fine (o almeno la sua versione di fallback non riesce a JavaScript). Ciò è utile quando CSP è implementato per la sicurezza, il suo scopo normale: proteggersi da problemi di cross-site scripting (e, per farlo, usa un CSP rigoroso). Quando conosci tutti gli script incorporati utilizzati nella tua pagina, puoi crearne un elenco, calcolare un valore hash o aggiungere un valore casuale (chiamato "nonce") per ciascuno, quindi aggiungi l'elenco di hash alle tue norme sulla sicurezza del contenuto. In questo modo, qualsiasi script non è nell'elenco. Deve essere integrato nel processo di produzione del sito: gli script nelle pagine devono che includa il nonce o che venga calcolato un hash come parte della build. Per tutti i dettagli, consulta l'articolo sulla regola rigida-csp.

Fortunatamente, i browser supportano un'intestazione correlata, Content-Security-Policy-Report-Only. Se viene fornita questa intestazione, le richieste che violano il criterio fornito non sarà bloccato, ma verrà inviato un report JSON all'URL fornito. Un'intestazione di questo tipo ha questo aspetto: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/, Se il browser carica uno script da una posizione diversa da 3p.example.com, la richiesta viene eseguita correttamente, ma viene generato verrà inviato all'oggetto report-uri fornito. Normalmente questo viene utilizzato per fare esperimenti con un criterio prima di implementarlo, ma è utile l'idea è di utilizzarla come modo per eseguire un "controllo continuo". Oltre al controllo regolare descritto in precedenza, attivare i report CSP per verificare la presenza di domini imprevisti, il che potrebbe significare che le risorse di terze parti si stanno caricando risorse di terze parti proprie e che devi prendere in considerazione e valutare. (Potrebbe anche essere un segno di alcune che gli exploit di scripting sono sfuggiti ai tuoi confini di sicurezza, ovviamente, cosa di cui è importante conoscere!)

Content-Security-Policy è un'API complessa e complessa da usare. È risaputo e stiamo lavorando per creare la "nuova generazione" di CSP che raggiungerà gli stessi obiettivi, ma che non sarà così complicato da usare.Questa funzionalità non è ancora pronta, ma se vuoi sapere dove si sta dirigendo (o per contribuire alla sua progettazione), visita la pagina https://github.com/WICG/csp-next per maggiori 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. Quando il file JSON viene pubblicato sull'URL, memorizzalo. Controlla i dati memorizzati per ottenere una raccolta dei domini di terze parti richiesti dal tuo sito web quando vengono visitati da altri. Aggiorna l'intestazione Content-Security-Policy-Report-Only per elencare i domini previsti, in modo da vedere quando cambia 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é

Questa fase fa parte della tua verifica tecnica, in modo continuativo. Il controllo tecnico iniziale che hai eseguito ti fornirà un un elenco di terze parti con cui il tuo sito condivide o trasmette i dati utente. Questa intestazione genererà quindi un report per le richieste di pagine quali terze parti vengono ora contattate e puoi tenere traccia dei cambiamenti nel tempo. Questo non solo ti avvisa dei cambiamenti apportate dalle terze parti esistenti, ma contrassegnerà anche le terze parti appena aggiunte 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 il manuale di tanto in tanto una verifica tecnica (poiché l'approccio Content-Security-Policy non segnala quali dati vengono passati, ma che è stata fatta una richiesta).

Tieni presente che non deve essere aggiunto ogni volta alle pagine pubblicate o a ogni pagina. Regola il numero di risposte alle pagine ricevute l'intestazione in modo da ricevere un campione rappresentativo di rapporti di dimensioni non eccessive.

Norme relative alle autorizzazioni

L'intestazione Permissions-Policy (presentata con il nome Feature-Policy) ha un concetto simile a Content-Security-Policy, ma limita l'accesso alle potenti funzionalità del browser. Ad esempio, è possibile limitare l'uso dell'hardware del dispositivo come l'accelerometro, videocamera o dispositivi USB oppure per limitare funzionalità non hardware come l'autorizzazione per la visualizzazione a schermo intero o l'utilizzo di XMLHTTPRequest sincrono. Queste restrizioni possono essere applicate a una pagina di primo livello (per evitare che gli script caricati cerchino di utilizzare queste funzionalità) oppure pagine con frame secondari caricate tramite un iframe. Questa limitazione dell'utilizzo delle API non riguarda la fingerprinting del browser; ma impedire a terze parti di svolgere operazioni invasive (come l'utilizzo di potenti API, la visualizzazione finestre di autorizzazione e così via). Questo viene definito dal Modello di minaccia alla privacy per il targeting come "intrusione".

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

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

Questo esempio consente a questa pagina ("self") e <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 qualsiasi pagina, inclusa questa pagina, dall'utilizzo di una fotocamera per leggere le informazioni video. Puoi trovare molti più dettagli e un elenco di potenziali esempi qui.

L'elenco di funzionalità gestite dall'intestazionePermissions-Policy è lungo e potrebbe essere in continuo cambiamento. Attualmente l'elenco è , disponibile all'indirizzo https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

Cosa fare

I browser che supportano Permissions-Policy non consentono l'utilizzo di funzionalità potenti nei frame secondari per impostazione predefinita, ed è necessario un intervento per attivarle. Per impostazione predefinita, questo approccio è privato. Se noti che i frame secondari sul tuo sito richiedono queste autorizzazioni, puoi aggiungerle in modo selettivo. Tuttavia, per impostazione predefinita non vengono applicate norme relative alle autorizzazioni alla pagina principale e, di conseguenza, gli script (inclusi quelli di terze parti) che vengono caricate dalla pagina principale non sono limitate dal tentativo di utilizzare queste funzionalità. Per questo motivo, è utile applicare una limitazione Permissions-Policy su tutte le pagine per impostazione predefinita e poi aggiungere gradualmente le funzionalità richieste dalle tue pagine.

Esempi di funzionalità efficaci interessate da Permissions-Policy includono la richiesta della posizione dell'utente e l'accesso ai sensori (tra cui accelerometro, giroscopio e magnetometro), l'autorizzazione per la modalità a schermo intero e la richiesta di accesso alla fotocamera e al microfono dell'utente. Trovi un link all'elenco completo delle funzionalità (che cambiano).

Sfortunatamente, bloccare tutte le funzionalità per impostazione predefinita e poi riautorizzarle selettivamente richiede l'elenco di tutte le funzionalità nell'intestazione. che possono sembrare piuttosto ineleganti. Tuttavia, un'intestazione Permissions-Policy di questo tipo è un buon punto di partenza. permissionspolicy.com/ dispone di un generatore facilmente cliccabile per creare questa intestazione: se lo utilizzi per creare un'intestazione che disattiva tutte le funzionalità, avrà il seguente risultato:

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 al "tempo di compilazione" e "design time" esistono anche protezioni della privacy che vengono applicate in "tempo di esecuzione", ovvero le funzionalità implementate nei browser stessi per proteggere gli utenti. Non si tratta di funzionalità che puoi controllare o utilizzare direttamente come sito sono funzionalità del prodotto, ma sono funzionalità di cui è necessario essere a conoscenza, perché i tuoi siti potrebbero essere interessati da queste decisioni sui prodotti nei browser. Per dare un esempio di come queste protezioni del browser possono influire sul tuo sito, se hai JavaScript lato client che attende affinché una dipendenza di terze parti venga caricata prima di continuare con la configurazione della pagina e che non venga mai caricata, potrebbe non essere mai completato, quindi all'utente viene mostrata una pagina caricata a metà.

Includono la funzionalità Intelligent Tracking Prevention in Safari. (e il motore WebKit sottostante) e la Protezione antitracciamento avanzata in Firefox (e il suo motore, Gecko). Tutte queste caratteristiche rendono difficile per le terze parti creare profili dettagliati dei tuoi utenti.

Gli approcci dei browser alle funzionalità per la privacy cambiano di frequente ed è importante rimanere aggiornati. il seguente elenco di protezioni siano corrette al momento della stesura. I browser potrebbero inoltre implementare altre protezioni. questi elenchi non sono esaustivi. Consulta il modulo sulle best practice per sapere come stare al passo con i cambiamenti qui e assicurati di testare le prossime versioni del browser per individuare le 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 (i cookie di terze parti potrebbero essere bloccati per impostazione predefinita in queste modalità, ad esempio). Pertanto, i test in modalità di navigazione in incognito potrebbero non rispecchiare sempre la tipica esperienza di navigazione della maggior parte degli utenti se non stanno usando la navigazione privata. Ricorda inoltre che il blocco dei cookie in varie situazioni potrebbe comportare il fatto che altre soluzioni di archiviazione, come window.localStorage, vengono bloccati, non solo i cookie.

Chrome

  • I cookie di terze parti sono pensati per essere bloccati in futuro. Al momento della stesura del presente documento, non sono bloccati per impostazione predefinita (questa opzione può essere attivata da un utente): https://support.google.com/chrome/answer/95647 spiega i dettagli.
  • Le funzionalità per la privacy di Chrome, in particolare le funzionalità di Chrome che comunicano con Google e servizi di terze parti. sono descritti all'indirizzo privacysandbox.com/.

Edge

  • I cookie di terze parti non sono bloccati per impostazione predefinita (ma possono essere attivati da un utente).
  • Blocchi di funzionalità Tracking Prevention di Edge I tracker di siti non visitati e i tracker dannosi noti sono bloccati per impostazione predefinita.

Firefox

Per informazioni su ciò che 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.
  • Come parte della sua funzionalità Intelligent Tracking Prevention, Safari riduce il referrer trasmesso ad altre pagine come un sito di primo livello anziché una pagina specifica: (https://something.example.com, anziché https://something.example.com/this/specific/page).
  • I dati di localStorage del browser 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, attiva la "modalità di debug di Prevenzione del monitoraggio intelligente" nel menu di Safari menu sviluppatore (su computer). Per maggiori dettagli, vedi https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/.

Proposte per l'API

Perché abbiamo bisogno di nuove API?

Sebbene le nuove funzionalità e norme che tutelano la privacy nei prodotti dei browser contribuiscano a preservare la privacy degli utenti, presentano anche delle sfide. Molte tecnologie web sono utilizzabili per il monitoraggio tra siti nonostante siano progettate e utilizzate per altri scopi. Ad esempio: molti sistemi di federazione delle identità che utilizziamo ogni giorno si basano su cookie di terze parti. Numerose soluzioni pubblicitarie che i publisher oggi per generare entrate si basano sui cookie di terze parti. Molte soluzioni di rilevamento di attività fraudolente si basano sul fingerprinting. Cosa 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 o intende farlo, per proteggere l'utente privacy.

È necessario un nuovo approccio: man mano che i cookie di terze parti vengono eliminati e il fingerprinting è mitigato, gli sviluppatori hanno bisogno di API create ad hoc che soddisfano i casi d'uso (che non sono scomparsi), ma che sono progettati in modo da garantire la tutela della privacy. L'obiettivo è progettare e creare API che non possono essere utilizzate per il monitoraggio tra siti. A differenza delle funzionalità del browser descritte nella sezione precedente, queste tecnologie a diventare API cross-browser.

Esempi di proposte API

L'elenco seguente non è completo, è un assaggio di alcuni degli argomenti trattati.

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

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

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

Inoltre, sta emergendo un altro tipo di proposta relativa alle API per provare a mitigare il monitoraggio nascosto specifico del browser. Un esempio è il budget di privacy. In queste varie e casi d'uso, le API inizialmente proposte da Chrome sono disponibili con il termine generico di 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 intento è simile a Do Not Track, che non è più disponibile.

Stato delle proposte dell'API

La maggior parte di queste proposte dell'API non è stata ancora implementata, oppure il deployment viene eseguito solo dietro flag o in ambienti limitati per la sperimentazione.

Questa fase di incubazione pubblica è importante: i fornitori e gli sviluppatori dei browser raccolgono opinioni ed esperienze relative alla compatibilità di queste API. utili e se fanno effettivamente per quello per cui sono state progettate. Sviluppatori, fornitori di browser e altri attori dell'ecosistema utilizzano questa fase di eseguire l'iterazione del design dell'API.

Il luogo migliore per restare al passo con le nuove API proposte è attualmente l'elenco delle proposte del gruppo sulla 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 alle tue esperienze nelle discussioni e nella progettazione delle API. In tutti gli altri casi, non è necessario conoscere tutti i dettagli su queste nuove API al momento della stesura, ma è bene essere a conoscenza delle novità in arrivo.