wsj.comは、ユーザーが何件の記事を読んだかをどのように追跡していますか？
私はウェブサイトがペイウォールの実装方法でユーザーを追跡する方法を探っていました。 WSJ.comには、コンテンツを読んだユーザーを検出するための最良の方法があります（コンテンツを読んだ方法を理解することはできません）。
ユーザーを追跡する（ペイウォールを設置する）ことが知られている標準的なメカニズムは、
- 要求パラメーター（紹介ヘッダーを含む）
- Cookie/LocalStorage /ファイルストレージ
- プライベートブラウジングまたは別のブラウザー（Cookieに関連する種類）
- ETagヘッダー（あまり知られていないユーザー追跡方法）
- IPアドレス
- WebRTC /サービスワーカー（バックグラウンドで実行）
- SSL証明書のキャッシング関連（記事を読む、その方法が明確ではなかった）
- ブラウザが送信した情報のフィンガープリント
Wsj.comに関しては、ページは数十のドメインから大量のJavaScriptをロードします。 SSL証明書は数十のウェブサイトで共有されています（コンテンツを提供するためにアカマイを使用していることが原因である可能性があります）
（ほぼ）白紙の状態であるにも関わらず、ウェブサイトがどのようにブラウザー全体を追跡しているか心配です
私がペイウォールを実装しなければならなかった場合、おそらくあなたが言及した方法の組み合わせで行くでしょう。
たとえば、Cookieは多くのユーザーにとって問題なく機能し、効率的であるため、それが最初の「防御線」になります。顧客からCookieを受け取った場合、それを使用してエントリを許可または拒否します。
Cookieが返されない場合はETagを使用する可能性があり、それでも機能しない場合は、ファジーソースIPアドレスマッチングと組み合わせたブラウザフィンガープリントにフォールバックします。
JavaScriptが有効になっている場合、ブラウザーのフィンガープリントは非常に効果的です（デモについては EFFのPanopticlick を参照）。誤検知が発生しますが、誰かの接続元のIPアドレスブロックを確認することと組み合わせると、非常に正確になります。職場にはインストールイメージに基づくコンピューターがたくさんあるので、同じブラウザーフィンガープリントを持っていると思いますが、数週間使用した後、大まかなチェックを行ったところ、いくつかのフィンガープリントが変更されました。理由はわかりません。多分それはマシンに追加のフォントをインストールする追加のソフトウェアをインストールしたためでした。
Cookieが標準的な方法であり、etagsがやや卑劣であり、フィンガープリントが最後になるのは、無害な顧客に影響を与えるフィンガープリントで誤った判断を下す可能性があるためです。それでも、無実の被害者にアクセスを許可するのは簡単です。誰かをロックアウトした場合、メッセージが誤っていると思われる場合は、将来私のドメインからのCookieを受け入れる必要があるというメッセージを表示します。
すべてのCookieを禁止することで、WSJがどのように実行するかを確認できます。WSJがまだあなたを識別している場合、Cookieだけでそれを実行しているわけではありません。ローカルストレージについても同じことを行います。次に、ETag関連のヘッダーをブロックできるプラグインをインストールし、それらがまだあなたを識別しているかどうかを確認します。含まれている場合は、JavaScriptを無効にします。それでも問題が解決しない場合は、Acceptヘッダーなど、他のさまざまなヘッダーの値を変更してみてください。