デジタル カンファレンス Google Cloud Day: Digital '22 開催まで、1 か月を切りました。今回は、新しいプログラムである特別講演と、Innovators Hive についてご紹介します。
スペシャルゲストをお呼びして、対談形式のセッションをお届けします。
DAY 2（4 月 20 日）は、「クラウドによる、これからの日本のテクノロジーの変革」をテーマに、デジタル庁ガバメント クラウドチームから梅谷氏をお迎えし、お話をお聞きします。
DAY 3（4 月 21 日）は、「Tech Leader に聞く。マルチクラウド活用における技術選定とそれを支える組織」と題して、経験豊かなテックリーダーの皆様とパネルセッション形式でお届けします。
Innovators Hiveエンジニア、デベロッパーの皆さんのための新しいイベントです。さまざまなコミュニティの Meetup や座談会を実施します。Google Cloud Innovators に参加し、Google 製品の深いストーリーやご自身の知識と経験を共有しあって、一緒に盛り上がりましょう！※イベントにご参加いただく際、Innovators プログラムのメンバー登録をお願いいたします。
日程 :
お問い合わせ先 : Google Cloud Day: Digital '22 事務局（gcd22-office@event-info.com）
昨年 10 月に開催された Google Cloud Next で、Google チームは地理空間情報企業である CARTO と vis.gl Technical Steering Committee（TSC）との連携により、deck.gl 可視化ライブラリの最新リリースを発表しました。deck.gl のリリースには、Maps JavaScript API の WebGL による新機能との緊密なインテグレーションが含まれており、ベースマップ上で直接 2D ・ 3D のいずれも可視化できるようになりました。
CARTO のチームは、テキサス州のトラックを電化できる可能性を示す各種データソースを可視化したサンプルアプリを作成しました。このアプリは、Google Maps Platform と deck.gl で作成できる、さまざまなタイプの高度なデータの可視化を紹介しています。そこで、皆様に、可視化のためのデータソースと、CARTO プラットフォームがどのように可視化を実現しているのかについてご紹介します。
Google Cloud は、地理空間クエリをサポートするサーバーレス データ ウェアハウス ソリューションである BigQuery を提供します。空間データを扱う場合、データセットを探索し可視化する地図を作成することは、重要かつ一般的に必要とされていることです。CARTO Spatial Extension for BigQuery は、データ ウェアハウスへの接続を作成し、BigQuery テーブルからのデータで地図を設計し、deck.gl を使用してウェブアプリで可視化する簡単な方法を提供します。
CARTO プラットフォームを使用してシンプルな地図を作成するには、体験版アカウントに登録します。ログインすると、サービス アカウントを使用して BigQuery インスタンスと接続するように設定できます。設定したら Data Explorer に移動して、利用可能なデータセットを確認し、地図でデータソースとして使用したいテーブルを見つけます。詳細については、CARTO ドキュメントをご確認ください。
テキサス州の送電線を可視化するために、まずテキサス州の行政界情報を引き出す所から始めると、概況がつかめます。Data Explorer でテーブルをプレビューし、右上の [Create map] ボタンをクリックし、可視化の設定作業を開始します。
地図作成ツールである CARTO Builder を使用して、背景地図として利用可能な Google のベクターベースマップのスタイルの中から 1 つを選び、レイヤスタイルをカスタマイズします。
SELECT *
FROM cartobq.nexus_demo.transmission_lines
WHERE ST_INTERSECTS(
geometry,
(SELECT geom FROM cartobq.nexus_demo.texas_boundary_simplified)
);
[Run] ボタンをクリックすると、Google Cloud の BigQuery 側でクエリが実行されます。結果は Builder ツールに返送され可視化されます。新しいレイヤでスタイルのカスタマイズをすれば、地図表現の準備は完了です。
Google Maps Platform アプリケーションに地図を追加する前に地図を公開する必要があります。[Share] ボタンをクリックして、[Developers] タブを選び、地図 ID をコピーします。
あとは、以下の 4 行のコードを追加するだけで、Google Maps Platform アプリケーションで CARTO で設定した主題図を可視化できます。
const cartoMapId = 'b502bf53-877d-4e89-b5ad-71982cac431d';
deck.carto.fetchMap({cartoMapId}).then(({layers}) => {
const overlay = new deck.GoogleMapsOverlay({layers});
overlay.setMap(map);
});
fetchMap 関数を呼び出すには、CARTO Builder からコピーした地図 ID が利用できます。この関数はプラットフォームに接続し、指定したすべてのスタイリング プロパティを持つ deck.gl レイヤのコレクションを含む、可視化に必要なすべての情報を取得します。このレイヤのコレクションを使って、deck.gl GoogleMapsOverlay のインスタンスを作成し、地図に追加します。
完全なサンプルはこちらのこちらからご覧ください。
BigQuery の大きな特徴の 1 つは、巨大なデータセットに対しても処理をスケールアウトできることです。CARTO プラットフォームでは、タイルセットという、あらかじめ生成されたベクトルタイルを含む空間的に最適化されたデータ構造を使って、非常に大きなデータセットを高速で可視化できます。タイルセットは BigQuery 内で Analytics Toolbox 関数を使用して数十億点を処理できる並列処理で生成されます。
例えば、前述の米国の送電線の全データセット、100 MB 以上のジオメトリでタイルセット機能を使用して可視化できます。
このような大規模なデータセットの問題点は、一度にメモリに収まらないことです。そのため、タイルに分割して順にレンダリングする必要がある訳ですが、CARTO はこの点をあらかじめ考慮し、BigQuery で直接タイルセットを作成したり、オンザフライで動的に生成することができます。
この方法で地図にデータを読み込むと、必要な範囲だけをレンダリングすることが可能です。例えば、170 億点の船舶データを可視化した以下のサンプルを見てみましょう。
BigQuery は継続的に更新されるストリーミング データをサポートしています。このシナリオでは、データの変化に応じて、一定間隔で可視化を更新できるように設定しています。deck.gl を使用すれば可視化情報を更新することは簡単です。地図の取得時に autoRefresh パラメータを true に設定し、新しいデータがダウンロードされたときに実行したい関数を指定するだけです。
const {layers} = await deck.carto.fetchMap({
cartoMapId,
autoRefresh: true,
onNewData: (parsedMap) => { … }
BigQuery のコンソールで INSERT 関数を使ってテーブルにポイントを追加し、地図上でリアルタイムにデータが更新されるのを見ることができます。
上に示したようなシンプルな可視化の方法に加え、deck.gl は、広範囲に可視化する柔軟性を備えています。CARTO プラットフォームはデータ ウェアハウスからデータにアクセスし、高度な地図作成機能でデータを可視化する機能を提供します。さらに、deck.gl レイヤカタログで利用できる高度な可視化によって、機能を拡張できます。
deck.gl のコードをさらにコントロールするための追加オプションが 2 つあります。1 つ目は、fetchMap を使用せずに、直接 CartoLayer を使用する方法です。この場合、CARTO プラットフォーム側で接続対象の地図データの設定と、データソースのタイプ・名前、クエリやスタイル プロパティなどを指定する必要がありますが比較的容易に可視化レイヤを生成可能です。
const overlay = new deck.GoogleMapsOverlay({
layers: [
new deck.carto.CartoLayer({
connection: 'bqconn',
type: deck.carto.MAP_TYPES.TABLE,
data: `cartobq.public_account.retail_stores`,
getFillColor: [238, 77, 90],
pointRadiusMinPixels: 6,
}),
],
2 つ目は、fetchLayerData 関数を使用する方法です。この関数は、BigQuery とアプリケーション間のデータ転送に使用されるフォーマットをさらにコントロールすることが可能で、ArcLayer、H3HexagonLayer、TripsLayer などの特定のデータ形式を必要とする高度な可視化において使用できます。
deck.carto.fetchLayerData({
source: `cartobq.geo_for_good_meetup.texas_pop_h3`,
format: deck.carto.FORMATS.JSON,
credentials: {
accessToken: 'eyJhbGciOiJIUzI1NiJ9.eyJhIjoiYWNfbHFlM3p3Z3UiLCJqdGkiOiI1YjI0OWE2ZCJ9.Y7zB30NJFzq5fPv8W5nkoH5lPXFWQP0uywDtqUg8y8c'
}
}).then(({data}) => {
const layers= [
new deck.H3HexagonLayer({
id: 'h3-hexagon-layer',
data,
extruded: true,
getHexagon: d => d.h3,
getFillColor: [182, 0, 119, 150],
getElevation: d => d.pop,
elevationScale: 2.5,
parameters: {
blendFunc: [luma.GL.SRC_ALPHA, luma.GL.DST_ALPHA],
blendEquation: luma.GL.FUNC_ADD
})
];
両方のオプションを使用した完全なコードは、こちらのサンプルをご覧ください。
deck.gl のドキュメント ウェブサイトと CARTO のドキュメント センターで、デモやドキュメントにアクセスできます。ご不明な点がある場合は、CARTO Users Slack ワークスペースにて、CARTO チームにお問い合わせください。
Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 3 月 3 日時点で、Chrome 100 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。
Chromium 100 は、デフォルトで長い User-Agent 文字列をサポートする最後のバージョンとなる予定です（これに関連する navigator.userAgent、navigator.appVersion、navigator.platform DOM API も同様です）。サイトで完全削減版の User-Agent をテストできるようにするオリジン トライアルは、2022 年 4 月 19 日に終了します。この日以降、User-Agent 文字列は徐々に削減されます。全体スケジュールを確認したい方は、Chromium ブログ : User-Agent 削減のオリジン トライアルと日付についてをご覧ください。サイトでのテストや User-Agent Client Hints への移行にさらに時間が必要な場合は、Chrome 100 から 113（100 と 113 を含めて）で予定されている逆オリジン トライアルに登録できます。完全削減版の User-Agent 文字列を試す最初のオリジン トライアルとは異なり、逆トライアルでは以前の User-Agent が保持されます。逆トライアルは、2023 年 5 月後半に終了する予定です。
navigator.userAgent
navigator.appVersion
navigator.platform
これは、User-Agent 文字列を 新しい User-Agent Client Hints API に置き換える戦略の一環として行われます。User-Agent Client Hints の詳細については、User-Agent Client Hints に移行すると User-Agent Client Hints でユーザーのプライバシーとデベロッパーのエクスペリエンスを改善するをご覧ください。
PC で利用できるようになるマルチスクリーン ウィンドウ配置 API を使うと、マシンに接続されているディスプレイを列挙し、ウィンドウを特定の画面に配置できます。これにより、特定のウィンドウを厳密に配置する必要があるマルチウィンドウ アプリケーションなどのユースケースを実現できます。さらに、Element.requestFullscreen() メソッドに新しい screen オプションが追加され、どの画面で全画面表示を始めるかを指定できるようになります。
Element.requestFullscreen()
screen
詳細については、マルチスクリーン ウィンドウ配置 API で複数のディスプレイを管理するをご覧ください。
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
次のオリジン トライアルは、記載されているバージョンまで延長されます。
専用のワーカーから Media Source Extensions（MSE）API を利用できるようにするためのオリジン トライアルが継続されます。この機能により、メイン ウィンドウの HTMLMediaElement で再生中のメディアをバッファリングする際のパフォーマンスが向上します。アプリケーションは、専用ワーカーで MediaSource オブジェクトを作成した後、そのオブジェクト用の ObjectURL を作成できます。次に、postMessage() を呼び出してその URL をメインスレッドに渡し、HTMLMediaElement にアタッチします。すると、MediaSource オブジェクトを作成したコンテキストからメディアをバッファリングできます。ウェブ制作者からは、ワーカーのコンテキストから MSE を利用したいというリクエストが継続的に寄せられています。このオリジン トライアルの延長は、2022 年 7 月後半の Chrome 103 までとなる予定です。
HTMLMediaElement
MediaSource
postMessage()
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
ウェブ アプリケーションからのアプリ内購入を促進するため、Chrome でデジタル商品の照会や管理をする API が提供されます。この新しい API は、実際の購入処理に使われる Payment Request API と連携して動作します。この API は、ユーザー エージェントを通して接続するデジタル配信サービスにリンクできます。Chromium の場合、これは Android Play 請求サービス API のウェブ API ラッパーを指します。
この API を使うと、Play ストアのウェブアプリで、デジタル商品の購入をすることができます（Play ポリシーでは、他の方法で支払いを受けることは禁止されています）。これがないと、デジタル商品を販売するウェブサイトを Play ストアからインストールすることはできません。
詳細については、Digital Goods API と Payment Request API で Google Play 請求サービスから支払いを受ける - Chrome Developers をご覧ください。
シグナルが異常終了した場合に、Chrome が AbortSignal オブジェクトの理由をスローするようになります。この便利なメソッドを使うと、シグナル処理関数でシグナルの中断ステータスを確認し、中断の理由を伝播できます。たとえば、シグナルのステータスが変わる可能性がある非同期操作の後に呼び出すことができます。
AbortSignal
多くの場合、中断シグナル処理関数では、シグナルのステータスをチェックし、中断している場合はエラーを伝播する必要があります。この機能により、一貫した便利な方法を使ってそれを実現できるようになります。例は、すでに MDN に掲載されています。
Capability Delegation とは、あるフレームが制限された API を呼び出す機能を放棄し、その機能を信頼する（サブ）フレームに移管できるようにすることを指します。制限された JavaScript（ポップアップ、全画面表示など）を呼び出す機能を既知の信頼するサードパーティ フレームに委譲する必要があるアプリは、この API を使って、指定した期間、その機能を対象のフレームに移管できます。この機能は、iframe の allow 属性のような静的なメカニズムとは対照的です。
多くの販売者のウェブサイトに独自ドメインのオンライン ストアがホストされていますが、カード決済に関するセキュリティや規制に準拠する複雑さに対応するために、支払いの回収や処理インフラストラクチャは決済サービス プロバイダ（PSP）にアウトソースされています。このワークフローは、販売者のウェブサイトのトップ（販売者）フレームに他の部分とうまく調和する「支払い」ボタンを配置し、支払いリクエストのコードは PSP によるクロスオリジン iframe に配置するという形で実装されます。PSP のコードで使われる Payment Request API は、一時的にユーザーがアクティブ化することによって制御されます（悪意のある試みによって、支払いリクエストが自動で実行されたり繰り返されたりすることを防ぐため）。トップ（販売者）フレームのユーザー インタラクションは iframe から見ることができないので、決済処理を始める前に、トップフレームのクリックに応答して PSP コードに委譲する必要があります。
ウェブ デベロッパーは、HIDDevice forget() メソッドを使うことで、ユーザーが許可した HIDDevice へのパーミッションを自発的に取り消すことができます。HID デバイスにアクセスする長期パーミッションを保持する必要がないサイトもあります。たとえば、多くのデバイスがある共用コンピュータで使われる教育用ウェブ アプリケーションでは、ユーザー生成パーミッションが大量に蓄積されると、ユーザー エクスペリエンスの悪化につながります。 この問題を避けるには、最初のリクエストのパーミッションをデフォルトでセッション スコープにしたり、あまり使われないパーミッションに有効期限を設けたりといったユーザー エージェント側の対策と合わせて、サイト自体が不要になったユーザー生成パーミッションをクリーンアップできるようにする必要があります。
HIDDevice
forget()
mix-blend-mode プロパティで "plus-lighter" 値がサポートされます。これにより、ソースカラーとデスティネーション カラーにそれぞれのアルファを掛けたものが加算されます。この操作は、共通のピクセルを含む 2 つの要素をクロスフェードする場合に便利です。この場合に "plus-lighter" を使うと、ある要素の不透明度が 0 から 1 に変わる間に別の要素の不透明度は 1 から 0 に変わるので、共通ピクセルの外観は変化しないことが保証されます。
mix-blend-mode
"plus-lighter"
このヒントには、"WoW64-ness"（64 ビット Windows で実行される 32 ビットアプリ）を使うサイトが User-Agent 文字列を UA-CH に移行する際の下位互換性シムとしての用途しかありません。ブール値を返します。
WritableStream を使う際、すべての書き込み操作が終わるまで待機せずにシリアルポートをクローズできるようになります。ポートがピアデバイスからのフロー制御シグナルを待機している場合、無限にブロックされる可能性があります。WritableStream を中断する目的は、背後にあるシンクへのデータの書き込みを即座に停止することにあります。
WritableStream
wss スキームの WebSocket で、単にデフォルトの "http/1.1" プロトコルをオファーする新しい接続を開始する際に、TLS ALPN 拡張が含まれるようになります。現在のところ、HTTPS 接続とは異なり、この接続は ALPN をオファーしません。この変更により、Firefox と Safari と挙動が一致し、クロスプロトコル攻撃（ALPACA など）に対して強固になり、wss で False Start 最適化を利用できるようになります。また、HTTPS DNS レコードの処理もシンプルになります。
WebSocket
ウェブ デベロッパーが NDEFReader makeReadOnly() メソッドを使うと、Web NFC で NFC タグを永久的に読み取り専用にすることができます。
NDEFReader
makeReadOnly()
WebTransport で serverCertificateHashes オプションを使うと、ウェブ公開鍵基盤（PKI）は使わずに、期待される証明書ハッシュに対して証明書を認証することによって、WebTransport サーバーに接続します。
WebTransport
serverCertificateHashes
ウェブ デベロッパーは、この機能を使うことで、通常は公式に信頼された証明書を取得するのが難しい WebTransport サーバーに接続できます。たとえば、パブリックにルーティングできないホストや、暫定的な用途の仮想マシンなどです。
このバージョンの Chrome でサポートが終了するのは、この記事の最初に記載されている一件のみです。 現在サポートの終了作業が行われている機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
このたび、オープンソース ライブラリ Maps Compose の提供を開始することになりました。Maps Compose を使用すると、Maps SDK for Android を Jetpack Compose と一緒に使用できます。Compose を使ってアプリに地図を追加する場合、これまでは Compose とビューベースの MapView の間を橋渡しするために多くのビュー相互運用性コードを記述する必要がありましたが、今後はそういった手間を省くことができます。
Compose は、Android の最新の宣言型ネイティブ UI ツールキットです。UI の記述についての考え方を変えることで、前述の Compose は UI 開発を簡素化と高速化します。つまり、ユーザーはアプリの外観を指定するだけで済み、それ以外は Compose によって処理されます。これは Maps Compose についても同様です。従来よりはるかに少ないコードで Android アプリに地図を追加できるようになりました。
このブログでは、Maps Compose ライブラリをインストールする方法と、その機能の一部について説明します。
さっそく始めましょう。
Maps Compose ライブラリをインストールするには、アプリレベルの build.gradle ファイルに次の依存関係を追加します。
dependencies {
implementation "com.google.maps.android:maps-compose:1.0.0"
implementation "com.google.android.gms:play-services-maps:18.0.2"
上記の新しい依存関係をアプリに追加したら、Android Studio でプロジェクトを再構築して、変更を同期します。また、Cloud のコンソール経由で、API キーを作成してアプリに追加する必要があります。詳しくは、「API キーを使用する」をご覧ください。
Maps Compose を依存関係としてアプリに追加し、API キーを追加したら、アプリでコンポーズ可能な関数 GoogleMap を使用できるようになります。Compose を初めて使用する場合、コンポーズ可能な関数は基本的に、Compose で構築されたアプリケーションの UI ビルディング ブロックとなります。
アプリに地図を追加する最も簡単な例を次に示します。
val singapore = LatLng(1.35, 103.87)
val cameraPositionState = rememberCameraPositionState {
position = CameraPosition.fromLatLngZoom(singapore, 10f)
GoogleMap(
modifier = Modifier.fillMaxSize(),
cameraPositionState = cameraPositionState
) {
Marker(
position = singapore,
title = "Singapore",
snippet = "Marker in Singapore"
)
上記のスニペットでは、地図が画面内で最大化され、ビューは camera パラーメータでシンガポールの中心に配置されます。googleMapOptionsFactory で提供されるラムダ式は、地図の初期化に使用される GoogleMapOptions オブジェクトを構築します。最後に、地図のコンテンツでコンポーズ可能な関数 Marker を呼び出すと、地図にマーカーが追加されます。
この例を、ビューを使って地図を追加する例と比較するには、Maps SDK for Android のドキュメント ページにある既存のクイックスタートをご覧ください。Compose の場合は必要なコードがはるかに少なく、地図のライフサイクルを考慮する必要がないことがわかります。
地図上でプロパティを設定するには、MapProperties オブジェクト、または UI 関連のプロパティ用の MapUiSettings オブジェクトを使用します。これらの状態を管理することで、地図上で再構成をトリガーする際にに利用できます。
次のスニペットでは、地図上のズーム コントロールを切り替えるために、Compose の Material コンポーネントであるスイッチがビューに追加されています。
var uiSettings by remember { mutableStateOf(MapUiSettings()) }
var properties by remember {
mutableStateOf(MapProperties(mapType = MapType.SATELLITE))
Box(Modifier.fillMaxSize()) {
modifier = Modifier.matchParentSize(),
properties = properties,
uiSettings = uiSettings
Switch(
checked = uiSettings.zoomControlsEnabled,
onCheckedChange = {
uiSettings = uiSettings.copy(zoomControlsEnabled = it)
マーカーやポリゴンなどのオブジェクトを地図上に描画するには、コンテンツ ラムダをコンポーズ可能な関数 GoogleMap に提供します。
たとえば次のスニペットでは、コンポーズ可能な Marker を使用して、シンガポールを中心とする地図にマーカーを追加しています。
modifier = Modifier.fillMaxSize()
地図のビュー内での位置を制御するには、CameraPositionState を使用します。このオブジェクトは、地図のカメラ位置の変更を管理するために使用できます。また、カメラ更新コマンドを地図に送信するために使用することもできます。
たとえば次のスニペットでは、ボタンがクリックされると、地図のカメラをシドニーに移動する方法を表しています。
val sydney = LatLng(-33.852, 151.211)
Button(
onClick = {
cameraPositionState.move(CameraUpdateFactory.newLatLng(sydney))
Text(text = "Animate camera to Sydney")
Google マップにおける Jetpack Compose のサポートを改善することで、より迅速かつ簡単にアプリに地図を追加できるようになりました。すぐに使用したい場合は、GitHub リポジトリにある付属のサンプルアプリを利用してご確認ください。Jetpack Compose をこれまで利用したことがない場合は、Jetpack Compose の公式ドキュメントに詳細の記載がありますのでご覧ください。
今後ともどうぞよろしくお願いいたします。
Google は、ユーザーがログインして、Google アカウント データをサードパーティ アプリケーションと共有できる安全な方法を提供するため、常に努力しています。その理念に基づき、OAuth インタラクション中のフィッシングやアプリのなりすましによる攻撃に対する一連の保護機能をロールアウトします。
Google のログインと認可のフローは、Google OAuth プラットフォームを利用しています。アプリ デベロッパーがサポート対象の OAuth フローを組み込めるように、ここ数年の間にたくさんの方法を開発し、サポートしています。今回は、オンラインのユーザーの安全を維持するという目的のもと、2 つのレガシーフローのサポートを終了します。デベロッパーの皆さんは、保護が強化されている別の実装方式に移行する必要があります。
スムーズな移行を実現し、サービスの中断が起きないようにするため、十分な実装の時間を提供します。以下の期日に間に合うように移行をお願いいたします。このロールアウトについては、メールでさらに最新情報をお知らせする予定です。Google API コンソールのプロジェクト設定で、サポート メールアドレスが最新になっていることをご確認ください。
ループバック IP アドレスフローは、中間者攻撃に脆弱です。この攻撃が行われると、悪意のあるアプリが一部のオペレーティング システムで同じループバック インターフェースにアクセスし、OAuth レスポンスを傍受して認可コードを入手できる可能性があります。そこで、iOS、Android、Chrome アプリの OAuth クライアント タイプでこのフローを禁止することにより、この脅威ベクターを取り除きます。既存のクライアントは、安全性が高い実装方式に移行できます。2022 年 3 月 14 日以降、新規クライアントはこのフローを使えなくなります。
アプリのコードか、外向きのネットワーク呼び出し（アプリで OAuth ライブラリを使っている場合）を調べ、アプリで行っている Google OAuth 認可リクエストの “redirect_uri” パラメータに次の値が含まれているかどうかを確認してください。
redirect_uri=http://127.0.0.1:port または http://[::1]:port">http://[::1]:port または
http://localhost:port
アプリでループバック IP アドレス方式を使っている場合は、デフォルトで安全性が高い別の方式に移行する必要があります。移行する別の方式として、以下を検討してください。
iOS クライアント : Google Sign-In for iOS SDK Android クライアント : Google Sign-In for Android SDK Chrome クライアント : Chrome Identity API
2022 年 3 月 14 日 - 新規の OAuth 利用で、ループバック IP アドレスフローがブロックされます。 2022 年 8 月 1 日 - 期日の 1 か月前より、非準拠 OAuth リクエストを使うと、ユーザーに警告メッセージが表示される場合があります。 2022 年 8 月 31 日 - 既存クライアントに対して、ループバック IP アドレスフローがブロックされます。
OAuth のアウトオブバンド（OOB）は、レガシーフローです。ウェブアプリの場合、ユーザーが OAuth 同意リクエストを承認した後、リダイレクト URI で資格情報を受け取ることができます。このフローは、リダイレクト URI を持たないネイティブ クライアントをサポートするために開発されました。OOB フローにはリモート フィッシングのリスクがあるので、クライアントはこの脆弱性に対する保護策として、別の方式に移行する必要があります。2022 年 2 月 28 日以降、新規クライアントはこのフローを使えなくなります。
redirect_uri=urn:ietf:wg:oauth:2.0:oob または urn:ietf:wg:oauth:2.0:oob:auto または oob
アプリで OOB 方式を使っている場合は、デフォルトで安全性が高い別の方式に移行する必要があります。移行する別の方式として、以下を検討してください。
iOS クライアント : Google Sign-In for iOS SDK Android クライアント : Google Sign-In for Android SDK Chrome クライアント : Chrome Identity API PC クライアント : デスクトップ アプリ用の OAuth 2.0
2022 年 2 月 28 日 - 新規の OAuth 利用で、OOB フローがブロックされます。 2022 年 9 月 5 日 - 非準拠 OAuth リクエストを使うと、ユーザーに警告メッセージが表示される場合があります。 2022 年 10 月 3 日 - 既存クライアントで OOB フローが非推奨となります。
前述の OAuth 方式がブロックされる 1 か月前から、非準拠リクエストを使うユーザーに対して警告メッセージが表示される場合があります。このメッセージは、近日中にアプリがブロックされる可能性があることをユーザーに伝えるものになります。Google API Console の OAuth 同意画面で登録されたサポートメールも表示されます。
【ユーザーに表示される警告の例】
デベロッパーは、ユーザーに表示される警告メッセージを確認したうえで、認可呼び出しの際に次のようにしてクエリ パラメータを渡すことで、メッセージを抑制することができます。
Google の OAuth 2.0 認可エンドポイントにリクエストを送るアプリのコードを開きます。 期日を値としたパラメータを追加します。 OOB の場合 : ack_oob_shutdown パラメータを追加し、値として期日 2022-10-03 を指定します。例 : ack_oob_shutdown=2022-10-03 ループバック IP アドレスの場合 : ack_loopback_shutdown パラメータを追加し、値として期日 2022-08-31 を指定します。例 : ack_loopback_shutdown=2022-08-31
ack_oob_shutdown
ack_oob_shutdown=2022-10-03
ack_loopback_shutdown
ack_loopback_shutdown=2022-08-31
期日までに基準を満たすようにアップデートされないアプリでは、認可リクエストがブロックされ、無効なリクエストを示すエラー画面がユーザーに表示される場合があります（次に例を示します）。
【ユーザーに表示されるエラーの例】
