ハイライト
ブラウザプロファイルの選択が、リクエストごとの設定項目になりました。希望するブラウザとOSを指定すると、フィンガープリントとヘッダーがそれに合致したものになります。今週、SingleはBrowserを起動することなく、さらに2つのチェック（SiteGroundおよびeBayの計算チェック）を完了できるようになりました。また、DashboardのActivityビューには、内部で実行された処理ではなく、リクエストした内容が記録されるようになりました。
新機能
リクエストごとのブラウザプロファイル選択
これまではunblocker: trueが1つのシグネチャ（その時点のデフォルト）を選択するのみでした。今回のアップデートにより、個別に指定可能になりました。
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
または、ブラウザとOSの組み合わせを指定します:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
APIは未定義の組み合わせを名前で拒否し、利用可能な一覧を返します。そのため、タイポによって意図しないシグネチャが暗黙のうちに送信されることはありません。
完全なカタログは GET /api/profiles にあります。これは機密情報ではなく機能一覧であるため、公開されています（キーは不要です）。本稿執筆時点で、Windows、macOS、Android、iOS上のChrome、Firefox、Edge、Safari、Torにわたる79個のプリセットが存在します。Playgroundも同じリストを参照するため、ドロップダウンにはコードから指定可能な項目が常に正確に表示されます。
これが重要な理由: ターゲットがOSごとにリクエストをプロファイリングしている場合や、チームが特定の防御を回避できるスタックをA/Bテストしている場合に、他の要素を変更しつつその変数を固定できるようになります。
SingleがSiteGroundおよびeBayの計算チェックをクリア
以前はBrowserへのリダイレクトを余儀なくされていた2つの防御が、Singleでクリアできるようになりました。eBayは独自のProof-of-Workチャレンジ（Argon2パズル）を送信し、SiteGroundは共有ホスティングWebの大部分で独自のチェックを実行します。どちらもレンダリングなしで解決されるため、レスポンスは単一のHTTPリクエストの形式で返され、それに応じた価格が適用されます。
レスポンス内の防御シグナルも拡張されました。Browserのレスポンスに defenses: { present, cleared } が含まれるようになり、ページの前にどのベンダーが存在し、それを回避できたかを確認できます。課金も同じルールに従います。クリアしたベンダーは、どのブランドであってもすべてカウントされます。これまでは1つのチェックサービスのみがインタラクティブページとして課金されていましたが、さらに3つが同様の対象となりました。
DashboardのActivityビューを刷新
DashboardのActivityリストにある2つのカラムで表示に問題がありました。HTTPメソッドはすべての行で常に POST と表示されていました（すべてのエンドポイントがPOSTであるため、このカラムは意味のない定数となっていました）。また、Playgroundの呼び出しにおけるクライアントIPには、RunをクリックしたユーザーではなくPlaygroundが呼び出された場所が記録されていました。
両方とも修正されました。メソッドカラムには、リクエストボディ内で送信した動詞が表示されるようになりました。Playgroundの行のクライアントIPには、サインインしたユーザーのブラウザIPが表示されます。これは署名付きPlaygroundトークン内に保持されるため、APIクライアントが偽装することはできません。
これに合わせて、ビューの残りの部分も再構築しました。テーブルはカラムを非表示にすることなくノートPCの画面に収まり、プロダクトカラムはリクエスト行に統合され、詳細パネルにはタブが追加されてリクエスト、レスポンス、防御サマリーを個別にスクロールできるようになりました。
請求: プラン変更時の3Dセキュア対応
カード発行会社が（初回契約時だけでなく）プラン変更時にも3DS認証を要求する場合、その処理がトリガーされず変更が自動的にロールバックされていました。現在は正常にトリガーされます。先月プランを変更しようとして何も起きなかったように見えた場合は、これが原因です。
内部の実装
Playgroundは、取得したサイトのデータからレスポンスヘッダーを構築することを拒否します（早期に検出されたヘッダーインジェクション系のバグへの対処）。Dashboardの課金エンドポイントは、応答前に呼び出し元がリソースを所有していることを検証し、IDORの経路を遮断します。
6日にビルドの途中でデプロイホストのディスクが一杯になり発生した停止事故を受け、デプロイパイプライン自体にも1週間かけて集中的な修正を加えました。ディスク容量に余裕がない場合はすべてのサービスでビルドを拒否し、デプロイは競合させずに直列化し、バックエンドが不安定になってもゲートウェイは稼働し続け、各サービスは30秒後に強制終了されるまでハングするのではなくSIGTERMで適切に終了するようになりました。
これまで長い間、「どのブラウザシグネチャを使用するか」は弊社側で判断して決定していました。しかし、今後はその必要はありません。