プライバシーサンドボックスの提案と Chrome の対応に関して受け取ったエコシステムのフィードバックをまとめた 2022 年第 3 四半期の四半期レポートです。
CMA へのコミットメントの一環として、Google は、プライバシー サンドボックスの提案に対する関係者のエンゲージメントプロセスに関する四半期レポートを公開することに同意しました(コミットメントの第 12 段落および 17(c)(ii) を参照)。これらのプライバシーサンドボックスに関するフィードバック要約レポートは、フィードバックの概要に記載されているさまざまなソースから Chrome が受け取ったフィードバックを集計して生成されます。これには、GitHub のイシュー、privacysandbox.com で利用できるフィードバックフォーム、業界関係者との会議、およびウェブ標準フォーラムが含まれますが、それに限定されていません。Chrome は、エコシステムから受け取ったフィードバックを歓迎し、それから学んだことを設計の決定に統合する方法を積極的に模索しています。
フィードバックのテーマは、API ごとに発生率によってランク付けされます。これは、特定のテーマに関して Chrome チームが受け取ったフィードバックの量を集計し、量の多い順に整理することによって行われます。一般的なフィードバックのテーマは、公開会議(W3C、PatCG、IETF)、直接的なフィードバック、GitHub、および Google の内部チームや公開フォームを通じて浮上したよくある質問からの議論のトピックを確認することによって特定されました。
より具体的には、ウェブ標準化団体の会議の議事録がレビューされ、直接的なフィードバックについては、1 対 1 で行われた Google の関係者会議の記録、個々のエンジニアが受け取ったメール、API メーリングリスト、公開フィードバックフォームが考慮されました。次に、Google はこれらのさまざまなアウトリーチ活動に関与するチーム間で調整を行い、各 API に関連して出現したテーマの相対的な発生率を判断しました。
フィードバックに対する Chrome の対応の説明は、公開されている FAQ、関係者によって提起されたイシューに対する実際の対応、およびこの公開報告の目的に特化した立場の決定に基づいて作成されました。開発とテストの現在の焦点を反映して、特に Topics、Fledge、および Attribution Reporting API に関する質問とフィードバックが寄せられました。
現在のレポート期間の終了後に受け取ったフィードバックには、考慮された Chrome の対応がまだ含まれていない可能性があります。
頭字語の用語集
- W3C
- PatCG
- IETF
- DSP
- デマンドサイド プラットフォーム
- SSP
- サプライサイド プラットフォーム
- OT
- UA
- UA-CH
- IP
- インターネット プロトコル アドレス
- WIPB
- IAB
- openRTB
- CHIPS
- FPS
- FedCM
- IDP
- ID プロバイダー
一般的なフィードバック、API/テクノロジーの指定なし
フィードバックのテーマ | 要約 | Chrome の返答 |
(Q2 にも報告) さまざまなタイプの関係者にとっての有用性 |
プライバシーサンドボックステクノロジーが大規模なデベロッパーに有利であり、ニッチ(小規模な)サイトが一般的な(大規模な)サイトよりも多くの貢献をしているという懸念。 |
第 3 四半期の更新: Google は CMA に対し、プライバシー サンドボックスの提案を、Google 自身のビジネスを自己優先することによって競争を歪めない方法で設計および実装し、規模に関係なくデジタル広告における競争およびサイト運営者と広告主への影響を考慮に入れることを約束しました。私たちは、私たちの仕事がこれらのコミットメントに準拠していることを確認するために、CMA と緊密に協力し続けています。 プライバシー サンドボックスのテストが進むにつれて、私たちが評価する重要な質問の 1 つは、新しいテクノロジーがさまざまな種類の関係者に対してどのように機能するかということです。この点で、フィードバックは非常に重要な役割を果たします。特に、技術設計をさらに改善するのに役立つ具体的で実用的なフィードバックが重要です。 私たちは CMA と協力して定量的テストへのアプローチを開発してきました。CMA が実験計画に関するメモを発行して、市場参加者により多くの情報を提供し、提案されたアプローチについてコメントする機会を提供することを支持しています。 |
(Q2にも報告) 資料請求 |
テスト、分析、および実装を管理する方法を詳述するリソースのリクエスト |
第 3 四半期の更新: 開発者が現在の資料を参考してくれたことに感謝しており、新しいテクノロジーががどのように機能するかを開発者が理解できるように、今後数週間または数か月にわたってより多くの資料を提供することに引き続き取り組んでいます。 また、ベストプラクティスとデモを共有するための公開デベロッパーオフィスアワーセッションや、ライブディスカッション/質疑応答を可能にするプロダクトリーダーやエンジニアリングリーダーとの Q&A セッションも開催しました。 |
クロスブラウザのサポート | プライバシー サンドボックス API を採用している他のブラウザベンダー。 | Apple、Mozilla、Microsoft などの他のブラウザベンダーは、プライバシーの原則とブラウザベースのアプローチが議論されている公開フォーラムに積極的に参加しています。私たちは、最近の W3C 年次 TPAC 会議や進行中の W3C PATCG フォーラムなど、収束の兆しが見られるフォーラムでの協力的な議論に励まされています。 |
プラットフォームの違い | 移行に必要なリソースを削減するために、ウェブと Android の機能セットを可能な限り調整するようリクエストします。 | 業界全体で混乱や分断が生じるのを避けるために、Chrome と Android でアプローチを調整するために懸命に取り組んでいます。私たちのアプローチの違いは主に、開発者がすでに考慮しているウェブとモバイルアプリ プラットフォーム間の必要な技術的な違いによるものです。 |
プライバシー サンドボックス API をテストするためのリソース | 現在の経済的な逆風を考慮すると、 プライバシーサンドボックス API をテストするのに十分なリソースを割り当てられることが困難 |
Google は、複雑さを軽減し、API の採用を支援するために、テスターが利用できるドキュメントとサポートを継続的に改善しています。これらの取り組みには、API 固有のメーリング リスト、公開オフィスアワー、developers.chrome.com での継続的な更新が含まれます。 |
サンドボックス API のオプトアウトのシグナル | 「ユーザーがサンドボックス API をオプトアウトしました」という、アドテックとウェブサイトが使用できるシグナルを提供するというリクエスト | 「サードパーティ Cookie をオフにする」などのユーザーの選択にウェブサイトが反応して、ユーザーに設定を変更するよう圧力をかけ、変更しない限りウェブサイトへのアクセスをブロックするなどの事例を過去に数多く見てきました。オプトアウトシグナルは、フィンガープリンティングの追加シグナルとして使用することも考えられます。現時点では、Google はオプトアウト シグナルを提供する予定はありません。 |
(Q2 にも報告) より明確なタイムライン |
より明確で詳細なリリース スケジュール |
第 3 四半期の更新: 以下の「フィードバックに応じた変更」セクションで説明されているように、Google は 7 月にプライバシー サンドボックスのタイムラインを更新し、予備テストとフィードバックを行う時間と、サードパーティ Cookie が廃止される前にプライバシーサンドボックス API が完全に公開されてからテストする時間を市場に追加提供しました。 |
(Q2 にも報告) サードパーティ Cookie の廃止スケジュール |
サードパーティ Cookie の廃止に向けたさらなる遅延を回避するためのリクエスト |
第 3 四半期の更新: 7 月、Chrome は、技術の複雑さとエコシステムに対するそれらの重要性を考慮し、責任を持って行動するという私たちのコミットメントを反映して、サードパーティの Cookie の廃止に関する最新のタイムラインを発表しました。規制当局や業界からのフィードバックは、この変更の前に考慮されており、すべての関係者との緊密な協力を続けています。 |
ファーストパーティ Cookie | ファーストパーティ Cookie の制限も提案されていますか?その場合、長期的な安定性、予測不可能な今後のブラウザの変更によるリスク、およびそれによるエンジニアリングの取り組みが無駄になるという懸念があります。 | ファーストパーティ Cookie の制限については考慮していません。プライバシー サンドボックスは、サードパーティの Cookie を廃止することに重点を置いています。 |
関連するコンテンツと広告の表示
Topics
フィードバックのテーマ | 要約 | Chrome の返答 |
(Q2 にも報告) さまざまなタイプの関係者にとっての有用性 |
トラフィックのレベルやコンテンツの専門性によっては、サイトにとっての有用性について懸念が提起されています。 |
第 3 四半期の更新: API の有用性は、テストを通じて調査されます。コミットメントの第 17.c.ii 項で義務付けられているように、Google はそのようなテストの結果を CMA と共有する意向です。Chrome では、テスト結果に基づいて分類法やその他のパラメータが進化することを期待しています。分類法またはパラメータの進化は、後方互換性のない変更を必要としない場合があります。さらに、サードパーティ Cookie の廃止後も、フィードバックが引き続き Topics API の進化に影響を与えることを Chrome は期待しています。 |
プライバシーポリシー | 呼び出し元ごとのトピック フィルタリング要件を削除するリクエスト | プライバシー KOF、プライバシー擁護者、セキュリティ専門家、デジタル著作権グループ、およびエコシステム内の他の人々からのフィードバックに基づいて、Chrome はこの設計を選択し、他の方法ではそのようなアクセス権を持っていた人だけに情報へのアクセス権を付与しました。この理由には、段階的なクロスサイドのデータ漏えいを制限する、透明性と説明可能性を確保する、実装と説明が簡単なアプローチを採用する、フィンガープリンティングのリスクを制限することが含まれますが、これに限定されません。トピックを受け取るサイト運営者およびサード パーティは、自分のサイトでどのような情報を共有するかを自分で決めることができます。サードパーティがこの情報を共有する場合、Chrome では、そのような共有についてユーザーに透明性を持たせ、コントロールを提供することを強くお勧めします。 |
誤って分類されたサイト | サイトが間違ったトピックに誤って分類され、広告のターゲティングが不正確になる可能性があります。 | サイトは、最も人気のあるサイトを含む、人間が精選したオーバーライド リストと、オンデバイス ML モデルを組み合わせて分類されます。Chrome では、トピックの分類に貢献するサイトのオプションを引き続き評価しています。ユーティリティの改善は、プライバシーと悪用のリスクと比較検討する必要があります。たとえば、次のようなリスクがあります。
chrome://topics-internals またはこの colab を介して利用可能なツールを使用して、一般にこれらのコンポーネントを調べることができます。テストを通じて、時間の経過とともに分類が改善されることを期待しており、誤って分類される可能性のあるサイトの例に関するフィードバックを歓迎しています。 |
アクセス要件 | アクセスするためのスクリプトまたは iframe としてのページ上の DOM エンティティに対する現在のトピック要件は、広告エコシステム内のプレーヤーによる望ましくない行動につながる可能性があります。 | Github Explainer の変更をマージしました。 HTTP ヘッダーで Topics をサポートする予定です。 |
トピックの分類が十分に細分化されていない | 現在のトピックの分類は広すぎるため、地域のトピックなど、より詳細なトピックは含まれていません。 | 分類法の改善は継続的な取り組みであり、エコシステムのテストと入力によって分類法が進化することを期待しています。 私たちは、エコシステムにとって最も役立つ分類法に関するフィードバックを積極的に求めています。トピックの数を増やすか、より詳細なトピックを含めるかを評価する際には、1)潜在的なプライバシーへの影響(たとえば、トピックが増えるとフィンガープリンティングのリスクが発生する可能性があります)、および 2)以前に観察されたトピックを取得する機能(たとえば、トピックがさらに増えると、アドテックが過去に選択したトピックを見た可能性が低くなる可能性があります)。2) をさらに展開して、Google は、ユーティリティとプライバシーの両方を達成することを目標に、既存のフィルタリング要件の範囲内で、以前に観察されたトピックを取得する呼び出し元の能力を最大化しようとしています。 |
トピックの制限 | ウェブサイトごとに 3 つのトピックでは、広告主が広告を配信するには情報が少なすぎます。 | API は、エコシステムからのフィードバック、特にオリジン トライアルのテスト結果の影響を受けながら、引き続き進化しています。Topics は、コンテキストなどの他のシグナルを補完して、訪問者に適した広告を見つけるのに役立つことが期待されていることに注意してください。そのため、トピック以外にも広告主が利用できる情報が増える可能性があります。 |
(Q2 にも報告) ユーザーコントロールと安全性 |
特定のトピックは機密性の高いグループのプロキシである可能性があり、ユーザーは否定的な結果を防ぐためにより多くの制御を必要とします。 |
第 3 四半期の更新: Topics のユーザーコントロールと透明性は、大きく前進しています。ユーザーは、トピックのオプトアウト、割り当てられたトピックの確認、トピックの削除、特定のページでトピックとやり取りしている企業の把握が可能です。さらに、ユーザーは、トピックの派生元であるブラウジング履歴を削除して Topics をクリアすることもできます。これらのコントロールは現在、デバイス レベルで Chrome ブラウザに実装されています。開発者によって提案されたものなど、より高度なユーザー コントロールに関する継続的な議論を歓迎します。ただし、発生した懸念に対処するために、新しい追加が適切に調整されており、断片的な変更が行われないようにする必要があります。 |
SEOへの影響 | サイト運営者が、Topics をより適切に反映するようにウェブサイトのホスト名を調整すると、SEO に悪影響を与える可能性があります。 | サイトが Topics のためだけにホスト名を変更しないように警告しています。このようにすれば、割り当てられたトピックに影響を与えてしまうのは事実ですが、そうすることによるサイト運営者へのメリットはよくわかっていません。また、サイトが分類モデルを「操作」しようとすると、エコシステム全体のトピックの価値が損なわれることになります。トピックの割り当ても固定されていません。分類法は、テストと入力によって進化し続けると予想されます。このテストに関連して、誤って分類されている可能性のあるサイトの例を含め、フィードバックをお寄せください。 |
不正と悪用 | 表示されるトピックが実際にブラウザによって生成されたものであることをバイヤーが確認できる方法を用意してほしい | プログラマティック広告オークションでセラーから渡されたトピックをアドテック バイヤーが検証するメカニズムをサポートするという提案に感謝します。エコシステムはこちらの活発なディスカッションに参加することをお勧めします。現在、優先度の高いその他の改善に注力していますが、これが将来の設計への重要な追加になる可能性があることを認識しています。 |
不正と悪用 | First-Party Sets と同じ種類の公開投稿とレビューを通じて、Topics データの正当なユーザーであるパーティのパブリック レビューを行えるようにする | 私たちはこの提案を高く評価し、公的説明責任がプライバシー サンドボックスの目標を達成するための重要なツールであることに賛同しています。Topics API 呼び出しは本質的にパブリックです。これは、誰でもサイトにアクセスして、JavaScript API に対するドメインの呼び出しを監視できるためです。したがって、個人や組織は、関連するアクティビティを表示し、どのサイトが Topics をどのように使用しているかを評価できます。これは、Topics API 自体の機能の一部としてサイトの「正当性」を評価するアプローチよりも優れていると考えています。 |
ファーストパーティシグナルへの影響 | Topics のシグナルは非常に価値がある場合があり、その結果、他のファースト パーティのインタレスト ベース シグナルの価値が低下してしまいます。 | インタレストベースの広告はウェブにとって重要なユースケースであると考えており、トピックはそのユースケースをサポートするように設計されています。前に説明したように、他のエコシステム関係者は、Topics は価値を提供するには十分に有用ではない可能性があるという懸念を表明しています。いずれの場合も、分類法の改善は継続的な取り組みであり、エコシステムのテストとインプットによって分類法が進化することを期待しています。 |
FLEDGE
フィードバックのテーマ | 要約 | Chrome の返答 |
FLEDGE オークション | SSP は、FLEDGE オークションに入札するために Google 広告に送信されるデータをどのようにフォーマットできるのか。 | テストに参加している企業は、それぞれのテスト計画に関するドキュメントを公開し、必要に応じて協力することをお勧めします。 私たちは CMA と協力して定量的テストへのアプローチを開発してきました。CMA が実験設計に関するメモを発行して、トライアルに参加することを計画している市場参加者により多くの情報を提供し、提案されたアプローチについてコメントする機会を提供することを支持しています。 広告マネージャー チームは、広告マネージャーをアドサーバーとして使用するサイト運営者と FLEDGE をテストすることに関心のあるセラー向けのドキュメントをこちらに投稿しています。 追加の技術詳細は、こちらで説明されています。 |
ネストされた Fenced Frame の FLEDGE | Fenced Frames を使用すると、テストの制限を緩和できますが、不確定な未来により制限が加えられてしまいます。タイムラインが不明であることは、エコシステムにとって困難です。 | 企業は今すぐ Fenced Frames で FLEDGE をテストできます。より簡単なオンボーディング オプションを提供するために、企業はまず FLEDGE を実装することを選択できます。FLEDGE を実装した後、Fenced Frame を FLEDGE 設計でテストできます。 |
データ処理ポリシー | インタレストグループ / FLEDGE のデータ処理ポリシーとは? | FLEDGE 設計では、インタレストグループに保存されているすべてのデータ、またはどのインタレストグループにどのような人物がいるかについてのデータがデバイス上に残ります。このデータは Google サーバーに送信されません。 Chrome が FLEDGE に対して計画しているプライバシー保護には、Google が運営する k-匿名サーバーとのやり取りが含まれます。このインタラクションは、ユーザーに関する情報の共有を回避し、信頼できる実行環境(TEE)で実行して、広告エコシステム全体で情報の同等性を確保するように慎重に設計されています。 \ Google は CMA に対し、Google 自身のビジネスを自己優先することで競争を歪めない方法でプライバシー サンドボックスの提案を設計および実装し、デジタル広告の競争およびパブリッシャーと広告主への影響を考慮に入れることを約束しました。私たちは、私たちの仕事がこれらのコミットメントに準拠していることを確認するために、CMA と緊密に協力し続けています。 |
年齢に関するポリシー | Chrome では、FLEDGE によって作成されたオーディエンスが年齢制限に準拠していることをどのように確認していますか? | サイト運営者と広告主は、FLEDGE を使用して作成したオーディエンスが適用法に準拠しているかどうかを評価するのに最適な立場にあります。ユーザーをさらに保護するため、Chrome にサインインしているユーザーのアカウントに関連付けられている年齢が 18 歳未満の場合、テスト期間中であってもプライバシー サンドボックス API は有効になりません。(ログアウトしているユーザーの場合は、Chrome は、ブラウザがユーザーの年齢を推測できるようにするプロファイル シグナルを収集しません)。 |
FLEDGE Key/Value サービス | キーの数や更新頻度など、FLEDGE Key/Value サービスで許可される内容をより明確にしてほしい | FLEDGE を使用する企業は、RAM に収まる数のキーを持つことができます。詳細については、こちらの Explainer をご覧ください。 データを変更するためのより高速なパスを提供することを検討しており、あらゆる要件に対する提案を歓迎します。 |
テスト | Google 広告で FLEDGE をテストするのは難しい | オリジン トライアルに参加してテストする最適な方法については、Google 広告のオンボーディング ドキュメントを参照してください。 |
Bidding and Auction Services API | Bidding and Auction Services API に対する Google の方向性は?Chrome ブラウザの FLEDGE オンデバイスオークションよりも優先されますか? | 現在の FLEDGE オンデバイス入札設計に引き続き取り組んでいきます。入札とオークションサービスは、デバイスの計算能力またはネットワーク速度が制限される可能性があるユース ケースをサポートするために可能なソリューションを探索するために提案されています。 |
集計レポート | generateBid で利用可能なすべてのシグナルに基づく集計レポートのサポートをリクエストします。 | これについては、近日中に公開する予定です。 |
コンテキスト広告 | FLEDGE でのコンテキスト広告の配信 | このオプションを検討しましたが、このディスカッションで説明した理由により、現時点ではコンテキスト広告に FLEDGE を使用することはお勧めしません。 |
実世界でのテスト | 実際のテストのために、FLEDGE をサードパーティ Cookie から分離する方法についてのガイダンス。 | テスト集団を提供する方法を検討しています。 私たちは CMA と協力して定量的テストへのアプローチを開発してきました。また、CMA が実験計画に関するメモを発行して、市場参加者により多くの情報を提供し、提案されたアプローチについてコメントする機会を提供することを支持しています。 |
FLEDGE と Attribution Reporting API のテスト | FLEDGE で Attribution Reporting API を実装する最良の方法は何ですか?FLEDGE と Attribution を分離するか、一緒にテストすることをお勧めしますか? | 最終的には、FLEDGE と Attribution Reporting API の両方を統合ソリューションとしてテストすることをサポートしますが、開発者にはまず Attribution Reporting API を個別にテストし、統合が完了したら FLEDGE でテストすることをお勧めします。 |
入札価格の可視性 | 入札価格の難読化のリクエスト。 | 「generateBid()」または「scoreAd()」内にブレークポイントを設定すれば、DevTools から入札値にアクセスすることができます。Chrome チームは、FLEDGE に関するこのフィードバックで提起された狭い攻撃ベクトルを検討しました。ただし、Chrome のセキュリティ モデルとプライバシー モデルでは、ユーザーが自分のデバイス上の情報を使ってやりたいことを何でもできると信頼されていると見なされているため、要求に応じて入札データを非表示にする実現的な方法はありません。 |
ドキュメントのリクエスト | ライブ エコシステムでテストするためのドキュメントと例。 | 開発者が現在の資料を参考にしてくれたことに監視しており、開発者が新しいテクノロジーがどのように機能するかを引き続き理解できるように、今後数週間または数か月にわたってより多くの資料を提供することに取り組んでいます。 また、外部開発者向けの公開オフィス アワーを開催して、Q&A セッションをプロダクトリーダーやエンジニアリングリーダーとの Q&A セッションとともにベスト プラクティスとデモを共有し、ライブ ディスカッション/質疑応答を実施しました。 |
Private Aggregation API | Private Aggregation API に関する詳細をリクエスト | 現時点で共有できる最新情報については、公開 Explainer て提供されています。この API が開発され、ユース ケースが定義されるにつれて、より多くのドキュメントが提供される予定です。 |
データ遅延 | FLEDGE Key/Value サーバーのデータ取得はリアルタイムですか? | 公開されている GitHub の問題 で説明されているように、更新されたデータがサーバーによってクエリ用に返されるまでに、数時間ではなく数分の程度の少量の古い状態が予想される場合があります。開発者からのフィードバックもお待ちしています。 |
入札およびオークションサービス | 入札およびオークション(B&A)サービスを使用する場合、入札価格は他のユーザーに非表示になっていますか? | B&A サーバー側アプローチの場合、入札リクエストは SSP オークション サービスから DSP オークション サービスに直接行われるため、個々の入札価格はユーザーには表示されず、ブラウザでは使用できなくなります。 ただし、落札価格は引き続きブラウザに表示されます (入札価格を難読化する要求については、上記で詳しく説明しています)。 |
入札およびオークションサービス | 入札とオークション サービスの負荷をどのように分散できますか? | 現在、負荷分散に関するガイダンスはありませんが、パフォーマンスとプライバシーの両方の観点から重要な懸念事項です。詳細については、今後お知らせいたします。 |
FLEDGE 制限 | joinAdInterestGroup の期間上限を 30 日から 90 日に増やすリクエスト | 30 日間のデータ保持期間は、アトリビューション レポートの 30 日間の制限やトピックの 3 週間の振り返りなど、他のプライバシー サンドボックス広告 API と一致していると感じています。この時間枠は、アドテックのニーズとユーザーのプライバシーへの期待の両方に対応しています。 ただし、この問題については引き続きこちらで議論するため、さらなるフィードバックをお待ちしております。 |
FLEDGE の共有ストレージ | FLEDGE で Shared Storage API を利用することはできますか? | 今後、FLEDGE で Shared Storage API をサポートする予定であり、今後のオリジントライアルでこれを利用できるように取り組んでいます。 |
クリック数によるフリークエンシー制御 | FLEDGE でクリック数(獲得数ではない)でフリークエンシー キャップを設定することはできますか? | FLEDGE は、Fenced Frame が navigator.leaveAdInterestGroup() (パラメーターなし) を呼び出して、広告が表示される原因となったインタレスト グループから脱退できることを指定します。この呼び出しは、クリックが最初に受信されたときに行われ、フリークエンシー キャップの形態として、今後の入札を防ぐことができます。現在、このソリューションは、複数回クリックした後のキャッピングには機能しません。 |
ネストされた Fenced Frame の FLEDGE | ネストされた Fenced Frame でクリックが発生した場合、Fenced Frame Ads Reporting を介してクリックをレポートできません。 | このイシューを解決するための提案をこちらに公開しました。 |
測定 | FLEDGE オークションで入札者のレイテンシ データを収集する方法についてのガイダンスが必要です。 | パフォーマンス測定ドキュメントを近日中に公開する予定です。 |
レポーティング | FLEDGE のレポートはどのように処理されますか? | 落札、オークション結果、イベント(クリックなど)に関する FLEDGE レポートは、reportResult() などの FLEDGE API を介して利用できます。広告コンバージョンのレポートでは、Attribution Reporting API との統合は FLEDGE から独立していますが、可能なアプローチについてエコシステムとの継続的な議論があります。 Private Aggregation API を使用して、分離された実行環境内からオークション結果を報告することもできます。 こちらの Explainer をご覧ください。 |
インタレストグループのサイズ | アドテックがインタレスト グループのサイズ(グループ内のユーザー数)を確認する方法はありますか? | インタレスト グループのメンバーシップは、ブラウザによってユーザーのデバイスに保存され、ブラウザ ベンダーや他の誰とも共有されません。 ただし、インタレストグループの所有者は、理論的には navigator.joininterestgroup(...) へのすべての呼び出しをトラッキングできます。この呼び出しをトラッキングしても、IG の正確なサイズは保証されませんが(ユーザーはいつでもグループを脱退できるため)、上限とサイズの概算を所有者に提供します。 |
パフォーマンス | Bidding JS/WebAssembly コードはオークションごとにコンパイルされますか? | Bidding JS/WebAssembly コードは、オークションごとに 1 回コンパイルされます。 |
パフォーマンス | biddingDurationMsec の範囲は何ですか? | biddingDurationMsec には、スクリプトのコンパイル時間が含まれます。ダウンロード時間、wasm コンパイル時間、ネットワーク時間は含まれません。JS コンパイルの前に Key/Value サーバーなどから時間をフェッチします。 |
カスタマイズ | ユーザー向けにカスタマイズされるように adComponent を更新することは可能ですか? | 呼び出し元が joinInterestGroup を呼び出したとき、または Chrome が DailyUpdateURL を呼び出したときにインタレスト グループが更新されると、adComponent が更新されます。これにより、呼び出し元は、現在のサイトからのユーザーの知識に基づいて、または k-匿名情報に基づいて、それぞれ adComponent を更新できます。製品レベルの turtledove の元の提案はこちらにあります。これには、推奨ユース ケースのコア メトリクスへの影響に関する RTB House による分析が含まれています。 |
インタレストグループ | インタレストグループの所有者が条件付きで特定のユーザーを削除することはできますか? | インタレスト グループのメンバーシップはユーザーのブラウザにのみ保存され、ユーザー側でのみ削除できます(サイト データを消去するなど)。 ただし、ユーザーがインタレストグループの所有者の管理下にあるページに戻った場合、インタレストグループの所有者は (いくつかの条件付きロジックを使用して)navigator.leaveAdInterestGroup() を呼び出すことができます。 |
パフォーマンス | generateBid のパフォーマンスを測定するにはどうすればよいですか? | コンパイル時間と実行時間は、biddingDurationMsec で測定できます。ダウンロード時間は、chrome://net-export で測定できます。最近のバージョンの Chrome では、コンパイル時間と実行時間が DevTools の [パフォーマンス] タブに表示されます。 |
インタレストグループの更新頻度 | ブラウザからインタレスト グループが更新される頻度はどれくらいですか? | 過去 24 時間更新されていないインタレストグループについては、navigator.updateAdInterestGroups() が呼び出されたとき、またはオークションに参加する機会があったときに、Chrome が更新を試みます。詳細については、こちらの Explainer をご覧ください。 |
アグリゲーション サービス プロバイダー | アグリゲーションサービスで他のクラウド プロバイダーがサポートされるのはいつですか? | 現在、特定の時間に関する更新はありませんが、更新され次第、さらに共有します。現在、アグリゲーションサービスのセキュリティ要件を満たしているのは AWS だけです。 |
FLEDGE テストのタイムライン | FLEDGE は BYOS でどのくらいの期間テストされますか?BYOS モデルから TEE ベースのモデルに切り替えるのに十分な時間はありますか? | エコシステムがテストするのに十分な時間を確保するために、サードパーティ Cookie が廃止されるまで、TEE の使用を要求することはないと考えています。この移行が行われる前に、開発者がテストと採用を開始するように十分な通知を行います。現在、これ以上の更新はありませんが、更新が行われたらさらに共有します。最新情報はこちらでご確認ください。 |
データサイズ制限 | wasm の入札機能のデータサイズ制限は? | こちらで説明されているように、インタレスト グループの更新によってインタレスト グループが 50kb を超えることはできないという要件がありますが、wasm のデータ サイズ制限はまだ定義されていないため、このトピックに関する情報をお待ちしております。 |
オークションシグナル | オークションシグナルの標準化されたデータ構造はありますか? | これはまだ定義されていませんが、フィードバックを受け付けています。 |
アドテックサーバーのクエリ | K/V サーバーからアドテック サーバー データをリアルタイムでクエリすることは可能ですか? | いいえ、K/V サーバーは、ユーザー データの漏えいを避けるために「ネットワーク、ディスク アクセス、タイマー、またはログ記録なし」を強制する信頼モデルで実行されます。詳細については、こちらの信頼モデルの説明をご覧ください。 |
adComponents の更新頻度 | ユーザーの閲覧履歴による adComponents フィールド(現在は IG 設定のみ)の更新は現在不可能です。 | プライバシー サンドボックスは、クロスサイト トラッキングなしでウェブエコシステムのニーズをサポートすることを目的としています。つまり、ブラウジング履歴へのアクセスを防止します。Topics などの代替手段を使用することをお勧めします。 |
オークション結果 | アドテックがオークションの落札率を知る方法はありますか? | オークションの結果は、セラーと落札したバイヤーがそれぞれ提供するオークション コードで reportResult() 関数と reportWin() 関数を呼び出すことによって報告されるため、それぞれにオークション結果に関するログとレポートを実行する機会があります。 |
(Q2 にも報告) ネガティブ インタレスト グループ ターゲティングのサポート |
ユーザーがインタレスト グループに属していない場合にのみ広告を表示するネガティブ インタレスト グループ ターゲティングをサポートする API |
第 3 四半期の更新: 新しい提案を共有し、フィードバックを求めています。 |
デジタル広告の測定
Attribution Reporting(およびその他の API)
フィードバックのテーマ | 要約 | Chrome の返答 |
OT 要件 | OT のみの間または OT に対してのみ、アクセス許可ポリシーの制限を削除します。 | テスト中に発表されたアクセス許可ポリシーの変更を参照してください。この変更によって対処される根本的な関係者の懸念は、DSP がより多くのクロスオリジン iframe で API をテストできるようにすることです。当初、DSP はサイト運営者/SSP と調整して、クロスオリジン iframe で API をテストするために適切なアクセス許可ポリシーが設定されていることを確認する必要がありましたが、この変更により、DSP はデフォルトで API を呼び出すことができ、SSP/サイト運営者はオリジントライアル中に必要に応じて API を無効にします。 |
ノイズ | ノイズのレベルが高すぎて、レポートの有用性に影響を与えているというフィードバック。 | ノイズに関するフィードバックを歓迎します。これを使用して、特定のノイズ関連パラメータを設定する方法を決定します。また、テスターがこれを行うのに役立つリソース、ツール、その他のドキュメントをさらに公開する予定です。 |
クロスドメイン コンバージョン | 2 つ以上のリンク先など、クロスドメインのコンバージョンを追跡するにはどうすればよいですか? | この質問については、現在議論中であり、フィードバックを求めています。 |
デバッグ要件 | 要約レポートの展開/テスト時に、開発者が残りのプライバシー予算を確認できるようにするリクエスト | この機能のリクエストはこちらで追跡できます。 |
API 使用ポリシー | フィンガープリンティングなどの制限に基づいて、特定の API を使用できるユーザーに関するポリシーを提案するフィードバック | これは非常に興味深いアイデアであり、他のブラウザプロバイダーとより広範なウェブエコシステムの両方とさらに協力したいと考えています。 |
コンバージョン レポートの有効期限設定 | 24 時間未満のレポート フィルター/有効期限のサポートをリクエストします。 | 時間レベルの有効期限は、ユーザーが広告主のサイトにアクセスした時間を正確に知ることができるため、プライバシー上の懸念の原因となります。日レベルの有効期限により、アドテックは、ユーザーがサイトにアクセスした時間を特定せずに、無効なインプレッションを除外できます。 |
OT トークンの有効期限 | 運用上のオーバーヘッドを削減するために、既存の OT トークンの有効期間を延長することをリクエストします。 | トークンを更新する必要があることは認識しており、開発者が簡単に更新できるように取り組んでいます。追加の通知を提供する予定です。 |
リージョンサポート | 現在、アグリゲーションサービスはすべてのリージョンをサポートしているわけではありません。 | これはベータ版の現在の制限です。テストの進行に伴い、追加のリージョンをサポートする予定ですが、明確なタイムラインはまだありません。 |
イベントレベルレポートの遅延 | イベント レベル レポートの 2 ~ 30 日の遅延は、特定のユース ケースでは長すぎる場合があります。 | イベント レベルのレポートが有効期限を介して送信されるタイミングをアドテックが制御できるようにするための提案をこちらに共有しました。デフォルトは 30 日ですが、これより短く設定することもできます。 |
(Q2 にも報告) マルチタッチ アトリビューション |
クロスデバイスやクロスアプリなどのマルチタッチ アトリビューションの許可 |
第 3 四半期の更新: マルチタッチ アトリビューションの現在の方法では、さまざまなウェブサイトでのユーザーのインプレッション(したがってID)を決定論的に結び付ける必要があります。その結果、現在の形でのこの機能は、クロスサイト トラッキングなしで主要な広告のユースケースをサポートすることを目的としたプライバシーサンドボックスの目標と一致しません。 |
FLEDGE とアトリビューション レポートの統合スケジュール | FLEDGE とアトリビューション レポート API の統合のタイムラインは? | 現在、共有できる更新はありませんが、特定のタイムラインにコミットできるようになったら、さらに情報を公開します。 |
複数のトリガー タイプ | トリガー登録の柔軟性を高めるように要求します。 | アドテックがイベント レベルの集計可能なレポートをより柔軟に制御できるようにするアグリゲート API の重複排除システムを提案しました。 |
測定 | 広告枠がうまく機能しているかどうかの測定データを受信するリクエスト | フィードバックに感謝し、このリクエストのユースケースをさらに明確にするよう努めています。 |
コンバージョンの有効期限 | ソースタグだけでなく、トリガータグでコンバージョンの有効期限をサポートするようリクエストします。 | フィードバックに感謝し、このリクエストのユースケースをさらに明確にするよう努めています。 |
バッチ レポート | バッチ レポートでの追加測定の要求。 | アグリゲーション サービスへの影響について引き続き検討しておりますので、フィードバックをお待ちしております。バッチ レポートとその予想される頻度についてアドテクがどのように考えているか、バッチ戦略が年間を通じてどのように変化するかについてのフィードバックをお待ちしております。 |
イプシロン | イプシロンの値はいつ決定されますか? | イプシロンの値とそれを GA に実装する方法を最終決定するために、エコシステムのテスターと積極的に協力しています。この値は、値の決定につながった議論とともに公開されます。フィードバックがある場合は、この GH イシューに投稿してください。 |
隠されたトラッキングの制限
User-Agent の情報量削減
フィードバックのテーマ | 要約 | Chrome の返答 |
デプロイの依存関係 | 構造化ユーザー エージェント(SUA)デプロイの依存関係への対応 | バージョン 101 以降の Chrome ユーザーの 100% に対してマイナーバージョン削減とも呼ばれる「フェーズ 4」をロールアウトしました。こちらで更新をご覧ください。 |
テスト | メタからの User-Agent Reduction オリジントライアルの延長をリクエストします。 | オリジントライアルを延長し、より大規模なサイトに対応するためにトラフィック制限を削除する許可を取得しました。トラフィック制限の緩和は、大小を問わずすべてのサイトに適用されます。 |
User-Agent Client Hints
フィードバックのテーマ | 要約 | Chrome の返答 |
(Q2 にも報告) 不正防止/悪用防止に関する懸念 |
UA-CH によって失われる可能性がある特定の機能: クリック リダイレクト トラッカー、および不正なクリック。 |
第 3 四半期の更新: 企業から、不正防止パイプラインに悪影響が見られなかったという肯定的なフィードバックを受け取りました(結果はこちらとこちら)。 チームは、不正防止および測定の関係者とともに、これらの潜在的なイシューを調査し続けています。 |
アクセス許可ポリシー | アクセス許可ポリシーはキャッシュされますか? | この Github イシューで説明されているように、アクセス許可ポリシーはキャッシュされません。 |
Gnatcatcher(作業中)
フィードバックのテーマ | 要約 | Chrome の返答 |
ジオロケーションのユースケース | Gnatcatcher は、ジオロケーションに基づくコンテンツのパーソナル化など、正当なジオロケーションのユースケースを今後機能させなくなる可能性があります。 | Google は関係者と協力して、Chrome が引き続き IP アドレスの正当なユースケースをサポートできるようにしています。 |
サイト間プライバシー境界の強化
First-Party Sets
フィードバックのテーマ | 要約 | Chrome の返答 |
ポリシー | FPS が 3 つの制限を想定しているのに対し、GDPR はセット内のサイト数に制限を課していないことに基づいて、FPS が「適用可能なデータ保護法」に関する CMA コミットメントの規定と一致していないという懸念。 | Google は、Google 自身のビジネスを自己優先することによって競争を歪めない方法でプライバシー サンドボックスの提案を設計および実装し、デジタル広告、サイト運営者、および広告主における競争への影響、および適用されるデータ保護法に定められていプライバシーの結果およびデータ保護原則の遵守への影響を考慮に入れることを CMA に約束しました。表明された懸念は、GDPRとの非互換性を開示するものではありません。Googleは、この仕事がこれらのコミットメントに準拠していることを確認するために、CMAと緊密に協力し続けます。 |
ドキュメント | 例の追加と既存の Explainer の更新 | Explainer の例はレビュー中であり、必要に応じて明確にするか削除します。 |
環境設定の共有 | 同じパーティ セット全体で環境設定を設定する提案。 | フィードバックを求めており、こちらでそのアイデアについて積極的に議論しています。 |
実施 | 透過的な実施プロセスには、バッドアクターによる悪用のリスクがあります。 | フィードバックに感謝します。GitHub およびその他のフォーラムで関係者と積極的に対話して、このリスクを評価し、潜在的な軽減策を特定しています(このイシューで提起された点を考慮し、このイシューで提起された提案を組み込むことを検討しています)。 |
共通オーナーシップ | 共通オーナーシップの機械可読宣言の提案。 | この提案に対するご意見をお待ちしています。 |
サブドメインの所有権 | 異なるデータ管理者、異なるプライバシー ポリシー、または異なるエンティティによって運営されている異なるサブドメインは、同じ First-Party Sets の一部である必要がありますか? | フィードバックに基づいて、一般的な eTLD ユース ケースを削除する予定です。 |
悪用の緩和 | 悪用緩和対策の詳細についてのリクエスト | プロセスの管理は検討中であり、詳細は今後数か月以内に共有されます。 |
潜在的な攻撃ベクトル | 簡単に見つけられるページの欺瞞的な関連セットを使用して、独立を偽って表示する他のページに誘導できる可能性がある | 積極的に一般からの意見を集め、このイシューに対処する方法を調査しています。 |
セットの検証 | 同意済みの共通ポリシーによるセットの検証。 | ウェブ標準コミュニティやより広範なエコシステムのさまざまなメンバーから、これは実現不可能であると指摘されています。 |
ドメイン制限 | 関連付けるドメイン数の拡大のリクエスト。 | FPS でのドメイン制限について積極的に議論しており、ユース ケースに必要な関連ドメインの数について、コミュニティからのフィードバックをお待ちしております。 |
サブセット サービスの操作 | サービスと関連するサブセットの操作に関する懸念。 | フィードバックに感謝し、将来の仕様でこれをより明確にすることを検討します。 |
(Q2 にも報告) プライバシーの向上 |
同じセット内のサイトが多すぎると、サードパーティ Cookie と同様の結果になる可能性があります |
第 3 四半期の更新: 最新の提案では、「関連付けられた」サブセットに対して 3 つのドメインの制限が提案されています(ccTLD とサービス ドメインは含まれません)。Chrome はエコシステムと積極的に連携して、この制限が適切かどうかを判断しています。 |
(Q2 にも報告) 一般的なプライバシー ポリシー要件 |
すべての製品、および同じセットの一部である必要がある法域にわたって共通のプライバシー ポリシーを維持することは実行不可能です。 |
第 3 四半期の更新: 共通のプライバシー ポリシーは、同じセットの一部である必要はなくなりました。 |
Fenced Frames API
フィードバックのテーマ | 要約 | Chrome の返答 |
なぜ iframe の属性ではなく新しい要素なのですか? | 既存の iFrame の提案ではなく、Frenced Frame の提案に関する質問です。 | フィードバックを歓迎しています。こちらで議論されているように、現状を収束させる方法についてのアイデアをお待ちしています。 |
Fenced Frames 内の交差オブザーバー | Fenced Frame 内の情報の視認性に関する質問。 | これについては活発な議論が行われており、このドキュメントと GitHub ではコメント期間にあります。サポート方法をよりよく理解するために、パートナーからのユースケースの共有をお待ちしています。 |
動画とネイティブ広告枠のサポート | Fenced Frames は動画とネイティブ広告枠をサポートしていますか? | 動画再生機能に関しては、Fenced Frame は iframe と変わらないため、どの公開ドキュメントでも明示的には言及されていません。動画広告に問題が見られる場合は、さらに調査するためにフィードバックを送信してください。 |
ウェブバンドル | Fenced Frame x FLEDGE では、ウェブバンドルによる広告配信/レンダリングは将来必須になりますか? | 長期的には、Fenced Frames で広告コンテンツをレンダリングするためのウェブバンドルをサポートすることを目標としていますが、FLEDGE の現在の実装はこれをサポートしていないため、renderUrl から取得した HTML リソースをレンダリングする必要があります。 |
アセットの寸法 | 適切なサイズのクリエイティブで応答できるように、render_url がスロットの高さと幅のマクロをサポートすることを要求 | これについては、こちらで活発に議論されています。 |
Shared Storage API
フィードバックのテーマ | 要約 | Chrome の返答 |
FLEDGE 統合 | 共有ストレージと FLEDGE はどのように統合されますか? | 現在はこれを追求していませんが、プライバシー保護を確実に維持できるのであれば、このアイデアを検討したいと考えています。関係者には、この提案が共有ストレージの github リポジトリまたは FLEDGE の github リポジトリに、サポートできる可能性のあるユース ケースの提案を提出することをお勧めしています。 |
データ保持 | 共有ストレージをクリアすると、有用性が減少します。保持期間の延長または個々のキー/値を削除する機能は、代替手段として検討されていますか? | ユーザーのプライバシーと有用性のトレードオフのバランスを常に考えています。調整に関するフィードバックをお待ちしております。パートナーが共有ストレージをテストする際に、より多くのフィードバックと詳細を提供することをお勧めします。 |
否定的なシグナル | 共有ストレージの提案に関する Mozilla からの否定的なシグナル。 | この提案を慎重に検討してくれた Mozilla に感謝します。近いうちにフィードバックに対応する予定です。 |
CHIPS
フィードバックのテーマ | 要約 | Chrome の返答 |
Partitioned の要件 | ファーストパーティ Cookie の「Partitioned」属性に明示的な動作要件の追加 | これについては、PrivacyCG コールで議論し、 GitHub イシューをメモとともにフォローアップしました。ブラウザ、開発者、プライバシー コミュニティと協力して、動作を調整し、それを指定する作業を続けています。 |
認証済みの埋め込み | 様々なパーティション化によって認証済みの埋め込みに影響があるため、CHIPS は 現在の SSO サインインフローに影響を与える可能性があります。 | 認証済みの埋め込みのユースケースを認識しており、解決策を模索しています。 |
Cookie のパーティション制限 | 現在の 10 個の Cookie 制限では、特定のユース ケースに対応できない可能性があるという懸念 | Cookie 数の制限から 12kb のメモリ制限に移行しています。そうすることで、Cookie の制限に関する懸念に対処しながら、パフォーマンスとブラウザのメモリ フットプリントに悪影響が及ばないようにすることができます。 |
オリジントライアルのタイムライン | ホスト名の境界要件の削除に従って、OT を延長してほしい | エコシステムからのフィードバックを受けて、オリジン トライアルの期限を延長しました。 |
Chrome でのテストの制限 | Chrome の現在の制限により、Firefox で CHIPS をテストできる可能性 | Firefox の実装はほぼ異なります。Chrome は Cookie の制限が低く、CHIPS はオプトイン メカニズムですが、Firefox はデフォルトでパーティション化されています。 |
(Q2 にも報告) 認証済みの埋め込み |
サインオン状態は CHIPS で保持されますか? |
第 3 四半期の更新: サインイン状態は現在保持されていませんが、CHIPS の意図したユースケースではありません。認証された埋め込みのユースケースを認識しており、解決策を模索しています。 |
FedCM
フィードバックのテーマ | 要約 | Chrome の返答 |
(Q2 にも報告) 潜在的な攻撃ベクトル |
リンクデコレーションとタイミング攻撃による潜在的な攻撃ベクトル。 |
第 3 四半期の更新: Mozilla と協力して、タイミング攻撃の問題に対処する方法について共通の理解に達しました。詳細はこちらをご覧ください。現在、このアーキテクチャ変更のプロトタイプを作成しており、今後数四半期で実験を行う予定です。 |
ID プロバイダー | アカウント チューザー: 単一の ID プロバイダー。複数の ID プロバイダーを許可するように要求します。 | 複数の ID プロバイダーを許可する方法について、ブラウザベンダーおよび FedID CG と協力し、試してみる価値のある定式化に到達しました。提案の説明はこちらにあります。今後数四半期でプロトタイプを開発し、実験を行う予定です。 |
連携に関する既知の問題 | 連携がサード パーティ Cookie の廃止によって問題に遭遇する可能性があるケースを挙げてください | FedID CG には、連携がこことここで壊れるケースを列挙した作業項目があります。また、破損をウェブプラットフォーム API にマップするための意思決定マトリックスもこちらに用意しています。 |
通知パラメーター | Nounce パラメーターはサインイン フローに影響しますか? | これはクロスサイト トラッキングと見なされる可能性がありますが、現在も情報を収集し、そのようなケースを処理する方法を分析しています。 |
ユーザーの同意 | オリジンごとに異なる証明書利用者(RP)とユーザーの同意のリンク | この仕様では、同じドメイン内のオリジンが Cookie を共有する方法を制御できません。この仕様では、IDP オリジンから RP オリジンへの idtoken を許可していますが、ユーザーのサインイン状態を、その単一のオリジンにロックされた Cookie に保存するか、同じドメイン内で同じオリジンと共有される Cookie に保存するかは、RP が選択します。 |
IDP アカウント 移植性 |
2 つの IDP 間で転送するときに選択した場合、IDP を移行するユーザー オプション。 | これは、ユーザーが FedCM API 経由ではなく、選択した新しい IDP のサインアップ ページで直接行う必要があるように思えます。 |
アカウントの削除 | IDP のアカウント削除による IDP 取り消し | この機能リクエストは意見を受け付けており、調査中です。 |
UI に関するクレーム | ブラウザ固有のインターフェイスの側面に関するクレーム。 | これに対処するには、プルリクエストを参照してください。 |
IDP リファーラルチェック | IDP が RP のリファラーをチェックする。 | 必須の IDP リファラー チェックを仕様に追加しました。プルリクエストを参照してください。 |
サインインのフロー | RP 設定に基づいてカスタマイズされるサインインフローに関するリクエスト | このアイデアを歓迎しており、積極的に議論しています。 |
スパムや詐欺への対抗
Trust Tokens API
フィードバックのテーマ | 要約 | Chrome の返答 |
不正と悪用 | ボットが発行者を騙してトークンを与えていないこと、ボットが実際のユーザーに発行されたトークンを乗っ取っていないこと、およびボットが悪意のあるトークンを発行するのを防ぐためのツールは? | ボットは発行者からトークンを取得できる可能性がありますが、発行者は、トークンを発行する頻度に制限を設け、トークンを発行し、悪意のあるアクターがトークンを回避しようとするときに発行ロジックを更新するための堅牢な方法を用意することが推奨されます。ウェブサイトはより堅牢な発行者に依存することを優先するため、トークンを発行するのに十分に堅牢なロジックがない発行者のエコシステムでの信頼は、低くなる可能性があります。 |
不正と悪用 | トラスト トークンの引き換え者が、特定のエンティティからのトラスト トークンのみを受け入れるように指定できる方法はありますか? | はい、あります。Explainer のトラストトークンの引き換えセクションでは、これがどのように機能するかについて説明しています。 |
不正と悪用 | トラスト トークンの発行者が引き換え者のリストを定義して、他の人がトークンを引き換えられないようにする方法はありますか? | 現時点ではありませんが、チームはこのユース ケースを調査しています。 |
タイムライン | Trust Token API はいつ一般提供されますか? | タイムラインにコミットできるようになり次第、さらに情報を公開します。 |
(Q2 にも報告) メンテナンスのオーバーヘッド |
プロトコルバージョンがサポートされる期間が明確ではありません。 |
第 3 四半期の更新: バージョン間の移行に猶予が与えられるように、複数の同時バージョンをサポートするための API の追加サポートが追加されているところですが、サポート/非推奨の時期はまだ検討中です。 |