ハイライト
これまでのOrganizationは1人しか保持できない単なるデータ行に過ぎませんでした。これからは管理可能な専用ページとなります。同僚を招待し、ロールを割り当て、会社負担のキーを作成させることが可能です。また、Proxy Finderは「試行回数上限」とだけ返すのをやめ、直面したブロック要因を具体的に特定するようになりました。Browserに関しても、同一ページに対して一貫したブラウザプロファイル情報を返すよう改善されています。
新機能
実際に管理可能なOrganization機能
以前は同僚を追加するためにサポートへのメールが必要だったため、チーム内で別々の不要なサブスクリプションを契約するケースが発生していました。
DashboardにOrganization専用ページが新設され、3つのロールに対応しました。Ownerはキーの請求先となるサブスクリプションを保持するため常に1人のみ存在し、所有権は譲渡によって移行します。Adminは使用状況、請求、メンバーを管理します。Memberはサービスを利用します。招待はメールアドレス経由で行われ、未登録のユーザーも招待可能です。
Organization内のすべてのメンバーは、Organization所有のキーの作成や個人キーの移行を行えるため、開発者が業務利用で個人に課金されるキーを使う必要はありません。Organizationキーの使用量はOwnerのプランに請求され、確認画面にはどのプランから支払われるかが明記されます。Memberはキーの名前変更が可能ですが、再生成、無効化、削除の権限はOwnerとAdminに限定されます。これらは実行した瞬間にそのキーを使うすべての同僚に影響するためです。
Overview、Detailed Metrics、Recent Activity、キー一覧の各画面でOwnerフィルターが機能します。なお、MemberがOwnerのクォータを閲覧する必要はないため、Usage & LimitsおよびBillingは個人のみの表示を維持します。
Proxy Finderの推測を排除
「Download maxTry limit reached」というエラーは、すべての出口ノードがブロックされたのか、すべて応答しなかったのか、あるいは正常なページを取得したものの設定したカスタムルールで破棄されたのか区別がつきませんでした。これら3つはそれぞれ全く異なる対処が必要です。
失敗したタスクにattemptReportが含まれるようになりました。応答しなかった出口数、検知された防御機能によって拒否された数と該当ベンダー名、validate.statusによって拒否された数、防御の兆候がなくHTTP 200を返したもののvalidate.dataのみで失敗した数が確認できます。あわせて簡潔なサマリーテキストも提供されます。
特に最後のカウントが重要です。マッチしないコンテンツルールは、従来の測定基準ではあらゆる角度からブロックされている状態と見分けがつかず、いくらリトライしても解決しません。(validate rulesが成否を判定する仕組みの詳細はこちら。)
もう1つの改善点はプロファイルです。Proxy Finderは出口ノードのみをローテーションし、クライアントシグネチャは維持していたため、特定のブラウザプロファイルを拒否するサイトではプール内の全出口で拒否されていました。現在は拒否が発生した場合、予定されていたリトライの中でプロファイルも切り替えるため、タスクごとのリクエスト数やクレジット消費は変わりません。profileをご自身で固定している場合は動作に変更はありません。なお、極めて防御が強固なターゲットに対しては、送信するプロファイル以上に着信先の出口ノードが依然として重要になります。
Browserの整合性向上
以前はBrowserにUser-Agentを要求すると、要求しない場合よりも状況が悪化していました。3つのレイヤーがそれぞれリクエストの送信元について異なる認識を持っていたため、1つのリクエストがWindows、Mac、そしてフリートで実行されていないバージョンを同時に主張することがありました。現在は1つの値が一元的に決定され、起動、ページ、そのページが開始するワーカーなど、すべてに引き継がれます。
Client hintsはその文字列から導出されるため、sec-ch-ua、プラットフォーム、navigator.platformの間で整合性が保たれます。レスポンスには実際に送信された文字列が返されます。クリアランスクッキーはイグジットとUser-Agentの組み合わせに紐づくため、これは重要です。レンダラーに関する問い合わせも、ドキュメント内とワーカー内で同じ応答を返すようになり、積み重なる微小なシグナルの1つが解消されました。
これに合わせて、さらに3つの改善が行われました。
- 時計がイグジットに追従。 Browserはイグジットが存在する国のタイムゾーンで動作するため、現地時間をレンダリングするページでは現地の訪問者に表示される通りの内容が表示されます。国が不明な場合、時計は変更されません。
- WebRTCが他のトラフィックと同じパスを維持。 プロキシ設定はブラウザがTCP経由で送信するトラフィックを対象とします。WebRTCはそのパス上にないため、ICE candidateを要求するページには別の応答が返されます。Browserは、リクエストにイグジットが含まれる場合、常にこれを無効化します。
- アンカー付きURLの処理コストを適正化。
#reviewsで終わるURLは、以前は毎回タイムアウトまで待機していました。現在は通常通りの速度に戻っています。
より低コストなルーティングと、正確なDashboard表示
Impervaは拒絶ページだけでなく正常なページにもスクリプトを注入しますが、Autoは両者を区別できなかったため、正常なページでも不要にブラウザへエスカレーションされていました。あるレンタカーサイトでは、6回の試行で75クレジットと27.5秒かかっていましたが、現在は1回の試行、10クレジット、約6.5秒で完了します。セッションなしのリクエストに対する拒絶応答の中でセッションを渡してくるサイトもありますが、4つのエンジンすべてが、エスカレーションを行う前にそのセッションを直接送り返すようになりました。
Overviewのクレジットカードには消費されたすべてが表示され、請求対象としてラベル付けされていました。成功報酬型ではこれらに差異が生じ、その差額は実際のコストに影響するため、両方をカードに表示するようにしました。請求額を数値として表示し、その下に消費額をプロダクト別および合計で記載しています。Requestsカードも同様に分割されています。期間と詳細度も個別のコントロールになり、30分から1年、さらにカスタム範囲まで選択可能になったことで、「1D」と表示されながら30日間を開いていたボタンは廃止されました。
Playgroundでは、引き継ぎボタンで直前のレスポンスのプロファイルを選択できるようになり、入力していないプロファイルで送信されたリクエストでも、成功したバージョンを再実行できるようになりました。すべてのパラメーターはAPI referenceに記載されています。
Under the Hood
Proxy Finderはホストごとに保持する履歴を増やし、従来の12件前後から32件の出口IPを保持するようになりました。本番A/Bテストでは、難易度の低いターゲットに対しては同等、難易度の高いターゲットではフリート全体のレイテンシを維持したまま、ページ取得の中央値が5.5秒から3.8秒に改善しました。1つのターゲットのみ逆の結果となり、現時点では原因が不明なため、個別に計測を行っています。
失敗するタスクはいずれにせよ失敗します。違いは、1分でチケットをクローズできるか、見当違いの計測に午後を費やすかです。