web-dev-qa-db-ja.com

複数のタイプの追跡

私が製品のレビューを持っているシステムでは、偽のレビューを避けるために、私は次のことをすることを考えました：

  1. アカウントごとに1つのレビューを制限する->この手段をバイパスするために、ユーザーは複数のアカウントを作成できます。
  2. 各製品のブラウザフィンガープリントを制限します。この手段を回避するために、悪意のあるユーザーに対して新しいアカウントを作成することはできません。しかし、その後、彼は新しい指紋を取得するためにブラウザを変更することができました。
  3. 各製品のレビューのIPを制限します。 私の質問はこのステップについてです。各製品でIPを制限すると、企業や学校が大勢のユーザーに対して同じ静的IPを使用していることはわかっていますが、問題はそれではありません。私の問題は動的IPについてです。正当なユーザーが以前に登録した別のユーザーのIPを受け取った場合、そのユーザーは新しいレビューを作成できません。それで、最初の2つのステップだけを使用する必要がありますか？このアプリのメンバーである2人が、同じ製品についてレビューを書きたい、同じIPを受け取っている実際の確率はどれくらいですか？これは単なる妄想ですか、それとも実際のシナリオでしょうか？悪意のあるユーザーは新しいIPを簡単に取得できるため、この手順は簡単に回避できます。
  4. 私はevercookieのようなものには興味がありません。
  5. 追跡する別の方法はありますか？
web-applicationuser-trackingfingerprinting
1
user2990084

私の意見では、IPによる制限は厳しすぎます。

  • あなたが言ったように、動的IPには問題があります。ただし、IPはそれほど頻繁に変更されないため、特定の時間枠内でのみこの制限を適用すれば、これだけで解決できる可能性があります。
  • しかし、企業や機関は内部でプライベートIPアドレスを使用することが多く、インターネットゲートウェイはほとんどありません。これは、そこにいるすべてのユーザーが同じ発信IPを持っていることを意味します。
  • そして、DS-Liteと同様のアクセス方法。ここでは、すべてのユーザーに十分なパブリックIPv4アドレスがないため、ユーザーはプライベートIPv4アドレスのみを取得し、同じパブリックIPv4アドレスを共有します。ただし、通常は一意のIPv6アドレスがあります。この種のアクセスは、おそらくほとんどのモバイルネットワーク、アジアの大部分だけでなく、ヨーロッパやアメリカの一部のISPにも影響を及ぼします。

アカウントごとのレビューを制限しすぎて、アカウントの作成を難しくする、つまりキャプチャなどを使用するのが最善の方法だと思います。偽のアカウントを検出して、後でアカウントを閉じてレビューを削除できるようにする調査もあります。たとえば、 最近のUSENIX会議からの大規模ソーシャルオンラインサービス での偽のアカウントの検出を支援します。

もちろん、悪用を制限するために行うすべてのことは、それをより複雑にする可能性があり、一部の良性ユーザーがシステムを使用することを思いとどまらせる可能性があります。しかし、虐待が多すぎると、あなたのシステムは彼らにとっても役に立たなくなります。バランスを正しく取るのはおそらく非常に困難であり、ソーシャルネットワークや無料のWebメーラーなどを見ると、良性のユーザーがシステムを簡単に使用できるように手順を絶えず変更していますが、スパマーがシステムを悪用するのは困難です。スパマーも技術を進化させるので、おそらく定期的にシステムを調整する必要があります。または、グーグルなどが自分のアカウントに対して行う検証から利益を得ようとし、アカウントの作成と検証をすべて自分で行う代わりに、ユーザーにグーグルまたはフェイスブックのアカウントでサインインさせることもできます。

1
Steffen Ullrich

クライアント識別メカニズムのテクニカル分析 Googleから、多くのブラウザおよびネットワークレベルのヒューリスティックから指紋ブラウザ/ユーザーまでの詳細：

1.1 HTTP cookies
1.2 Flash LSOs
1.3 Silverlight Isolated Storage
1.4 HTML5 client-side storage mechanisms
1.5 Cached objects
1.6 Cache metadata: ETag and Last-Modified
1.7 HTML5 AppCache
1.8 Flash resource cache
1.9 SDCH dictionaries
1.10 Other script-accessible storage mechanisms
1.11 Lower-level protocol identifiers

これらの手法の実装例と、さらにいくつかの実装例は BrowserLeaks にあります。

0
Dr. mattle

2段階認証を使用してみませんか？レビューを実行するすべてのユーザーは、自分の携帯電話番号に認証コードを取得する必要があります。ブラウザでそのコードを提供した後、彼/彼女は製品レビューを実行することができました。

セル番号には制限があるはずです。特定のセル番号を持つ1人のユーザーが1回レビューできます。

0
mak93129