Ich finde es gut, dass Sie die Privatsphäre eines Benutzers schützen möchten, aber was Sie erstellen, scheint dem Schutz der Privatsphäre zu widersprechen. Daher denke ich nicht, dass dies mit einer einfachen Einrichtung möglich ist (z. B. Client-Sende-URL, in welcher Form auch immer, direkt an Ihren Backend-Service).
Wie andere angemerkt haben, ist das Hashing mit sha1 ein guter erster Schritt, erreicht jedoch nur die Privatsphäre gegenüber Menschen und riskiert einen schnellen Blick in die Datenbank. Es bietet Ihnen nicht viel Privatsphäre gegenüber Algorithmen zur Analyse des Datenbankinhalts.
Sie verlieren auch mehr als die besuchte URL: Der Benutzer teilt Ihnen auch mit, zu welcher Zeit er online war und sich umgesehen hat Die angegebene URL, wenn Sie in Echtzeit prüfen.
Einige andere haben Lösungen vorgeschlagen, um die Datenschutzprobleme zu verringern. Obwohl sie alle besser sind als nichts zu tun, lösen sie das Problem nicht. Zum Beispiel sieht Googles Lösung, nur 32 Bit des Hashs zu senden, gut aus, ordnet aber immer noch nur alle vorhandenen URLs einer Hash-Tabelle mit 4 Milliarden Slots zu. Einige dieser Slots enthalten möglicherweise eine große Anzahl von Einträgen. Da jedoch nicht alle URLs gleich häufig besucht werden (z. B. werden Facebook-URLs viel häufiger besucht als die Homepage einer Grundschule), werden auch die URLs einer einzelnen Domain verwendet höchstwahrscheinlich ziemlich gleichmäßig über die 4 Milliarden verfügbaren Slots gehasht werden, wird es immer noch ziemlich leicht zu erraten sein, wenn man eine Reihe vollständiger URLs verwendet, die auf dasselbe 32-Bit-Präfix hashen, das tatsächlich besucht wurde (insbesondere für Google, das Pagerank hat Daten zu einer großen Anzahl von URLs da draußen ...)
Bei einem solchen Angriff erstellt jemand eine Regenbogentabelle mit URLs, an denen er interessiert ist. Sie könnten es schwieriger machen, indem Sie
- Verwenden einer Passwort-Hash-Funktion anstelle von sha1, was lange dauert, um den Hash zu berechnen. Dies bedeutet jedoch, dass Ihr Browser-Plugin nicht mehr reagiert.
- Salzen Sie Ihre Hashes. Natürlich können Sie nicht jedem Benutzer sein eigenes Salz geben, oder alle Hashes für dieselbe URL, die von verschiedenen Benutzern bereitgestellt werden, sind eindeutig, was Ihre Anwendung höchstwahrscheinlich sinnlos macht. Aber je größer Ihre Nutzerbasis wird, desto weniger Benutzer benötigen dieselben Salzwerte. Sie schützen die Privatsphäre der Benutzer immer noch nicht, aber Sie erschweren die Berechnung von Regenbogentabellen, um herauszufinden, welche URLs genau besucht wurden. Wenn jemand dies für das Salz eines bestimmten Benutzers tut, gilt dies nur für die Privatsphäre aller anderen Benutzer, die sein Salz teilen Ist kompromittiert.
ol> Dies hilft jedoch immer noch nichts, wenn ein Angreifer nicht an allen gehashten URLs interessiert ist, sondern nur sehr spezifische Fragen beantworten möchte (z. B. welche Benutzer haben URLs besucht, die zu den Domains in einer bestimmten "Blacklist" gehören?) Da solche Abfragen nur eine kurze Liste beinhalten (möglicherweise ein paar Dutzend bis zu ein paar hunderttausend URLs, abhängig von der Größe der Blacklist), ist es trivial, Hash zu verwenden jeder von ihnen in kurzer Zeit, egal welche Gegenmaßnahmen Sie verwenden, um es zu verlangsamen.
Es ist schlimmer als das, da viele Websites nur wenige gemeinsame Einstiegspunkte haben, wobei der wahrscheinlichste nur die Domain ist, der ein leerer Pfad folgt. Andere häufig besuchte Pfade sind Anmeldeseiten, Profilseiten usw. Daher ist die Anzahl der URLs, die Sie hashen müssen, um festzustellen, ob jemand eine bestimmte Domain besucht hat, höchstwahrscheinlich sehr gering. Wenn ein Angreifer dies tut, verpasst er Benutzer, die einen Deep Link zu einer Website verwendet haben, aber er fängt die meisten von ihnen ab.
Und es wird noch schlimmer: Wenn ein Angreifer es schafft, zu finden Eine vollständige URL aus einem Hash, den ein Benutzer bereitgestellt hat, kann sehr leicht alle URLs für einen großen Teil der Browsersitzung dieses Benutzers abrufen. Wie? Nun, da er eine URL hat, kann er sie mit seiner eigenen benutzerdefinierten Spinne dereferenzieren, alle Links im Dokument anzeigen, sie hashen und in Ihrer Datenbank suchen. Dann macht er dasselbe mit diesen Links und so weiter.
Sie können also ein paar Dinge tun, um es schwieriger zu machen, aber ich glaube nicht, dass es einen Weg gibt, wie der Benutzer Ihnen im Grunde seinen Browserverlauf anvertrauen muss. Die einzige Möglichkeit, das zu umgehen, was ich sehen kann, besteht darin, ein verteiltes System aufzubauen, das nicht vollständig unter Ihrer Kontrolle steht, und damit URLs zu sammeln, beispielsweise eine Art Mischernetzwerk. Ein anderer Ort könnte darin bestehen, dass die Clients große Teile Ihres Datenbankinhalts herunterladen und so verbergen, an welchen URLs sie tatsächlich interessiert waren, und neuen Inhalt für Ihre Datenbank nur in großen Paketen bereitstellen, wodurch zumindest die Zeitkomponente des Browsings des Benutzers verborgen würde .