4

私は、会社が新しい訪問者に贈り物を贈りたいと思っているWebサイトの構築に着手しようとしています。贈り物には金銭的価値があり、サイトがゲーム化されているのではないかと心配しています。私は、誰もがギフトの在庫全体を使い果たす可能性を減らすのに役立つ方法を探しています。

計画ではFacebookとの統合が必要であるため、FB資格情報を使用して認証することで、新しい訪問者が実際に実在の人物であるという少なくとも少しの自信が得られます（数百のFBアカウントの作成をスクリプト化してから、それらを使用して認証することはできません。簡単なタスク）。

ただし、FBアカウントを持っていない新規訪問者に報酬を与えるという要件もあり、ここで私はアイデアを探しています。数え切れないほどの数のメールアドレス（me + 1 @ gmail.com、me + 2 @ gmail.comなど）を取得するのは非常に簡単なので、メール検証システム自体はそれをカットしません。クレジットカード番号を尋ねるのはあまりにも障壁だと言われています。

このような状況に対処するためのかなり堅実な戦略やサービスはありますか？

編集：「ギフト」は仮想です-クーポンのように

4

4 に答える 4

4

結局のところ、これは困難で敗北の戦いです。システムを打ち負かすインセンティブがある場合、誰かが試み、最終的に成功します。（たとえば、これまでに実装されたすべてのDRMスキームを参照してください。）

とはいえ、システムのゲームのしやすさを減らすための戦略があります。

  • FBアカウントがそれほど安全だとは思いません。新しいFBアカウントを作成する際の障壁は、新しいWebメールアカウントを作成するよりもおそらく無視できるほど高くなります。
  • IPアドレスによるフィルタリングは大惨事になります。単一のIPアドレス（咳、AOL）のプロキシの背後に数千人のユーザーがいる可能性があり、詐欺師はボットネットを使用して各アカウント要求を一意のIPに配布する可能性があります。IPを先制的にブロックするよりも問題が発生する可能性がありますが、後で（たとえば、実際に報酬を送信する前に）リクエストを分析して、IPからの疑わしい動作がたくさんあるかどうかを確認できます。
  • クレジットカード番号を要求することは良いスタートですが、あなたはすでにそれを除外しています。また、1人の個人が実際のクレジットカード、デビットカード、および使い捨てカード番号の間に10以上のカード番号を持つことができることを考慮してください。
  • SMS経由でPSTN番号に確認コードを送信することを検討してください。これにはいくらかのお金（メッセージあたり数セント）がかかりますが、詐欺師がそれらのメッセージを受信するために多数の電話番号を取得するには、かなりの額の変更が必要です。（インセンティブの価値によっては、プリペイドSIMのコストが高額になる場合があります。）もちろん、詐欺師がすでにSMSを受信するPSTN番号を多数持っている場合、これは機能しません。
于 2012-02-14T03:43:08.940 に答える
2

私が最初に疑問に思うのは、これらの贈り物を実際の住所に送る必要があるかどうかです。100個の電子メールアドレスまたはFBアカウントをスプーフィングするのは簡単ですが、明らかに一意の100個の物理アドレスを思い付くのははるかに困難です。

もちろん、あなたは彼らに電子クーポンか何かを与えているかもしれないので、住所はオプションではないかもしれません。

昔々、私はコンテスト審査ユーティリティのためにかなり強力なアンチゲームスクリプトを書きました。これは何ヶ月にもわたる開発であり、非常に複雑すぎて詳細に説明することはできませんが、スクリプトの基本的な機能の概要を説明できます。

1つは、ユーザーがコンテストに応募したときにできる限りの詳細を記録したことです。基準のグループ（IP、ブラウザーなど-なりすましの可能性があるすべてのもの）からのログイン/送信間の平均時間を考慮に入れることで、アカウントの明らかな類似点を見つけるのは非常に簡単でした。さらに、acct1 @ yahoo.com、acct2 @ yahoo.comなどの明らかなゲームのアカウントクレデンシャルを、信頼性だけではないレーベンシュタイン距離と、さまざまなものを分解した解析スクリプトの組み合わせを使用して比較しました。クレデンシャルの詳細とパターンを探しました。

各テストのスコアに応じて、ゲームの確率と可能なアカウント一致のリストを割り当てました。次に、結果からそれらを除外するのは管理者の責任でした。

アルゴリズムを改良するために何ヶ月も続けることができ、それを完璧にすることは決してできません。そのため、私のスクリプトはアカウントにフラグを立てるだけで、自動アクションを実行しませんでした。

于 2012-02-14T03:46:35.913 に答える
0

あなたは在庫について話しているので、あなたの贈り物は実際の物理的なアイテムであると仮定できますか？

その場合、ギフトの配達には配達のための物理アドレスが必要になります-一意のアドレスを要求する（または、重複するアドレスを許可するが、手動レビューのためにそれらのユーザーにフラグを立てる）ことは適切な制限です。

私の前提は次のとおりです。理論的にはスクリプトを実行して数百のFacebookまたはGoogleアカウントを作成できますが、数百の異なる実世界の配信場所を物理的に制御することは、まったく異なるクラスの問題です。

于 2012-02-14T03:47:43.343 に答える
0

すべてのセキュリティの代わりに、より「現実的な」ソリューションを提案します。アドレスごとに 1 つのクーポンであることを明確にします。物理的な（配達および/または支払い）住所。その後は、必要に応じて、メールなどで制限するかもしれませんが、最終的には、クーポンを受け取る人ごとではなく、実際のエンドユーザーごとに制限してください。

于 2014-03-04T06:55:35.713 に答える