Web のプライバシー サンドボックス: 変化するプライバシー状況とサイトへの影響

公開: 2023-04-09

Chrome は、2023 年を通じてプライバシー サンドボックス イニシアチブを通じてプライバシーの変更を行い、ユーザー情報のプライバシーを保護するための新しいテクノロジーを構築します。 同時に、Web パブリッシャーとブランドは、サードパーティの Cookie に依存する広告収入と貴重なマーケティング分析を維持するために、デジタル戦略をシフトしています。

ブラウザーのプライバシー保護の拡大に向けた動きにより、Web サイトのパーソナライズに対する需要が高まっています。

このセッションでは、Google Developer Advocate の Sam Dutton が今後の変更について説明し、プライバシー サンドボックス イニシアチブの目標を共有し、ビジネスとサイトを維持するために必要なデータを確実に入手できるように方向転換する方法について理解を深めるのに役立ちます。前進しています。

ビデオ: Web 用のプライバシー サンドボックス: 変化するプライバシーの状況とサイトへの影響

セッションのスライド:

Privacy-Sandbox-for-web-the-changed-privacy-landscape-and-impact-to-your-sitesダウンロード

転写:

サム・ダットン: こんにちは、サム・ダットンです。 私はここロンドンを拠点とする Chrome チームのデベロッパー アドボケイトです。 本日はご参加いただき、誠にありがとうございました。 では、次の 25 分間で 3 つのことを行います。 プライバシー サンドボックス API の概要を説明します。 今何をする必要があるかを説明し、テスターに​​なって API のディスカッションに参加し、フィードバックを提供する方法を示します。

それでは、プライバシーサンドボックスが必要な理由を説明することから始めましょう。 あなたの多くはバックストーリーをよく知っているでしょうが、なぜこれが必要なのか、そしてどのようにして今日に至ったのかを簡単に繰り返す価値があります. そのため、プライバシー サンドボックスは、サード パーティの Cookie などのメカニズムを追跡することなく、将来に向けてオープンな Web に資金を提供するビジネス モデルをサポートする一連のプライバシー保護 API の構築を支援するイニシアチブです。

Google I/O でこの例を見たことがあるかもしれません。 これは、さまざまなソースからのコンポーネントを含む典型的なサイトです。 そしてもちろん、コンポーザビリティは Web のスーパーパワーの 1 つです。 ある起源からの地図、別の起源からのいくつかのスクリプトなどがあります。もちろん、広告、そして私たちが好むと好まざるとにかかわらず、将来がどうであれ、広告は重要な収益源となり、ビジネスの原動力となっています。ウェブ。

歴史のこの時点で、ブラウザーと CMS は広告のユースケースをサポートする必要があると思います。 だから問題は何ですか？ 広告の選択、コンバージョン測定、不正行為の検出、デバイスのカスタマイズ、その他多くのユースケースが、プライバシーを考慮して構築されていないメカニズムを使用したクロスサイト ID に依存しています。

現在、サードパーティの Cookie だけでなく、フィンガープリンティングを使用して、サイト全体でユーザーの行動を追跡したり、サイトが電子メール アドレスなどの個人情報を要求したりします。さらに、サードパーティのエコシステムは、特に広告に関して非常に複雑です。 開発者、広告主、パブリッシャーでさえ、サードパーティ サービスのサプライ チェーンを理解していません。

確かに、私がウェブサイトにアクセスするとき、関係するすべてのサードパーティと、彼らが私のデータで何をしているのかを認識していません。それは私だけではありません.調査によると、人々は自分のデータを管理することを本当に気にかけています. プライバシーに関する懸念は、人々がオンラインで何をするかについての選択をますます促しており、世界中の規制当局はプライバシー要件を強化しており、これは非常に急速に進んでいます。

効果的なオンライン広告に依存している企業の数、サイトを収益化するために広告に依存しているパブリッシャーの数、およびその他の多くのユースケースを考えると、これはテクノロジー企業や広告プラットフォームだけでなく、ウェブ エコシステム全体の問題です。 しかしもちろん、Web はオープン プラットフォームであるため、変更の提案には賛同とフィードバックが必要であり、Chrome などのブラウザは一方的に行動することはできませんし、したくありません。

ブラウザは、ブラウザ ベンダーが単独で決定を下せる製品ではありません。現実には、Web は、広告詐欺の検出、ID 管理、およびその他すべての要件のユース ケースのために今日のプラットフォームの中核となっている要件の多くに対応するように設計されていません。すぐ。 したがって、私たちが必要としているのは、このプライバシーに重点を置いた Web 用に構築されたテクノロジーであり、それがプライバシー サンドボックスの出番です。

そのため、Chrome は業界関係者や規制当局とともにウェブ コミュニティと協力して、健全で持続可能なエコシステムをサポートできる新しいプライバシー保護技術を開発してきました。 これらの新しい専用 API が利用可能になったら、Chrome でのサードパーティ Cookie のサポートを安全に段階的に廃止し、他の種類のトラッキングを軽減する作業を継続できるように、企業がそれらを採用する時間を確保する必要があります。

現在、このイニシアチブの中核となる一連の原則は、Web の潜在的なプライバシー モデルであり、これは Google のプライバシー専門家とコンピューター サイエンティストによって開発されました。 このプライバシー モデルは、変化するプライバシー ニーズを順守しながら、これまでに説明した Web プラットフォームのユース ケースを満たすテクノロジを設計するための一連の基本ルールを示しています。

特に、この提案は、プライバシーを侵害することなくサイト間の接続を可能にする方法という難しい問題をカバーしています。 現在、Privacy Sandbox API の主要なイノベーションの 1 つは、ブラウザがユーザーに代わって動作できるようにすることです。ある意味では、ユーザー エージェントと呼ばれるものとしてのブラウザの中心的な役割に戻ります。

現在のテクノロジーでは、サード パーティによってデータが収集、集約、共有され、サイト間でのユーザーのブラウジングが追跡されます。 プライバシー サンドボックス API を使用すると、広告オークションのコンバージョン測定やその他のタスクを、ユーザーのデバイス上のユーザーのブラウザーで実行できます。

そのため、ブラウザ ベンダー、プラットフォーム、広告主、パブリッシャー、アドテック、ユーザー、規制当局、プライバシー コミュニティ、そして特に CMS プラットフォームで作業している開発者の協力を得て、広告プラットフォームとウェブを再構築する必要があります。

これらすべてを念頭に置いて、Privacy Sandbox API 自体のホイッスル ストップ ツアーを提供したいと思います。 したがって、Google では、これはウェブと Android で共有されているイニシアチブです。 Android のプライバシー サンドボックスは、クロスアプリ識別子を使用しない、よりプライベートな新しい広告ソリューションの導入に重点を置いています。

もちろん、Web と Android は同じ原則を共有しており、Android 向けにもいくつかの Web 提案が開発されています。 ただし、もちろん、Web と Android モバイル プラットフォームは根本的に異なるテクノロジに依存しています。

したがって、これは Android に関する独自のイニシアチブですが、Android アプリを作成し、Web で作業している方は、そのイニシアチブに注目してください。 そのため、Google は世界中のさまざまなパートナーと協力して新しい API をテストしています。

W3C などのパブリック フォーラムに参加している何百もの企業が、GitHub などで問題を説明し、視点と分析を公開し、業界の円卓会議に参加し、Chrome と Android でフィードバックを共有し、もちろんテストに参加しています。

間違いなく、Privacy Sandbox にはカバーする必要のある要件がたくさんあり、その道のりは厳しいものになるでしょう。 つまり、良いニュースは、これらすべての終わりには、ユーザーにとってより安全でプライベートなプラットフォームがあり、広告主、パブリッシャー、開発者、そしてもちろん WordPress のようなプラットフォームにとってより良いプラットフォームを持つことだと思います.

したがって、すべてのプライバシー サンドボックス API について説明するつもりはありません。 代わりに、プライバシー サンドボックスの 3 つの主要な広告 API に焦点を当てたいと思います。 それがトピック、FLEDGE、アトリビューション レポートです。 私たちのトピックと FLEDGE は、関連 API として知られています。

現在、トピックは、ユーザーの最近の閲覧履歴に基づいて、ユーザーの関心の高レベルのシグナルを提供します。 また、トピックをコンテキスト シグナルやファースト パーティ データと組み合わせて、関連する広告を選択することもできます。

また、FLEDGE は、マーケティング担当者が特定の Web サイトや製品に関心を示したオーディエンスにリーチしたい場合に、より詳細なリマーケティングとカスタム オーディエンスの使用例をサポートしますが、もちろん、プライバシーを保護する方法でそれを可能にします.

最後に、アトリビューション レポートは、プライバシーを保護するキャンペーン測定のための Chrome の提案であり、匿名化されたパフォーマンス レポートを提供し、ユーザーが広告を表示またはクリックした後、購入またはその他の種類のコンバージョンを完了したときに提供します。

そのため、これらの API は、Android およびデスクトップとモバイルの Chrome で一定期間テストされています。 アドテク プラットフォームを使用している場合は、サード パーティの Cookie やその他の追跡メカニズムを使用せずに、これらのユース ケースに対応するプラットフォームの計画と、これらの API によって将来的に満たされるユース ケースを理解していることを確認する必要があります。

そのため、Chrome フラグを使用してアクティブ化された API を使用して一定期間の技術テストを行いました。現在は、最初はごく一部の Chrome ユーザーのみを対象として最初にアクティブ化されたオリジン トライアルです。 現在、ユーティリティ テストのこの段階にあり、Chrome Canary の開発者とベータ版のユーザーの 50% が、有効なトークンを提供するページで広告オリジン トライアル API を有効にしており、安定したユーザーの 5% が有効になっています。

もちろん、これは Chrome トラフィック全体のごく一部ですが、実際のユーザーによる API の限定的なテストには十分です。 そして現在、すべてのユーザーがデフォルトで API を利用できるようになる Chrome Stable でのリリースに向けて動いています。そのタイムラインについては後で説明します。

繰り返しになりますが、1 人のユーザーの場合、Chrome フラグを使用して API をアクティブ化できますが、大規模なテストを行うには、プライバシー サンドボックスのオリジン トライアルに参加する必要があります。その方法に関するガイダンスについては、後でリンクを共有します。 .

ところで、Chrome はこの UI のようなユーザー プライバシー コントロールも更新しています。また、プライバシー サンドボックス コントロールは、ads API オリジン トライアルの一部として実際に利用できます。 ユーザーは、ブラウジングに関連する興味を確認して管理したり、API を完全にオフにしたりできます。

したがって、実際には他にも 3 つのプライバシー サンドボックス テクノロジがあり、これらをテストするか、サード パーティ プロバイダーに確実にフラグを立てたいと思うかもしれません。 まずはCHIPS。 That's Cookies having Independent Partition State により、開発者はトップ レベル サイトごとに個別の Cookie jar を使用してパーティション ストレージに Cookie をオプトインできます。

ファースト パーティ セットを使用すると、同じエンティティによって所有および運用されている関連ドメイン名が、同じファースト パーティおよびプライベート ステート トークンに属していると宣言できます。 この最初の名前を Trust Tokens と聞いたことがあるかもしれません。 これは、特定のブラウジング コンテキストから別のブラウジング コンテキストに限られた量の情報を伝達するための API です。

それではまず、トピック API について詳しく見ていきましょう。 トピック API は、興味に基づく広告を有効にするメカニズムを提供しますが、第三者がユーザーのブラウジング アクティビティを追跡することはできません。 したがって、ある意味で API には 3 つの主要なコンポーネントがあり、まずインタレスト ベースの広告には、関心のあるトピックの分類法が必要です。

トピック API の分類は次のようになります。 これは、機密性の高いトピックを避けた、人が読める形式で公開されているトピックのリストです。 そして今、これは Web エコシステムとの協議により、時間の経過とともに変更および発展する可能性があります。つまり、あなたのような人々は、これだけでなく他のすべてについてもフィードバックを必要としています。

そのため、トピック API はユーザーのブラウジング アクティビティに基づいてユーザーの興味を推測する必要がありますが、プライバシーを保護する方法でそれを行う必要があります。 そのため、関心のあるトップ トピックは、デバイスのブラウザによって、最近のブラウジング アクティビティに基づいて、デバイスのブラウザに記録されます。

現在、トピックスは、機械学習を使用して、ユーザーがアクセスしたページのホスト名を分類法からトピックスにマッピングすることでそれを行っています。 現在、トピックの分類自体と同様に、そのアプローチは時間の経過とともに発展します。 しかし、ブラウジング アクティビティから興味を推測するには、適切なバランスを取る必要があります。

ユーザーのブラウジングに関する詳細が多すぎるとプライバシーに悪影響を及ぼしますが、粒度が小さすぎると API が役に立たないことを意味します。 ここで理解しておくべき重要なことは、関心のあるトピックは、ユーザーに関連するものを見つけるための 1 つのシグナルにすぎないということです。

そのため、ブラウザーによってユーザーの関心のあるトピックが推測されると、トピックは API 呼び出し元に、ユーザーが観察した関心のあるトピックへのアクセスを提供する必要があります。

したがって、ユーザーが Web をナビゲートするとき、API には 2 つの段階があります。 API 呼び出し元 (たとえば、アドテック プラットフォームなど) は、ページで API を呼び出して、現在のページと現在のユーザーのトピックを監視する必要があることを通知します。

後で、API 呼び出し元は、ユーザーについて観察したトピックにアクセスできます。 これはすべて、観察された関心のあるトピック以外のユーザーのブラウジング アクティビティについて何も明らかにすることなく実行する必要があります。

そのため、トピック API は、ユーザーが関心のあるトピックを観察し、観察されたトピックにアクセスするための 2 つの方法を提供します。まず JavaScript API を使用する方法と、フェッチ リクエストでリクエスト ヘッダーとレスポンス ヘッダーを使用する方法です。

トピック API の呼び出し元が、ユーザーのトピックを観察したことをブラウザーに通知できる最初の方法は、ユーザーがアクセスするサイトに埋め込まれた iframe から document.browsingTopics を呼び出すことです。

その後、API 呼び出し元は同じ document.browsingTopics メソッドを呼び出して、現在のユーザーについて観察したトピックにアクセスできます。 ちなみに、このメソッドが iframe を必要とする理由は、トピックを観察するためのコンテキストが、トピックにアクセスするためのコンテキストと同じでなければならないからです。

トピックを観察してアクセスするもう 1 つの方法は、フェッチ、リクエスト、およびレスポンス ヘッダーを使用することです。 最初に、API 呼び出し元は、そのオリジンの URL に対してフェッチ リクエストを作成する必要があります。これには、オプション パラメーターのブラウジング トピックの真のオブジェクトが含まれます。

そして、フェッチ要求への応答に Observe-Browsing-Topics ?1 ヘッダーが含まれている場合、それは、呼び出し元が現在のユーザーの関心のあるトピックを現在のユーザーが観察したことをブラウザーに記録してほしいというシグナルをブラウザーに送信します。ページ。 それが理にかなっていることを願っています。

現在、sec-browsing-topics リクエスト ヘッダーにアクセスすることで、呼び出し元のフェッチ リクエストからユーザーについて観察されたトピックを取得できます。 というわけで、最初から最後までの全行程です。 時間を意識しているので、今は説明しませんが、後で共有して、それがどのように機能するか、プロセス全体を確認できるようにします。各 API について説明します。

また、JavaScript iframe メソッドを使用してトピックを監視およびアクセスするトピック デモを試すか、フェッチ リクエスト ヘッダー アプローチを使用するデモを試すことができます。 chrome://topics-internals は、現在のユーザーのトピック、ホスト名について与えられたトピック、および API 実装に関する技術情報を表示します。

また、トピック共同実験室を実行して、トピック分類子モデルを使用してトピックの推論をテストすることもできます。 トピックを離れる前に、未解決の問題が 3 つあります。ユーザーのブラウジング アクティビティに基づいて、ユーザーが興味を持っているトピックをより適切に推測するにはどうすればよいでしょうか? タクソノミーのコンテンツと構造を改善して、ユーザーのプライバシーを保護しながらより有用なものにするにはどうすればよいでしょうか? また、API の全体的なアーキテクチャを改善するにはどうすればよいでしょうか?

ここで心に留めておくべきことの 1 つは、トピックがあるかどうかに関係なく、そのユース ケースを満たす必要があるということです。 お次はFLEDGE。 したがって、これは、クロスサイトのサードパーティ トラッキングを必要とせずに、リマーケティングやカスタム オーディエンスのユースケースに対応するデバイス広告オプションの API です。

FLEDGE はトピックよりも複雑な作業を行うため、コードの詳細が少し増えると思います。 したがって、FLEDGE プロセスには 3 つの部分があります。 まず、広告バイヤーは、ユーザーまたは個々の閲覧者をインタレスト グループと呼ばれるものに実際に追加します。 これらはカスタム オーディエンスに似ていますが、インタレスト グループのメンバーシップはユーザーのデバイスのブラウザーに保存されます。

ユーザーがパブリッシャー サイトなどの広告を表示するサイトにアクセスした時点で、広告販売者が広告オークションを開始して広告を選択し、FLEDGE を使用すると、このオークションをユーザーのデバイスで実行できます。

広告を選択するために、オークション コードはバイヤーから入札ロジックを実行し、セラーからオークション ロジックを実行します。 最後に、ブラウザは売り手と買い手が提供するエンド ポイントにオークション レポートを送信します。

だから私はFLEDGEを一歩一歩非常に簡単に見ていきます。 まず、ユーザーがオンラインの靴屋を訪れ、ブラウジングを行ったとします。 アドテク プラットフォームまたは広告主自身が JavaScript 呼び出しを行い、ブラウザに利益団体に参加するように指示します。 このグループの名前は、トレイル ランニング シューズのようなものかもしれません。

インタレスト グループの構成オブジェクトは次のようになります。 この例では、靴屋の広告技術に、ユーザーを追加したいリマーケティング用のインタレスト グループがあり、彼らはこのグループを Trail Running Shoes と呼んでいます。 また、靴屋のアドテック プラットフォームは、join ad Interest group を呼び出して、ユーザーのブラウザーに、先ほど示した構成を使用して、トレイル ランニング シューズの興味グループに参加するように求めます。

2 番目のパラメーターは、関心グループの期間を指定しますが、これは 30 日に制限されています。 ここで、ユーザーが広告を掲載するサイトにアクセスします。 この例では、ニュース Web サイトです。 ユーザーに表示する広告を選択するためのオークションは、広告オークションの実行を使用して販売者によって JavaScript でユーザーのデバイス上で実行されます。販売者はおそらくアド テク プラットフォームですが、パブリッシャー自体 (この場合はニュース サイト) である可能性もあります。

このオークションでは、ユーザーのブラウザが属している関心グループごとに、販売者とブラウザ自体からの他の要因とともに、入札が与えられた場合に最も適切な広告が選択されます。

コードを見ると、パブリッシャーまたはパブリッシャーのサイトで広告スペースを販売するプラットフォームが、広告オークション用の構成データを作成しています。 次に、売り手はブラウザに広告オークションを実行してブラウザで広告を選択するように要求します。広告オークションの実行によって返された値は、フェンシング フレームと呼ばれる要素に渡され、サイトは落札した広告を表示できます。

フェンスで囲まれたフレームを使用して広告を表示できるようになりましたが、その周りのページと対話することはできません。 そして、売り手と落札した買い手はそれぞれ、ログとレポートを実行する機会が与えられます。これは、navigator.reportresult を呼び出すことによって行われます。

最後に、すべてがうまくいけば、ユーザーが広告をタップまたはクリックすると、Attribution Reporting API が引き継ぎます。 繰り返しになりますが、最初から最後までのプロセス全体を示す図があります。これは基調講演の後に共有します。

最後に、広告測定用のプライバシー サンドボックス API である Attribution Reporting について少しお話ししたいと思います。 アトリビューション レポートは、広告クリックまたは広告インプレッションがいつコンバージョンにつながったかを測定するために使用されます。 たとえば、ニュース サイトで広告を表示したことが、オンラインの靴屋での購入につながった場合などです。

現在、トピックや FLEDGE と同様に、この API はクロスサイト トラッキングを回避するように設計されています。 そのため、API では、イベント レベル レポートと概要レポートの 2 種類の測定結果が可能です。 それでは、その仕組みを簡単に説明しましょう。

まず、イベント レベルのレポートを見てみましょう。 Attribution Reporting API に固有の属性を使用して広告リンクを設定できるため、コンバージョン側のリクエストでビューとクリックを集計できます。

ユーザーが広告をクリックするか、広告を見てからコンバージョンに至ると、ブラウザがレポートを生成し、そのレポートに広告会社またはアドテクが 2 つのデータを含めます。 1 つは、広告のクリックまたはインプレッションに関して必要なデータです。これは、クリエイティブ ID、パブリッシャーに関する情報、タイムスタンプなど、非常に詳細なデータです。 次に、広告コンバージョンに関する小さなデータです。

ここで、ユーザーのプライバシーを保護するために、これをあまり詳しく説明することはできません。 後でブラウザはそのレポートを送信します。ちょうど私が広告技術者または広告主に説明したデータを含むレポートであり、ユーザーの追跡を回避するための遅延が含まれています。

レポートには、広告のクリックまたはインプレッションに関する詳細データ、イベント、コンバージョンに関する概要データの 2 つのデータが含まれます。 これはイベント レベルのレポートです。 それでは、概要レポートを見てみましょう。

概要レポートを生成するためのブラウザー API は似ていますが、結果とメカニズムは少し異なります。 繰り返しになりますが、ユーザーが広告をクリックするか、広告を見て、その後コンバージョンに至ると、ブラウザはレポートを生成します。そのレポートには、広告会社または広告技術が、広告のクリックまたはインプレッションに関する必要なデータと、それらのデータを含めることができます。広告コンバージョンについて知りたいのですが、このレポートは暗号化されています。

このレポートにはコンバージョンとインプレッションに関する詳細なデータが含まれているため、これはプライバシー保護です。 そのため、レポートが暗号化されていなければ、クロスサイト トラッキングに使用される可能性があります。 その後、ブラウザはこの暗号化されたレポートを少し遅れて再度送信します。

このようにして、アドテック プラットフォームは多くのユーザーから多くのレポートを収集し、呼び出されたときにすべてのレポートを集約サービスに送信します。このサービスは、これらすべてのレポートを集約し、復号化し、ユーザーのプライバシーを保護するためにノイズを追加してから、最終結果を返します。最終結果は要約レポートと呼ばれます。 多くのユーザーの測定データが含まれています。

それがアトリビューション測定です。 それが理にかなっていることを願っています。 プライバシー サンドボックス API をより詳細に理解し、テストするのに役立つ多くのリソースにリンクします。 しかし、最後に 1 つ言及したいのは、Privacy Sandcastle です。

これは、すべての主要なプライバシー サンドボックス API を組み合わせたデモです。 東京の私たちのチームによって構築されました。 まだとても新しいです。 ただし、GitHub からコードを取得してローカルで実行することもできます。これは、これらすべての API がどのように組み合わされるかを理解するのに役立つように設計されています。

最後に、要約してプライバシー サンドボックスのタイムラインを見てみたいと思います。 ご覧のとおり、API の出荷を開始する四半期に近づいています。つまり、API は Chrome Stable でデフォルトで利用可能になり、本番環境でのテストの準備が整います。 カレンダー上ではわずかな時間しかありませんが、自分自身を見ることができます。 私はここにいる時間に近づいています。

そこで、あなたが今しなければならないと私が考えるいくつかのことがあります。 まず、ウェブと Android のタイムラインを理解します。 あなたとあなたのサード パーティ プロバイダーが、差し迫った変更に備えていることを確認してください。 次に、サイトを監査して、サードパーティの Cookie や非推奨になっているその他のメカニズムにどこが依存しているかを理解します。 本日のイベント後に、ツールへのリンクとその方法についての説明を共有します。

次に、アドテック プラットフォームなどのサード パーティ プロバイダーに、サード パーティの Cookie やその他のクロスサイト トラッキング メカニズムがない場合にコア ユース ケースを満たすためにどのように準備しているかを尋ね、最後にプライバシー サンドボックス API をテストしてフィードバックを提供します。サードパーティのプロバイダーに同じことを依頼してください。

体調が優れない場合は、その理由を尋ね、その質問に対する答えをお知らせください。 そのため、privacysandbox.com では、タイムライン、FAQ、クロスプラットフォームの取り組みに関する詳細情報を提供しています。 このイベントの後に URL を共有しますが、ここで参照したコンテンツの多くは、developer.chrome.com のプライバシー サンドボックス セクションから見つけることができます。

特に、これには質問の仕方やフィードバックの提供方法を​​説明するリソースがあり、developer.chrome.com でオリジン トライアルの詳細を確認できます。 また、オリジン トライアル、Chrome フラグ、ブリンク コンテンツなど、Chrome の概念を説明する一連の短いビデオと記事を作成しました。

聞いてくれてありがとう。 それは私からです。 私が言うように、サポートが必要な場合は、これらのリソースにアクセスするか、Twitter で SW12 に直接メッセージを送ってください。 本当にありがとう。