フィードバック 開発者のみなさんがプライバシーサンドボックスの提案に対してフィードバックを送る場所と方法をご紹介します。 プライバシー サンドボックスでは、ウェブ エコシステム全体の多様な関係者からフィードバックを得ることが必要不可欠です。ここでは、開発の情報を提供するさまざまな公開チャネルについて説明し、個人または組織が開発の各段階でフィードバックを提供するための方法をご案内します。こうしたフィードバックには、Chrome のプロダクト マネージャーとエンジニアが積極的に対処します。すでに数百名の業界代表者からご協力をいただいています。
さまざまなフィードバック チャネルをご利用になれます。個々のやり取りは多くの場合一般公開されるので、ディスカッションの進行を追いかけ、どこで開発に貢献するかを決めることができます。フィードバック フォーム もご利用いただけます。フォームを使用すると、関係者は公開フォーラムの外で Chrome チームと直接フィードバックを共有する機会を得られます。フィードバック フォーム経由で届いたフィードバックは、属性情報なしで Chrome チームの公開レポートに含まれるものとして集計される場合があります。
フィードバックが検討されたことを確認するにはどうすればよいでしょうか。
個々の Privacy Sandbox API に関する最新情報は、定期的にこのサイトで公開されています。特に、この最新情報では、API 固有の一般的なフィードバック テーマの概要を紹介します。
基本的に公開のフィードバック チャネルを推奨しますが、公開チャネル(GitHub など)とダイレクト チャネル(フィードバック フォームなど)の両方が利用可能です。Chrome チームは、関係者から得られたフィードバックと関心が各 API の設計と開発に反映されるかどうか、またどのように反映されるかを説明します。
フィードバックのルート
個々の提案に共同で取り組むプライバシー サンドボックスに関する提案はすべて公開されてディスカッションの対象となります。提案の作成者とウェブの関係者は、協力して未解決の質問に回答し、機能が確定される前に実装の詳細を明確化します。
個々の提案に共同で取り組む
プライバシー サンドボックスに関する提案はすべて公開されてディスカッションの対象となります。提案の作成者とウェブの関係者は、協力して未解決の質問に回答し、機能が確定される前に実装の詳細を明確化します。
提案は Explainer から始まります。Explainer とは、提案する仕様の機能の大まかな技術概要です。未解決の質問と明確化が必要な詳細情報は常に存在するので、Explainer が投稿されてフィードバック プロセスが開始されます。この共同作業プロセスは、提案のライフサイクルを通じて進行します。これは、アイデアの初期のディスカッションで始まり、正式な仕様の改訂の反復で終わります。
このような大まかな概要と未解決の質問のパターンについては、Topics API の Explainer をご覧ください。
Explainer と補足コンテンツは GitHub でホストされます。GitHub では、GitHub アカウントを持っている方はどなたでも、リポジトリ(repo)で問題を報告(質問を投稿またはコメントを追加)して、ディスカッションを開始するかディスカッションに参加することができます。提案の作成者(Chrome プロダクト マネージャーとエンジニアを含む)は積極的にディスカッションに参加します。GitHub には、新しいアクティビティのアラートを受け取るオプションがあります。GitHub のフィードバックについては、特定の提案に関心を持つコミュニティと直接交流できます。GitHub アカウントを持っていなくても、個々の提案に関するコミュニティのコメントをすべて閲覧できます。
リポジトリにおけるディスカッションでは、提案の中で解決すべきものとされているユースケースになぜ対処するのか、またどのように対処するかに焦点を絞る必要があります。個々の提案に関する問題を閲覧および報告するためのリンクは、提案セクションの表のフィードバックの列にあります。
Chromium 機能の開発を追跡して対応する機能開発の各段階はすべて公開メーリング リストで発表されます。これにより、技術実装に関するディスカッションがさらに促進されます。
Chromium 機能の開発を追跡して対応する
機能開発の各段階はすべて公開メーリング リストで発表されます。これにより、技術実装に関するディスカッションがさらに促進されます。
各提案の結果として、Chromium に 1 つ以上の機能が組み込まれる可能性があります。提案したデベロッパーは、一般公開されている blink-dev
メーリング リストで、機能開発の各段階を開始するリクエストを送信します。各段階には、Intent to Prototype(I2P)、Intent to Experiment(I2E)、Intent to Ship(I2S)、Intent to Remove(I2R)があります。
- Intent to Prototype(I2P): デベロッパーは、Chromium の最初の実装を開始したいと考えています。これにより、デベロッパー テストで初期の機能をテストできる機会が増えます。ほとんどの場合、この段階での目的は提案されたアイデアを開発中のコードで検証することなので、この段階で役立つフィードバックは GitHub に投稿することが適切です。
- Intent to Experiment(I2E): デベロッパーは、広範囲を対象としてテストをオリジン トライアルの形で実施したいと考えています。これにより、デベロッパーのサイトでデベロッパー自身のトラフィックの一部を使用して初期の機能をテストできます。この段階で役立つフィードバックとしては、テストへの参加希望の表明や、提案されたテストが動作の検証のニーズを満たしているかどうかなどがあります。
- Intent to Ship(I2S): デベロッパーは、完全な機能を Chromium にデプロイしたいと考えています。これにより、すべてのユーザーが機能を利用できるようになります。この段階で役立つフィードバックは、未解決だった問題が解決されて機能を一般提供する準備ができたという確認です。
- Intent to Remove(I2R): デベロッパーは、機能を非推奨にして Chromium から削除したいと考えています。この段階で役立つフィードバックとしては、この削除によって開発チームが把握していない影響がユースケースに及ぶかどうかの確認などがあります。
各段階には標準テンプレートがあり、デベロッパーはそれを通して関連性の高い情報を厳選して提供します。段階によっては、Chromium プロジェクト オーナーの承認が必要です。オーナーは、投稿に「Looks Good To Me」(LGTM)と回答することにより承認を行います。
メーリング リストは一般公開されているので、どなたでも各マイルストーンでディスカッションを追いかけたり、メーリング リストに参加して質問を追加したりすることができます。このメーリング リストは Chromium プロジェクトで扱われるすべての機能をカバーしているため、そこでは広範なアクティビティが行われています。Chrome ステータスで個々の機能の進捗状況をご覧ください。
メーリング リストのスレッドでは、Chromium における特定の機能の実装の詳細に焦点を絞ってディスカッションする必要があります。提案自体の有効性に関するディスカッションは、GitHub で行うことが適切です。個々のお知らせを閲覧してコメントを投稿するためのリンクは、提案セクションの表のインテントの列にあります。
個々の機能開発を追跡してディスカッションする特定の提案に焦点を絞ったディスカッションを行うため、提案の実装の進捗に応じて特定のメーリング リストが作成されることがあります。
個々の機能開発を追跡してディスカッションする
特定の提案に焦点を絞ったディスカッションを行うため、提案の実装の進捗に応じて特定のメーリング リストが作成されることがあります。
個々の提案の Chromium への実装が進むにつれて、特定の提案に焦点を絞ったディスカッションを行うため、提案固有のメーリング リストが作成されることがあります。
それにより、オリジン トライアルの最新情報、必要なコードの更新、開発に影響する可能性がある既知の問題などに関する通知とディスカッションが可能になります。そのようなメーリング リストは、blink-dev
と同様に一般公開されます。提案を直接追跡している場合や提案に取り組んでいる場合は、提案固有のメーリング リストに参加して、開発チームから最新情報を直接入手する必要があります。
これらのメーリング リストのスレッドでは、Chromium における進行中の実装の詳細に焦点を絞ってディスカッションする必要があります。メーリング リストの対象読者はお知らせ全般に興味がある一般ユーザーではなく、特定の機能のコードを作成するデベロッパーであるからです。メーリング リストで閲覧と投稿を行うためのリンクは、提案セクションの表のメーリング リストの列にあります。
機能に関する問題を報告および追跡する実装の進行に伴い、機能の動作に関する問題が発生した場合、Chromium の Issue Tracker に報告することができます。
機能に関する問題を報告および追跡する
実装の進行に伴い、機能の動作に関する問題が発生した場合、Chromium の Issue Tracker に報告することができます。
報告できる問題には、Chromium の動作が提案された仕様と一致しない実装バグのほかに、ブラウザ固有の機能(提案された機能が DevTools やユーザー設定とどのように相互作用するかなど)に関する問題や、単にエラーを報告するだけのものもあります。デベロッパー テスト用に新しく追加された試験運用機能の問題であれ、安定版リリースで検出された問題であれ、問題は Chromium 機能のライフサイクルのどの時点でも報告できます。
Chromium の問題については、Chromium の想定される機能実装の詳細に焦点を絞ってディスカッションする必要があります。提案自体の有効性に関するディスカッションは、GitHub で行うことが適切です。問題を閲覧または報告するためのリンクは、提案セクションの表の Chromium コンポーネントの列にあります。
標準化団体をフォローして参加するワールドワイド ウェブ コンソーシアム(W3C)とインターネット技術特別調査委員会(IETF)は、すべてのウェブ プラットフォーム向けのオープン標準を開発しています。それらの団体は、関係者が個々の基準と大規模なウェブ エコシステムについて議論し、知識を深めることを奨励しています。
標準化団体をフォローして参加する
ワールドワイド ウェブ コンソーシアム(W3C)とインターネット技術特別調査委員会(IETF)は、すべてのウェブ プラットフォーム向けのオープン標準を開発しています。それらの団体は、関係者が個々の基準と大規模なウェブ エコシステムについて議論し、知識を深めることを奨励しています。
W3C と IETF は、ウェブとインターネットのためのオープン標準を開発し、オープン プラットフォームの長期的な成長を促進する国際団体です。それらの標準化団体のさまざまなフォーラムでは、プライバシー サンドボックス技術のような新しいウェブ プラットフォーム技術が提案され、議論されています。フォーラムは、技術の設計と開発に積極的に参加することを希望するすべての人々に開放されています。
各標準化団体は、あらゆる関係者に対してさまざまなメンバーシップと貢献方法を提供しています。たとえば、ウェブ エコシステムと関連業界の人々が参加しているコミュニティ グループとビジネス グループがあります。提案の作成者は、しばしば関連する会議で概要と進捗状況に関する最新情報を紹介し、参加者が直接質問したり他の関係者から話を聞いたりする機会を設けています。ほとんどのグループの議事録は一般公開されています。 標準化団体での議論は広範囲にわたりますが、一般的には、提案がエコシステムのニーズを満たす方法と、提案が標準として承認されるまでの進捗状況に焦点を絞っています。標準化団体をフォローするかそれらに参加するためのリンクは、提案セクションの表の標準化団体の列にあります。
フィードバック フォームを使ってフィードバックを送信するすべての問題が上記のカテゴリに分類されるわけではありません。これらのルートは、最も関連性の高い相手と公開のディスカッションを開始する最良の方法ですが、フィードバック フォームを使用して、いつでも Chrome チームに直接問い合わせることができます。
フィードバック フォームを使ってフィードバックを送信する
すべての問題が上記のカテゴリに分類されるわけではありません。これらのルートは、最も関連性の高い相手と公開のディスカッションを開始する最良の方法ですが、フィードバック フォームを使用して、いつでも Chrome チームに直接問い合わせることができます。
以下の点をお知りになりたい場合は、このフォームをご使用ください。
複数の提案によって特定の状況にどのような影響があるか。
ユースケースが提案の対象となるかどうか。
このフォームによって、関係者は Chrome チームとフィードバックを直接共有できますが、フィードバックのテーマや問題は、関連付けなしで Chrome チームの公開レポートに含められる場合があります。
提案
キー
フィードバック | 個別の提案に関する進行中のディスカッション |
インテント | Chromium 機能開発の各段階におけるお知らせメッセージ |
Chromium コンポーネント | Chromium 機能の実装に関連する未解決の問題 |
メーリング リスト | 開発中の Chromium 機能に関するデベロッパー向けのお知らせとディスカッション |
標準化グループ | 個別の提案についてディスカッションを行っている W3C または IETF のグループ |
ウェブ上のスパムと不正行為の防止
Trust Token API
トラスト トークンを使用すると、クロスサイト トラッキングを許可しなくても、サイトは少量の情報(ユーザーが正当であることを示す情報など)を他のサイトと共有できます。Trust Token API の詳細をご覧ください。
最終更新日: 2022 年 2 月
フィードバック | WICG/trust-token-api |
インテント | I2E 2021/09, I2E 2021/04, I2E 2021/02, I2E 2020/05, I2P 2019/10 |
Chromium コンポーネント | Internals > Network > TrustTokens |
メーリング リスト | [任意] |
標準化グループ | Privacy Enhancements and Assessments Research Group (pearg) |
関連性の高いコンテンツと広告の表示
Topics API
トピックを使用すると、ユーザーがアクセスしたサイトのトラッキングに頼らなくても、インタレスト ベースの広告を表示できます。Topics API の詳細をご覧ください。
最終更新日: 2022 年 3 月 - Topics API はオリジン トライアルに向けて準備中です
フィードバック | jkarlin/topics |
インテント | I2E 2022/03, I2P 2022/02 |
Chromium コンポーネント | [更新される予定です] |
メーリング リスト | topics-api-announce |
標準化グループ | Improving Web Advertising Business Group |
FLoC API
FLoC は、閲覧履歴が類似する数千のユーザーをコホートにグループ化することで、ユーザーの興味 / 関心を大まかに把握する機能を提供していました。FLoC の詳細をご覧ください。
最終更新日: 2022 年 2 月 - FLoC は Topics API に置き換えられました。リンクは過去の情報の参照用です
フィードバック | WICG/floc |
インテント | I2E 2021/03, I2P 2020/05 |
Chromium コンポーネント | Blink > InterestCohort |
メーリング リスト | [任意] |
標準化グループ | Improving Web Advertising Business Group |
FLEDGE API
FLEDGE を使用すると、リマーケティングとカスタム オーディエンスのユースケースに対応できます。たとえば、広告で個別の識別子に依存することなく、ユーザーが以前アクセスしたサイトまたは商品の情報を利用できます。FLEDGE の詳細をご覧ください。
最終更新日: 2022 年 3 月 - FLEDGE API はオリジン トライアルに向けて準備中です
フィードバック | WICG/turtledove |
インテント | I2E 2022/03, I2P 2021/03 |
Chromium コンポーネント | Blink > InterestGroups |
メーリング リスト | fledge-api-announce |
標準化グループ | Improving Web Advertising Business Group |
デジタル広告の測定
Attribution Reporting API のイベントレベルのレポート
イベントレベルのレポートを使用することで、クロスサイト識別子を使用せずに、広告のクリックや閲覧などのユーザー アクションがいつコンバージョンにつながったかをサイトで測定できます。Attribution Reporting API の詳細をご覧ください。
最終更新日: 2022 年 3 月 - Attribution Reporting API は追加のオリジン トライアルに向けて準備中です
フィードバック | WICG/conversion-measurement-api |
インテント | I2E 2022/03, I2E 2021/09, I2E 2021/09, I2E 2021/07, I2E 2021/01, I2E 2020/09, I2P 2019/10 |
Chromium コンポーネント | Internals > ConversionMeasurement |
メーリング リスト | attribution-reporting-api-dev |
標準化グループ | Improving Web Advertising Business Group |
Attribution Reporting API のサマリー レポート
サマリー レポートは詳細なコンバージョン データを集約して確認するのに有用です。データ内の個別のユーザーを特定することなく、レポートに含めたい重要な情報を保持できます。Attribution Reporting API の詳細をご覧ください。
最終更新日: 2022 年 3 月 - Attribution Reporting API は追加のオリジン トライアルに向けて準備中です
フィードバック | WICG/conversion-measurement-api |
インテント | I2E 2022/03, I2P 2021/08 |
Chromium コンポーネント | Internals > ConversionMeasurement |
メーリング リスト | attribution-reporting-api-dev |
標準化グループ | Improving Web Advertising Business Group |
クロスサイトのプライバシー境界の強化
First-Party Sets API
ファーストパーティ セットを使用すると、同じ組織が所有および運営する関連サイトを、同じファーストパーティに属するものとして宣言できます。ファーストパーティ セットの詳細をご覧ください。
最終更新日: 2022 年 2 月
フィードバック | privacycg/first-party-sets |
インテント | I2E 2021/04, I2E 2021/02, I2P 2021/01, I2P 2020/08 |
Chromium コンポーネント | Internals > Network > First-Party-Sets |
メーリング リスト | [任意] |
標準化グループ | Privacy Community Group |
Shared Storage API
共有ストレージを使用すると、サイトはパーティショニングされていないクロスサイト データを保存し、特別に制御された方法でのみそのデータを読み取るようになります。これにより、サイト間で一貫した A/B テストを実施するなど、いくつかのユースケースに対応できます。Shared Storage API の詳細をご覧ください。
最終更新日: 2022 年 2 月
フィードバック | pythagoraskitty/shared-storage |
インテント | I2P 2021/06 |
Chromium コンポーネント | Blink > Storage > SharedStorage |
メーリング リスト | [任意] |
標準化グループ | Improving Web Advertising Business Group |
Cookies Having Independent Partitioned State(CHIPS)
CHIPS では、トップレベル サイトごとに個別の Cookie の格納場所を使用して、Cookie を「パーティショニングされた」ストレージに取り込むことができます。CHIPS の詳細をご覧ください。
最終更新日: 2022 年 2 月
フィードバック | WICG/CHIPS |
インテント | I2E2022/02, I2P 07/2021 |
Chromium コンポーネント | Internals > Network > Cookies |
メーリング リスト | [任意] |
標準化グループ | Web Platform Incubator Community Group (WICG) |
ストレージのパーティショニング
ストレージのパーティショニングを使用すると、トップレベル サイトごとにデータを保管できるようにストレージ用の個別のコンテナを作成して、他の既存の保管方法と通信方法を、提案されている Cookie の変更に合わせることができます。ストレージのパーティショニングの詳細をご覧ください。
最終更新日: 2022 年 2 月
フィードバック | wanderview/quota-storage-partitioning |
インテント | I2P 2021/05 |
Chromium コンポーネント | Blink > Storage |
Mメーリング リスト | [任意] |
標準化グループ | Privacy Community Group |
HTTP キャッシュ パーティショニング
これまで HTTP キャッシュは、あるサイトでリソースが別のサイトを読み込んだかどうかを判断できる単一のポイントとして機能していましたが、事実上、クロスサイト情報の漏洩の原因になっていました。キャッシュをパーティショニングすることで、アクティビティを単一のサイトに制限できます。HTTP キャッシュ パーティショニングの詳細をご覧ください。
最終更新日: 2022 年 2 月 - HTTP キャッシュ パーティショニングは完全リリースされました
フィードバック | shivanigithub/http-cache-partitioning |
インテント | I2S 2020/10, I2P 2019/07 |
Chromium コンポーネント | Internals > Network > Cache |
メーリング リスト | [任意] |
標準化グループ | Web Hypertext Application Technology Working Group (WHATWG) |
ネットワーク状態のパーティショニング
ネットワーク状態のパーティショニングは、キャッシュ用のきめ細かいコンテナを作成することで、HTTP キャッシュ パーティショニングで実装されたパターンを引き継ぎ、クロスサイト情報の漏洩を防止します。ネットワーク状態のパーティショニングの詳細をご覧ください。
最終更新日: 2022 年 2 月
フィードバック | MattMenke2/Explainer---Partition-Network-State |
インテント | I2S 2022/02, I2E 2021/04, I2P 2019/07 |
Chromium コンポーネント | Internals > Network |
メーリング リスト | [任意] |
標準化グループ | Web Hypertext Application Technology Working Group (WHATWG) |
Fenced Frame
Fenced Frame を使用すると、ページと埋め込みコンテンツの間に境界が強制的に設定されるため、クロスサイト トラッキングを許可しなくても、パーティション化されていないデータに安全にアクセスできます。Fenced Frame の詳細をご覧ください。
最終更新日: 2022 年 2 月
フィードバック | shivanigithub/fenced-frame |
インテント | I2P 2021/04 |
Chromium コンポーネント | Blink > FencedFrames |
メーリング リスト | [任意] |
標準化グループ | Improving Web Advertising Business Group |
Federated Credentials Management(FedCM)
Federated Credentials Management API は既存の ID プロバイダのユースケースをベースに構築されているため、サードパーティの Cookie なしで、フェデレーション ID に関する新規および既存のユースケースに対応できます。Federated Credentials Management の詳細をご覧ください。
最終更新日: 2022 年 3 月
フィードバック | fedidcg/FedCM |
インテント | I2E 2022/03, I2E 2022/02, I2P 2020/09 |
Chromium コンポーネント | Blink > Identity > FedCM |
メーリング リスト | [任意] |
標準化グループ | Federated Identity Community Group |
隠されたトラッキングの防止
デフォルトで SameSite=Lax の Cookie 設定
「SameSite=Lax のデフォルト化」は、すべての Cookie をデフォルトでファーストパーティ(つまり same-site)にする仕様変更でした。これにより、サイトはサードパーティ(つまり cross-site)として使用する Cookie を明示的にマークする必要が生じました。SameSite Cookie の詳細をご覧ください。
最終更新日: 2022 年 2 月 - SameSite=Lax のデフォルト化は完全リリースされました
フィードバック | mikewest/cookie-incrementalism |
インテント | I2S 2019/08, I2R 08/2019, I2P+I2S 2019/05 |
Chromium コンポーネント | Internals > Network > Cookies |
メーリング リスト | 任意] |
標準化グループ | HTTP 状態管理メカニズム(httpstate) |
DNS-over-HTTPS
DNS-over-HTTPS は、ブラウザがアクセスしたサイトを同じネットワーク上で覗き見されないようにします。DNS-over-HTTPS の詳細をご覧ください。
最終更新日: 2022 年 2 月 - DNS-over-HTTPS はすべてのプラットフォーム向けにリリースされました
フィードバック | net-dev |
インテント | [該当なし] |
Chromium コンポーネント | Internals > Network > DoH |
メーリング リスト | net-dev |
標準化グループ | DNS Over HTTPS (doh) |
User-Agent の情報量削減と User-Agent Client Hints
Chrome は、デフォルトで User-Agent 文字列内で開示される情報の量を削減し、これにより隠れたトラッキングが行われる可能性を抑制します。User-Agent Client Hints は、サイトがクリーンかつ監査可能な API を使用して、リクエストに応じてこの情報を受け取ることができるようにします。User-Agent の情報量削減と User-Agent Client Hints(UA-CH)の詳細をご覧ください。
注: 全体的な仕組みはさまざまな個別の機能として段階的にリリースされており、その結果としてインテント メッセージが増加しています。
最終更新日: 2022 年 2 月
フィードバック |
|
インテント | I2S 2022/02, I2E 2022/01, I2E 2022/01, I2S 2021/12, I2P 2021/12, I2S 2021/11, I2P 2021/11, I2P 2021/09, I2E 2021/07, I2P 2021/07, I2P 2021/04, I2R 2020/12, I2P 2020/09, I2R 2020/01, I2S 2020/01, I2P 2019/01 |
Chromium コンポーネント | Blink > Network > ClientHints |
メーリング リスト | 任意] |
標準化グループ | Web Platform Incubator Community Group (WICG) |
Gnatcatcher
Gnatcatcher は、サイトからユーザーの IP アドレスをマスクする方法を探索します。マスキングを行うことで、IP アドレスを必要とするコア機能を維持しつつ、主要なトラッキング シグナルを削減できます。Gnatcatcher の詳細をご覧ください。
最終更新日 2022 年 2 月 - プライバシー バジェットの初回提案はまだディスカッションの初期段階にあります
フィードバック | bslassey/ip-blindness |
インテント | [更新される予定です] |
Chromium コンポーネント | [更新される予定です] |
メーリング リスト | [任意] |
標準化グループ | Multiplexed Application Substrate over QUIC Encryption (masque) |
プライバシー バジェット
プライバシー バジェットでは、サイトで利用可能な識別情報の量をブラウザが検出し、大量のデータが収集される前にブラウザが対処できるようにする方法を提案しています。プライバシー バジェットの詳細をご確認ください。
最終更新日 2022 年 2 月: プライバシー バジェットの初回提案はまだ初期の検討段階です
フィードバック | bslassey/privacy-budget |
インテント | [未定] |
Chromium コンポーネント | [未定] |
メーリング リスト | [省略可] |
標準グループ | プライバシー コミュニティ グループ |
Last updated: • Improve article