本日、当社はプライベートアクセストークンを発表しました。これは、本物のユーザーがお客様のサイトを訪れていることを検証する、完全に不可視でプライベートな方法です。macOSまたはiOSの次期バージョンなど、これらのトークンをサポートするオペレーティングシステムを使用している訪問者は、CAPTCHAを完了したり個人データを提供することなく、自分が人間であることを証明できるようになりました。これにより、これらのユーザーに提供されるCAPTCHAのほぼ100%が排除されます。
これはどういうことなのでしょうか？
インターネットユーザーの場合：
当社は、お客様のモバイルWeb体験をより快適にすると同時に、他のネットワークよりもさらにプライベートなものにします。
サポートされているiOSまたはMacデバイス(その他のデバイスは近日公開予定！)がCloudflareネットワークにアクセスする際にCAPTCHAが表示されることはありません。
Webやアプリケーション開発者の場合：
デバイスベンダーによって直接検証された、本物のデバイスと署名されたアプリケーションからユーザーがアクセスしていることを確認できます。
面倒なSDKを維持することなく、ユーザーを検証することができます。
Cloudflareのお客様の場合：
何もする必要はありません！Cloudflareは自動的にプライベートアクセストークンを要求し、利用します
訪問者にはCAPTCHAが表示されず、訪問者のデバイスからのデータ要求も少なくなります。
プライベートアクセストークンの導入
過去1年間、CloudflareはApple、Google、その他の業界リーダーと協力し、プライバシーパスプロトコルを拡張し、新しい暗号トークンをサポートするようになりました。これらのトークンは、開発者やセキュリティチームにとってアプリケーションのセキュリティを簡素化し、人がデバイスを使用しているかどうかを判断するための従来のサードパーティ製SDKベースのアプローチを陳腐化させます。これらのトークンは、ブラウザ、ブラウザから呼び出されるAPI、およびアプリケーション内で呼び出されるAPIで機能します。当社は、これらの新しいトークンをプライベートアクセストークン(PAT)と呼んでいます。今朝、Appleは、PATがiOS 16、iPad 16、macOS 13に組み込まれると発表しました。近い将来、他のベンダーもサポートを発表すると思われます。
CloudflareはすでにPATをManaged Challengeプラットフォームに組み込んでおり、この機能を利用するお客様は自動的にこの新しい技術を利用し、対応デバイスのブラウジング体験を向上させることができます。
モバイル環境ではCAPTCHAは機能せず、PATがその必要性をなくします
当社は、CAPTCHAがいかにひどいユーザーエクスペリエンスであるかについて何度も書いてきました。ただし、モバイル端末でのユーザーエクスペリエンスがどれほど悪いかについては、特に説明していません。技術としてのCAPTCHAは、ブラウザベースの世界向けに構築され、最適化されました。これらは、一般的に1つのサイズがすべてにフィットするウィジェットまたはiframeを介してデプロイされ、レンダリングの問題を引き起こしたり、入力ウィンドウがデバイス上で部分的にしか表示されません。モバイル画面上の面積が小さいため、本質的に技術のアクセス性が低下し、CAPTCHAの解決がより困難になり、JavaScriptと画像ファイルをレンダリングする必要があるため、画像の読み込みが遅くなり、お客様の帯域幅を過剰に消費します。
使いやすさは別として、モバイル環境はAPI駆動型になりつつあるという点で、さらなる課題を抱えています。CAPTCHAは、JavaScriptがレンダリングできない、あるいはWebViewが呼び出せないAPI環境では、単純に機能しないのです。そのため、モバイルアプリの開発者は、必要なときにユーザーに挑戦するための簡単な選択肢を持っていないことがよくあります。不便なSDKを使ってCAPTCHAをアプリに直接埋め込むという手段を用いることもあります。この場合、CAPTCHAの埋め込みとカスタマイズに手間がかかり、メンテナンスと監視を続ける必要があり、その結果、放棄率が高くなります。このような理由から、現在、当社のお客様がCAPTCHAの表示を選択した場合、モバイルでは20％の割合でしか表示されません。
先日、Managed Challengeのプラットフォームを利用して、CAPTCHAの使用量を91%削減した方法をご紹介しました。しかし、モバイルでのCAPTCHA体験は非常に悪いので、特にモバイルでのCAPTCHA使用をさらに減らすことができる方法を別途検討しています。
サイトが訪問者に異議を唱えられない場合は、より多くのデータを収集します
つまり、APIを保護するためにCAPTCHAを使うことはできないか、あるいはUXがひどすぎてモバイルWebサイトで使うことはできない、ということです。訪問者が本物かどうかを確認するためには、どのような選択肢が残されているのでしょうか。よくあるのは、一般にフィンガープリンティングとして知られている、クライアント固有のデータを見ることです。
デバイスのIMEIやセキュリティパッチのバージョンを尋ねたり、画面サイズやフォントを調べたり、インタラクティブなタッチスクリーンイベントのような人間の行動を示すAPIの存在を確認したり、それらを指定されたクライアントの期待される結果と比較したりすることができます。しかし、このようなデータ収集はすべてコストがかかり、結局はエンドユーザーを尊重したものではありません。プライバシーを重視し、インターネットをより良くすることに貢献する企業として、当社は提供するサービスの安全性を損なうことなく、できるだけ少ないデータを使用したいと考えています。
もう1つの方法は、デバイス検証チェックを提供するシステムレベルのAPIを使用することです。これには、AppleプラットフォームのDeviceCheckおよびAndroidのSafetyNetがあります。アプリケーションサービスは、これらのクライアントAPIを独自のサービスで使用して、通信しているクライアントが有効なデバイスであることを表明することができます。ただし、これらのAPIを採用するには、アプリケーションとサーバーの両方を変更する必要があり、SDKと同様に保守が困難な場合があります。
プライベートアクセストークンは、フィンガープリンティングなしで検証することにより、プライバシーを大幅に向上させます
これは、PATの最も強力な側面です。デバイスの検証に役立つデータをすでに持っているデバイスメーカーのようなサードパーティと提携することで、検証プロセスの一部を抽象化し、_実際に収集したり、触ったり、そのデータを自分で保存したりせずに_データを確認することができるのです。当社はデバイスに直接問い合わせるのではなく、デバイスベンダーに依頼します。
従来のWebサイトのセットアップにおいて、最も一般的なCAPTCHAプロバイダーを使用した場合：
訪問したWebサイトは、URL、お客様のIPおよびいくつかの追加のユーザーエージェントデータを把握しています。
CAPTCHAプロバイダーは、お客様の訪問したWebサイト、IP、デバイス情報を把握し、ページ上でのインタラクションデータを収集し、このデータをGoogleがお客様を見たことのある他のサイトに結びつけます。これにより、サイトとデバイスの両方における閲覧状況のプロフィールが構築され、さらにお客様が個人的にそのページとどのように関わっているかが分かります。
PATを使用する場合、デバイスデータは分離され、関係者(メーカーとCloudflare)間で明示的に交換されることはありません
Webサイトが知るのは、接続を行うために必要なURLとIPだけです。
デバイスメーカー(アテスター)は、お客様のデバイスを認証するために必要なデバイスデータだけは分かりますが、お客様が閲覧したWebサイトは分かりませんし、IPも分かりません。
Cloudflareは、お客様が訪問したサイトは把握していますが、デバイスやインタラクションの情報は一切分かりません。
当社は、このプロセスのために収集された基本的なデータを実際に必要としませんし、求めてもいません。ただ、訪問者がデバイスやユーザーエージェントを偽装しているのかどうかを検証したいだけです。プライベートアクセストークンは、基本的なデータを一切必要とせず、その検証状態を直接取得することを可能にします。これにより、重要なシグナルを直接見ることなく、その信憑性をより確信することができます。
プライベートアクセストークンによるデータの区分け方法
プライベートアクセストークンでは、四者が共通のフレームワークで協力して、匿名かつ偽造不可能なトークンを生成・交換することに合意しています。このプロセスに四者すべてが参加しなければ、PATは機能しません。
オリジン。クライアントからリクエストを受け取るWebサイト、アプリケーションまたはAPIです。Webサイトがオリジンへのリクエストを受け取ると、オリジンはリクエストを送信したクライアントからトークンを探して要求することを把握する必要があります。Cloudflareのお客様の場合、Cloudflareがオリジンとして(お客様の代わりに)トークンのリクエストと処理を行います。
クライアント。訪問者がオリジンにアクセスするために使用するツールです。これは通常、Webブラウザまたはモバイルアプリケーションです。当社の例では、クライアントをモバイルSafariブラウザとします。
アテスター。アテスターは、トークンが発行される前に、クライアントが何か(たとえば、モバイル端末が有効なIMEIを持っていること)を証明するよう依頼する者です。下記の例では、デバイスのベンダーであるAppleがアテスターにあたります。
イシュアー。イシュア―はプロセスの中で唯一、実際にトークンを生成、または発行する者です。アテスターはオリジンが信頼するイシュア―にAPIコールを行い、イシュア―にトークンを生成するよう指示します。当社の場合、Cloudflareもまたイシュア―となります。
上記は、訪問者がiPhoneでSafariブラウザを開き、example.comにアクセスしようとした例です。
例ではオリジンをホストするためにCloudflareを使用しているので、Cloudflareはブラウザにトークンを要求します。
SafariはPATをサポートしているので、AppleのアテスターにAPIコールを行い、認証を依頼します。
Appleのアテスターは様々なデバイスコンポーネントをチェックし、それらが有効であることを確認した後、CloudflareイシュアーにAPIコールを行います(オリジンとして動作するCloudflareはCloudflareイシュアーを使うことを選択するため)。
Cloudflareイシュアーはトークンを生成してブラウザに送信し、ブラウザはそれをオリジンに送信します。
Cloudflareはこのトークンを受け取り、このユーザーにCAPTCHAを表示する必要がないと判断するために使用します。
少し複雑に聞こえるかもしれませんが、一番良いのは、このプロセスにおいて_Webサイトは何もしていないことです。_トークンの要求、検証、トークンの生成、受け渡し、これらすべてが、ユーザーとWebサイトの両方からは目に見えないサードパーティによって舞台裏で行われているのです。AppleとCloudflareが協力することで、このリクエストはより安全になり、やり取りされるデータは減少し、ユーザーがCAPTCHAを見る必要がなくなるのです。そして、ユーザーデータの収集と交換を従来よりも少なくすることで、これを実現しました。
ほとんどのお客様は、プライベートアクセストークンの利用のために何もする必要がありません
PATを活用するには、ファイアウォールルールの応答オプションとして、従来のCAPTCHAではなくManaged Challengeを選択するだけでよいのです。Cloudflareのお客様の65%以上は、すでにこれを実践しています。当社のManaged Challengeプラットフォームは、すべてのリクエストに自動的にトークンを要求し、クライアントがプライベートアクセストークンに対応している場合は、トークンを受け取ります。iOSまたはmacOSのデバイスを使用している訪問者は、OSをアップグレードすると、自動的にCAPTCHAをより少なく表示するようになります。
当社にとって、これは最初のステップにすぎません。当社は、他のクライアントやデバイスメーカーにもPATフレームワークを利用してもらえるよう、積極的に働きかけています。新しいクライアントがPATフレームワークを利用し始めると、そのクライアントからお客様のサイトに来るトラフィックは自動的にトークンを要求するようになり、訪問者は自動的にCAPTCHAを見る回数が減ることになります。
近々、他のセキュリティ製品にもPATを組み込んでいく予定です。近い将来、いくつかの発表がありますので、ご期待ください。