Opinion

このニュースは背筋が凍りました。 MetaがロシアのYandexと同じ手口でユーザーの行動を追跡していたことが判明、何百万ものウェブサイトに「スマホのアプリと通信するコード」を埋め込んで追跡しておりブラウザの履歴を削除しても無駄 通常、ウェブブラウザには「同一オリジンポリシー (Same-Origin Policy)」というセキュリティ機能があり、異なるオリジン（プロトコル、ホスト、ポートの組み合わせ）間でリソースを共有することを厳しく制限しています。Cross-Origin Resource Sharing (CORS) はこの制限を緩和するためのメカニズムですが、明示的な許可が必要です。 Meta Pixel がこの規制をどのようにバイパスしたのか、最新の調査結果に基づいて説明します。 localhostソケットとWebRTCの悪用 Meta PixelがCross-Originの規制をバイパスした主な手口は、以下の組み合わせにありました。 localhostポートの利用: Metaが提供するAndroidアプリ（Facebook、Instagramなど）が、デバイス内の特定のローカルポート（例えば12580-12585）をサイレントにリッスンしていました。つまり、アプリがウェブサイトからの通信を受け入れる準備ができていたということです。 ウェブサイトに埋め込まれたMeta PixelのJavaScriptコードは、モバイルブラウザ上で実行される際に、localhost (127.0.0.1) のこれらのポートに対して通信を試みました。 localhostへの通信は、ブラウザの同一オリジンポリシーのスコープ外、またはその穴を突く形で行われました。ブラウザは、自身のデバイス内のローカルホストへの通信に対しては、比較的制限が緩い場合があります。 WebRTC (Web Real-Time Communication) の利用: Meta Pixelは、WebRTCというリアルタイム通信プロトコルを利用して、_fbp Cookie（ブラウザを識別するファーストパーティCookie）などの追跡データをlocalhostのアプリに送信していました。 WebRTCは、ブラウザ間の直接通信や、ブラウザとローカルネットワーク内のデバイスとの通信を可能にするための技術であり、その機能がこの追跡に悪用された形です。特に、WebRTCのSDP (Session Description Protocol) というセッション情報をやり取りする部分が利用されたと報告されています（SDP munging）。 アプリ側でのデータリンケージ: Androidアプリは、localhost経由で受け取った_fbp Cookieを、アプリにログインしているユーザーの永続的な識別子（Facebook IDなど）と紐付けました。 これにより、ユーザーがブラウザでCookieを削除したり、シークレットモードを使ったり、Facebook/Instagramにログインしていなくても、そのウェブ閲覧履歴がMetaのユーザーアカウントに紐付けられて追跡されるという、従来のプライバシー保護メカニズムを回避する仕組みが実現されました。 Metaとサイト運営者の責任 実際に、"Disclosure: Covert Web-to-App Tracking via Localhost on Android“という調査報告書をチェックすると、日本のドメインだけでも以下のリストに見られるようなウェブサイトがMeta Pixelを使用している惨状が明らかになります。これはほんの一部に過ぎません。 https://auctions.yahoo.co.jp/ https://beauty.hotpepper.jp/ https://dmarket.docomo.ne.jp/ https://grapee.jp/ https://mechacomic.jp/ https://nlab.itmedia.co.jp/ https://page.auctions.yahoo.co.jp/ https://trilltrill.jp/ https://www.boatrace.jp/ https://www.cmoa.jp/ この状況は、Metaだけでなく、サイト運営者にも重い責任 があることを示しています。 この惨状から、私は次のことを強く要求します。 まず、Metaは今まで不法に採取したデータをすべて廃棄すること。 次に、サイト運営者はMetaから受け取った全ての違法データを廃棄すること。 これらが、ユーザーのプライバシーを守るために最低限必要な措置です。 楽天ad4U 今回のMeta Pixelの手口は、かつての「楽天ad4U」を想起させます。楽天ad4Uも一種の行動ターゲティング広告で、Adobe Flashオブジェクトの中に数千個のURLへのリンクを埋め込み、それぞれのURLを訪れた形跡があるか否かをCSSの色判定で調べる手口でした。 ...

不安しかない au IDや、「dアカウント」にログインしようとしたら、なぜか回線認証で詰んで先に進めない。機種変更したら、これまで使えていたサービスに紐付けられたdアカウントの再設定で地獄を見た──。そんな経験、ありませんか？ なぜなら、その背後には 「回線を持っているがゆえに、不便を強いられる」という、キャリア認証システムの根本的な問題 がちらついていたからです。 「dアカウント」にせよ、「au ID」にせよ、その 「King of ゴミ」 とも言うべき、回線認証の強要は、我々のデジタルライフを大きく阻害しています。ITmediaでも報じられたように、なぜdアカウントのUI/UXはこれほどまでに悪い評価で衆目の一致する所となっているのか。今回は、その根深い問題点、特に回線認証という 時代錯誤な仕組みが引き起こす弊害 に焦点を当て、なぜ我々がこれほどまでに不満を抱えているのかを徹底的に掘り下げていきます。 先ごろ、発表されたSBI住信の買収で不安を漏らす声が噴出しています。実際、ITmediaでも以下のような記事が書かれています。 なぜ、「dアカウント」は嫌われているのか　住信SBIネット銀行買収で、不安の声が上がるワケ 終わってるUser eXaust：キャリア認証の「糞」っぷり 私は家計簿アプリMoney Forwardでau PAYを含む複数の金融サービスを集約して管理していますが、その連携方法がユーザーに多大な「苦痛」をもたらしています。 Money Forward連携と「糞」なキャリア認証 まず、Money Forwardはau ID側からの適切なAPI提供がないため、不安定な「スクレイピング」でデータを収集せざるを得ません。これにより、au IDの認証が頻繁に切れてしまい、再認証の度に地獄を見ます。 この再認証プロセスが、まさに「User eXhaust」の極致です。 痛みしかないフロー Money Forwardでau Payからの認証切れを発見する おもむろに再認証を始める 認証しようとしたら、最初の壁、パスワード認証できないにぶつかる スマートフォンからパスワード認証を有効化しようとする スマートフォンアプリからは該当操作が見つからない wifiからは設定できない、回線認証の強制 糞そのもののキャリア認証 パスワード認証の無意味化と強制的なSMS認証: au IDのパスワード認証は、わずか15分で自動的に無効化されます。さらに、パスワードを有効にしようとすると「悪用に関する警告」が表示された上に、時代遅れのSMS認証が強制されます。安全で便利な時間ベースの二段階認証（TOTP）は選択肢にすらありません。 回線認証の強制とWi-Fi切断の強要: パスワード認証が無効化されると、次に強制されるのは「Wi-Fiを切って、VPNをオフにしろ」という「愚劣な回線認証」です。安定したWi-Fiを切り、特定のモバイル回線で接続し直すという不必要な手間は、ユーザーに計り知れないストレスを与えます。 設定変更の困難さ: これらのパスワード認証に関する設定は、My auアプリには存在せず、Webブラウザからしかアクセスできません。しかも、そのWeb設定もスマートフォンからしか行えないという多重の制約があり、スマートフォンが手元にない状況では完全に「詰み」ます。 PayPay連携も「アホすぎる」 PayPayの連携方法も同様にユーザーを疲弊させます。Money ForwardとPayPayを連携させる際、API連携ではなく、スマートフォンアプリ間で「インテント」を飛ばすという、極めて非効率で不安定な方法を強いてきます。この理解しづらい手間は、金銭管理という重要なタスクにおいて、ユーザーに「アホすぎる」苦痛を与えています。 信頼性と安定性の問題: アプリ間の連携は、アプリのバージョン、OSのバージョン、端末の設定など、様々な要因で不安定になる可能性があります。 バッテリー切れやアプリの不具合など、何らかの理由でPayPayアプリが使えない場合、連携自体ができなくなるリスクもあります。 テックジャイアントとキャリア認証の雲泥の差 GoogleやMicrosoftといった世界のテックジャイアントは、現在、パスキー、TOTP（時間ベースワンタイムパスワード）、フォールバックとしてのSMS、そして最終手段としての事前配布解除コードを組み合わせた認証基盤を標準としています。 これらの企業は、ユーザーがどのデバイス、どのネットワークからでも安全かつシームレスにサービスを利用できるよう、以下の点を重視しています。 フィッシング耐性の高いパスキーを基幹とする。 オフラインでも利用可能なTOTPを次点とする。 利便性とセキュリティを両立させる。 「回線認証」などという愚劣な認証を主要な手段として導入することはありません。 信用性が無い理由 古い技術への固執: 時代遅れで脆弱性が指摘されているSMS認証を主軸にしたり、利便性を著しく損なう回線認証に固執したりする時点で、最新のセキュリティ脅威に対する認識が甘いか、対応能力が低いと見なされます。 利便性の犠牲とユーザーへの負担: ユーザーに多大な手間やストレスを強いる認証システムは、結果的にユーザーがセキュリティ対策を回避しようとする行動を誘発しかねません。例えば、不便な設定を避けたり、パスワードを使い回したりするリスクを高めます。 「技術的腐敗」: 認証基盤が「技術的腐敗」の状態にあるということは、システム全体の整合性や信頼性が低いことを意味します。このような基盤の上で金銭取引が行われているとなると、潜在的な脆弱性や予期せぬトラブルのリスクが懸念されます。 ...