SHA-1でハッシュされたURLを共有するとプライバシーが侵害されますか？
私は、ブラウザーのアドオンとバックエンドサービスを含む小さなサイドプロジェクトに取り組んでいます。サービスはかなりシンプルです。 URLを指定すると、そのURLがデータベースに存在するかどうかがチェックされます。 URLが見つかると、いくつかの追加情報も返されます。
ブラウザのアドオンは、ユーザーが開いたすべてのURLをサービスに転送し、応答を確認します。これで、閲覧しているすべてのURLを共有することはもちろんa big no-noです。そのため、代わりに、SHA1（または同様のハッシュ関数）を使用してURLのハッシュを作成し、それをバックエンドサービスに送信してDBのメンバーシップを確認することだけを考えていました。
私の質問は、このスキームがユーザーのプライバシーに優れているかどうかです。私の考えでは、現在はURLを共有していません。ユーザーが特定のURLを開いたことを確認する唯一の方法は、そのURLがデータベースに既に存在するかどうかです。
それは良いですが完璧ではありません。
特定のハッシュのURLを取得することは（現在のところ）不可能ですが、もちろんすべてのURLが同じハッシュを持っています。
したがって、ユーザーが参照するすべてのURLを表示することはできませんが、ほとんどのURLを取得できる可能性が高くなります。
ユーザーAがHASH1にアクセスしたことを確認して、HASH1がfancyDomainBelongingToUserA-NoOneElseVisits.comを意味すると結論付けることはできませんが、たとえば、CheatOnMyWife.fancytldのハッシュを計算して、どのユーザーがそのサイトにアクセスしたかを確認することもできます。
ユーザーのプライバシーを保護することは考えていません。
また、似たドメインのたくさんにアクセスするユーザーを一致させるだけでも、かなり明らかになる可能性があります。
ユーザーのプライバシーを保護するのは良いことだと思いますが、構築しているものはプライバシーの保護とは反対のようです。そのため、単純な設定（たとえば、クライアント送信URLなど）でこれを行うことはできないと思います。 、バックエンドサービスに直接）。
他の人が指摘したように、sha1を使用したハッシュは優れた最初のステップですが、データベースをざっと見る危険を冒す人間に対するプライバシーを実現するだけです。データベースの内容を分析するために設計されたアルゴリズムに対して、プライバシーをあまり提供しません。
また、アクセスしたURLよりも多くの情報を漏らしています。リアルタイムチェックを行っている場合は、ユーザーがオンラインになっていた時間に、指定されたURLを確認したこともわかります。
他のいくつかは、プライバシー問題を軽減するための解決策を提案しています。彼らは何もしないよりはましですが、問題を解決しません。たとえば、ハッシュの32ビットのみを送信するというGoogleのソリューションは見栄えが良いですが、それでも既存のすべてのURLを40億スロットのハッシュテーブルにマッピングするだけです。これらのスロットの一部には多数のエントリが含まれている可能性がありますが、すべてのURLが同じようにアクセスされるとは限らないため（たとえば、FacebookのURLは、一部の小学校のホームページよりもアクセスされる可能性がはるかに高い）、単一のドメインのURLはおそらく40億の利用可能なスロットでかなり均等にハッシュされます。同じ32ビットプレフィックスにハッシュする完全なURLのセットが与えられた場合、実際にアクセスされたURL（特に、ページランクを持つGoogleの場合）そこにある膨大な数のURLに関するデータ...）
このような攻撃には、誰かが興味のあるURLのRainbowテーブルを作成することが含まれます。
- Sha1の代わりにパスワードハッシュ関数を使用すると、ハッシュの計算に時間がかかりますが、ブラウザープラグインが応答していないように見えます。
- ハッシュをソルトします。明らかに、すべてのユーザーに独自のソルトを与えることはできません。または、異なるユーザーによって提供された同じURLのすべてのハッシュが一意になるため、アプリケーションが無意味になる可能性が高くなります。ただし、ユーザーベースが大きくなるほど、同じソルト値を必要とするユーザーは少なくなります。それでもユーザーのプライバシーは保護しませんが、レインボーテーブルを計算して、アクセスされたURLを正確に見つけることを難しくします。特定のユーザーのソルトに対して誰かがそれを実行した場合、そのソルトを共有している他のすべてのユーザーのプライバシーのみ妥協しています。
ただし、攻撃者がハッシュされたURLのセット全体に関心がない場合でも、これは何の助けにもなりませんが、非常に具体的な質問（特定の「ブラックリスト」？）このようなクエリには短いリスト（ブラックリストのサイズによっては数十から数十万のURLが含まれる場合があります）のみが含まれるため、短時間でそれぞれをハッシュするのは簡単です。それを遅くするためにどのような対策をとるかが重要です。
それよりも悪いのは、多くのWebサイトにはいくつかの共通のエントリポイントしかないためです。最も可能性が高いのは、ドメインとそれに続く空のパスだけです。その他の一般的にアクセスされるパスはログインページ、プロファイルページなどです。そのため、特定のドメインにアクセスしたかどうかを判断するためにハッシュする必要があるURLの数は非常に少ない可能性があります。攻撃者がこれを行うと、Webサイトへのディープリンクを使用したユーザーを見逃しますが、ほとんどのユーザーを捕まえます。
さらに悪いことに、攻撃者がユーザーが提供したハッシュから1つの完全なURLを見つけた場合、そのユーザーのブラウジングセッションの大部分のすべてのURLを非常に簡単に取得する可能性があります。どうやって？まあ、彼はURLを持っているので、自分のカスタムスパイダーで逆参照し、ドキュメント内のすべてのリンクを見て、ハッシュして、データベース内でそれらを探すことができます。次に、それらのリンクについても同じようにします。
だからあなたはそれを難しくするためにいくつかのことをすることができます、しかし私はユーザーが彼の閲覧履歴で基本的にあなたを信頼しなければならない方法があるとは思いません。私が見ることができる唯一の方法は、完全に管理されていない分散システムを構築し、それを使用してURLを収集することです。たとえば、一種のミキサーネットワークです。別の場所は、クライアントにデータベースコンテンツの大部分をダウンロードさせ、実際に関心のあるURLを非表示にして、少なくともユーザーのブラウジングの時間コンポーネントを非表示にする大きなパケットでのみデータベースに新しいコンテンツを提供することです。 。
簡潔な答え。
エンドユーザーのプライバシーについて懸念していると述べていますが、エンドユーザーのプライバシーを誰からどのような理由で「保護」するつもりなのか明確ではありませんか？
- アプリケーションのコア機能が（本質的に）クライアントからのユーザーデータをファームし、サーバーに送信して結果を配信する場合、そのデータの受信者は常にそのデータが何かを知っている。
- クライアントからサーバーへの送信中のデータを第三者が盗用から保護することが目的である場合は、送信を保護するために暗号化スキームを考案できます。しかし、それはユーザーデータを保護するためにできる絶対的なベストです。
長い答え。
最初にこれを言う：
私は、ブラウザーのアドオンとバックエンドサービスを含む小さなサイドプロジェクトに取り組んでいます。サービスは非常に単純です。URLを指定すると、そのURLがデータベースに存在するかどうかがチェックされます。 URLが見つかると、いくつかの追加情報も返されます。
次に、これを言います：
ブラウザのアドオンは、ユーザーが開いたすべてのURLをサービスに転送し、応答を確認します。現在、閲覧しているすべてのURLを共有することは、もちろんbig no-noです。
あなたが説明するスキームとプライバシーに対する懸念の問題は、アプリケーションのコアである固有の動作が、従来はプライベートと見なされていた情報を共有することです。結局のところ、誰のために、何のために、どのような理由で、どのレベルの「プライバシー」を保護するつもりですか？
誰かがあなたのアプリケーションを使用することに同意する場合-アプリケーションが何をし、どの情報を共有するかについての基本的で初歩的な知識を持っている場合-バックエンドサーバーが閲覧するものを正確に知っていることを彼らは知っているでしょう。確かに、URLを「マスク」するために思いつくことができる手の込んだ、巧妙なハッシュスキームを設定できますが、1日の終わりにyourバックエンドサーバーはエンドユーザーのデータを認識します。そして、このデータが何らかの形で未知であることを確信している場合でも、データが何であるかを知っているだろうという認識を止めるものではありません。そして正直なところ、私はあなたがこのサービスを提供でき、どのURLが閲覧されているのか分からないようなスキームを想像することはできません。
潜在的なサードパーティへの送信中にユーザーデータが漏洩することを懸念している場合は、送信されるデータを保護できる暗号化スキームを考え出すことができます。私には、それが実行可能です。
しかし、全体的な目的が、何らかのプライベートデータを収集して分析し、最終結果を提供することである場合、データの詳細がわからないという、ユーザーとシステムの全体的な概念に欠陥があるのです。このようなプロセスのバックエンドを制御し、それが好きかどうかに関係なく、データに完全にアクセスできます。
URLの（部分的な）ハッシュを保存するという提案は、プライバシーへの影響を軽減する確立された方法です。これにより、「何ページ行った？」ハッシュはすべてのURLで実質的に一意であるため、探している正確なページを知っていても、それは明らかに簡単です。
あなたが説明しているのは、まさにGoogle Safe Browsingサービスが解決しなければならなかった問題です。このサービスは、Chrome=およびその他のアプリケーションで使用されており、疑わしいURLを、閲覧中にGoogleの危険なWebサイトのリストと照合します。ある程度のプライバシーを確保する必要があります。
Googleは Google Chromeプライバシーホワイトペーパー でその方法を概説しています：
Chromeでセーフブラウジングが有効になっている場合、Chromeは定期的にGoogleのサーバーに接続して、フィッシング、ソーシャルエンジニアリング、マルウェアサイトなどの安全でないサイトの最新のセーフブラウジングリスト、および誘導するサイトをダウンロードしますこのリストの最新のコピーはシステムのローカルに保存されます。Chromeは、アクセスした各サイトのURLまたはダウンロードしたファイルをこのローカルリストに対してチェックします。リストに表示されるURLに移動すると、Chromeは部分的なURLフィンガープリント（URLのSHA-256ハッシュの最初の32ビット）を確認のためにGoogleに送信します） URLが本当に危険であることを示します。Chromeは、サイトが潜在的に危険な許可を要求したときに部分的なURLフィンガープリントも送信するため、Googleがサイトを保護することができますGoogleはこの情報から実際のURLを特定できません。
（私自身の強調）
いくつかの誤検知がサービスに受け入れられる場合、より高速な検索と 妥当な拒否可能性 の利点を利用して、ハッシュのほんの一部のみを保存できます。
他のすべての答えは、URLをバックエンドサービスに「適切に」転送する方法に焦点を当てていますが、一般的な結論のようです。それは不可能です。
私は別のアプローチを提案したいと思いますが、それはあなたのユースケースではまったく不可能かもしれませんが、少なくとも議論することは価値のある方法だと思います。
バックエンドにURLを送信する代わりに、データベースをアドオンに送信してそこでルックアップを行わないのはなぜですか？
もちろん、これはあらゆる種類の新しい問題をもたらします。データベースはおそらく非常に大きく、ユーザーのマシンに必要のない情報が含まれている可能性があります。しかし、単純なアプリケーションや小規模なアプリケーションの場合、これは有効な解決策になる可能性があります。
これはユーザーのプライバシーにとってはあまり良くありません。例えば https://www.google.com/は常に同じハッシュを持っているので、誰がそれを閲覧したかがわかります。
プロジェクトのニーズによっては、自分に適した他のオプションを検討する必要がある場合があります。たとえば、オプションの1つが毎回すべてのURLを送信するわけではありません。 FQDNのみをチェックし、URL全体をチェックしないこともできます。これにより、プライバシーが大幅に向上します。