La privacy è compromessa quando si condividono gli URL con hash SHA-1?

È meglio, ma non perfetto.

Mentre è (attualmente) impossibile ottenere l'URL per un dato hash, ovviamente ogni URL ha lo stesso hash.

Quindi non è possibile vedere tutti gli URL che un utente naviga, ma è probabile che ne ottenga la maggior parte.

Sebbene non sia possibile vedere l'utente A visita HASH1 e concludi che HASH1 significa fancyDomainBelongingToUserA-NoOneElseVisits.com , è ad esempio possibile calcolare semplicemente l'hash per CheatOnMyWife.fancytld e poi vedere quali utenti visitano quel sito.

Non lo considererei come protezione della privacy degli utenti.

Anche la semplice corrispondenza degli utenti che visitano molti di domini simili può essere piuttosto rivelatrice.

Penso che sia bello che tu desideri proteggere la privacy di un utente, ma ciò che stai costruendo sembra essere contrario alla protezione della privacy, quindi non penso che sia possibile farlo con una semplice configurazione (es. url di invio client, in qualsiasi forma, direttamente al tuo servizio di back-end).

Come altri hanno notato, l'hashing che utilizza sha1 è un buon primo passo, ma raggiunge solo la privacy contro gli umani rischiando di dare una rapida occhiata al database. Non ti dà molta privacy contro gli algoritmi progettati per analizzare i contenuti del database.

Stai perdendo anche più dell'URL visitato: l'utente ti dice anche a che ora era online e ha guardato l'url dato se stai facendo un controllo in tempo reale.

Alcuni altri hanno suggerito soluzioni per mitigare i problemi di privacy. Mentre sono tutti migliori di non fare nulla, non risolvono il problema. Ad esempio, la soluzione di Google che invia solo 32 bit dell'hash sembra carina, ma che ancora associa solo tutti gli URL esistenti a una tabella hash con 4 miliardi di slot. Alcune di queste slot possono contenere un gran numero di voci, ma dal momento che non tutti gli URL sono visitati in modo uguale (ad esempio, gli URL di Facebook sono più visitati rispetto a quelli di qualche scuola primaria) e gli URL di un singolo dominio saranno molto probabilmente verrà eseguito un hash in modo abbastanza equo sui 4 miliardi di slot disponibili, sarà comunque abbastanza facile da indovinare, dato un insieme di url completi che ha lo stesso prefisso a 32 bit, quale URL è stato effettivamente visitato (specialmente per google, che ha pagerank dati su un numero enorme di URL là fuori ...)

Un simile attacco coinvolge qualcuno che costruisce una tabella arcobaleno di URL a cui è interessato. Potresti renderlo più difficile

1. Utilizzo di una funzione di hash della password anziché di sha1, che richiede molto tempo per calcolare l'hash, ma ciò significa che il plug-in del browser sembra non rispondere.
2. Salatura degli hash. Ovviamente non si può dare a ogni utente il proprio sale, o tutti gli hash per lo stesso url forniti da diversi utenti saranno unici, molto probabilmente rendendo inutile l'applicazione. Ma più cresce la tua base di utenti, meno utenti hanno bisogno degli stessi valori di sale. Non proteggi ancora la privacy degli utenti, ma rendi più difficile calcolare le tabelle arcobaleno per scoprire esattamente quali URL sono stati visitati, e se qualcuno lo fa per il sale di un utente specifico, solo la privacy di tutti gli altri utenti che condividono il suo sale è compromesso.

Tuttavia, questo non aiuta ancora nulla nei casi in cui un utente malintenzionato non è interessato all'intero insieme di URL hash, ma desidera solo rispondere a domande molto specifiche (ad es. quali utenti hanno visitato gli URL appartenenti ai domini in una determinata "lista nera"?) Dal momento che tali query riguarderanno solo una breve lista (forse poche decine o poche centinaia di migliaia di URL, a seconda delle dimensioni della lista nera), è banale abbatterle ognuna in una piccola quantità di tempo, non importa quali contromisure si utilizzano per rallentarlo.

È peggio di così, perché molti siti web hanno solo alcuni punti di accesso comuni, il più probabile è solo il dominio seguito da un percorso vuoto. Altri percorsi comunemente visitati sono le pagine di accesso, le pagine dei profili ecc. Quindi il numero di URL necessari per l'hash per determinare se qualcuno ha visitato un dominio specifico è molto probabilmente molto piccolo. Se un aggressore lo fa, perderà gli utenti che hanno utilizzato un link diretto in un sito web, ma ne prenderà la maggior parte.

Ed è anche peggio: se un utente malintenzionato riesce a trovare un URL completo da un hash fornito dall'utente, potrebbe facilmente ottenere tutti gli URL per gran parte della sessione di navigazione dell'utente. Come? Bene, dal momento che ha un URL, può dereferenziarlo con il suo ragno personalizzato, guardare tutti i link nel documento, cancellarli e cercarli nel tuo database. Quindi fa lo stesso con quei collegamenti e così via.

Quindi puoi fare alcune cose per renderlo più difficile, ma non credo che ci sia un modo per aggirare l'utente che deve fondamentalmente fidarsi di te con la sua cronologia di navigazione. L'unico modo per aggirare ciò che vedo è la creazione di un sistema distribuito non completamente sotto il tuo controllo e il suo utilizzo per raccogliere url, ad esempio una sorta di rete di mixer. Un'altra possibilità potrebbe essere quella di far scaricare ai client ampie parti del contenuto del database, nascondendo in tal modo gli URL a cui erano realmente interessati e fornire nuovi contenuti per il database solo in pacchetti di grandi dimensioni, il che almeno nasconderebbe il componente temporale della navigazione dell'utente .

Risposta breve.

Mentre dichiari di essere preoccupato per la privacy dei tuoi utenti finali, non è chiaro chi intendi proteggerli da e per quale motivo?

• Se la funzionalità di base della tua applicazione è essenzialmente di-farmare i dati utente da un client, inviarlo a un server e fornire un risultato, allora tu sempre come colui che riceve i dati quali sono questi dati.
• Se il tuo obiettivo è proteggere i dati in trasmissione dal client al server da parte di terze parti, è possibile ideare uno schema di crittografia per proteggere la trasmissione. Ma questo è l'assoluto migliore che puoi fare per proteggere i dati degli utenti.

Risposta lunga.

Per prima cosa dici:

I’m working on a small side project which involves a browser add-on and a backend service. The service is pretty simple: Give it a URL and it will check if the URL exists in a database. If the URL is found some additional information is also returned.

Quindi dici questo:

The browser add-on forwards any URLs that the user opens to the service and checks the response. Now, sharing every URL you’re browsing is of course a big no-no.

Il problema con lo schema che descrivi e le tue preoccupazioni per la privacy è che le tue applicazioni core, il comportamento intrinseco è quello di condividere informazioni che sono tradizionalmente considerate private. Quindi, alla fine della giornata, quale livello di "privacy" intendi proteggere per chi, da cosa e per quale motivo?

Se qualcuno acconsente a utilizzare la tua applicazione, con una conoscenza di base e rudimentale di ciò che l'applicazione fa e quali informazioni condivide, è probabile che sappiano che il tuo server di backend saprà esattamente cosa sfoglia. Oh, certo, puoi configurare qualsiasi schema di hashing elaborato e inventivo che puoi escogitare per "mascherare" l'URL, ma alla fine della giornata il tuo server back-end conoscerà i dati dell'utente finale. E anche se sei convinto che questi dati ti siano in qualche modo sconosciuti, non impedisce ancora la percezione che tu sappia quali sono i dati; e onestamente non riesco a concepire uno schema in cui tu possa fornire questo servizio e non sai quali URL vengono esplorati.

Se sei preoccupato che i dati degli utenti si trasmettano in trasmissione a potenziali terze parti di qualche tipo, allora forse puoi inventare uno schema di crittografia che possa proteggere i dati trasmessi. Per me, che è fattibile.

Ma se il tuo desiderio generale è quello di raccogliere dati privati di qualche tipo per analizzarli e quindi fornire un risultato finale, il concetto generale di te e del tuo sistema - in qualche modo non conoscendo le specifiche di quei dati è difettoso. Puoi controllare il backend di un processo come questo e hai completamente accesso ai dati che ti piaccia o no.

La proposta di archiviare gli hash (parziali) degli URL è un modo consolidato per mitigare l'impatto sulla privacy. Mentre ciò rende più difficile rispondere "Su quali pagine sei stato?" è ovviamente ancora banale se si conoscono le pagine esatte che si stanno cercando poiché gli hash sono praticamente unici per ogni URL.

Ciò che descrivi è esattamente il problema che il servizio Navigazione sicura di Google doveva risolvere. Questo servizio viene utilizzato da Chrome e da altre applicazioni per controllare gli URL sospetti contro l'elenco di siti Web pericolosi di Google durante la navigazione, con l'esigenza di garantire comunque un certo grado di privacy.

Google descrive il loro metodo nel white paper sulla privacy di Google Chrome :

When Safe Browsing is enabled in Chrome, Chrome contacts Google's servers periodically to download the most recent Safe Browsing list of unsafe sites, including phishing, social engineering, and malware sites, as well as sites that lead to unwanted software. The most recent copy of this list is stored locally on your system. Chrome checks the URL of each site you visit or file you download against this local list. If you navigate to a URL that appears on the list, Chrome sends a partial URL fingerprint (the first 32 bits of a SHA-256 hash of the URL) to Google for verification that the URL is indeed dangerous. Chrome also sends a partial URL fingerprint when a site requests a potentially dangerous permission, so that Google can protect you if the site is malicious. Google cannot determine the actual URL from this information.

(Enfasi mie)

Si noti che se alcuni falsi positivi sono accettabili per il proprio servizio, è possibile memorizzare solo una piccola parte dell'hash con il vantaggio di una ricerca più rapida e plausible deniability .

Mentre tutte le altre risposte sono incentrate su come trasferire l'URL al tuo servizio di backend "correttamente", la conclusione generale sembra: non è possibile.

Vorrei suggerire un approccio diverso, che potrebbe benissimo non essere possibile nel tuo caso d'uso, ma penso che sia un metodo valido per discutere almeno.

Invece di inviare l'url al back-end, perché non inviare il database all'addon e fare la ricerca ?

Naturalmente questo introduce tutti i tipi di nuovi problemi. Il database è probabilmente molto grande, potrebbe contenere informazioni che non si desiderano sul computer dell'utente, ecc. Ma per applicazioni semplici / piccole, questa potrebbe essere una soluzione valida.

Non è molto meglio per la privacy degli utenti. Ad esempio https://www.google.com/ avrebbe sempre lo stesso hash, quindi sarebbe noto chi lo ha sfogliato.

A seconda delle esigenze del progetto, potrebbe essere necessario prendere in considerazione altre opzioni che ti si addicono, ad esempio una di queste non trasmette ogni URL ogni volta. Puoi anche controllare solo l'FQDN e non l'intero URL che sarebbe molto meglio per la privacy.