Google は、2022 年 5 月 11 日 から 12 日にかけ、オンラインにて Google I/O 2022 を開催しました。

例年、Google Developer Groups(GDG)やその他の IT コミュニティの皆さんが、I/O Extended というイベントを各地で開催しています。今年は、Google I/O 2022 で発表のあったセッションの解説や振り返りなど、プロダクト別のさまざまな情報を共有する報告会がオンラインにて開催予定です。

開催される予定のイベントの概要は下記のとおりです。イベントごとにお申し込み方法が異なりますので、参加をご希望の方は、各リンクから詳細をご覧ください。

※リンクがない・開催日時が TBC となっている箇所は、イベント情報が確定次第、随時更新されますので今しばらくお待ちください。


イベント概要


GDG およびコミュニティ主催

Google は、2022 年 5 月 11 日 から 12 日にかけ、オンラインにて Google I/O 2022 を開催しました。

例年、Google Developer Groups(GDG)やその他の IT コミュニティの皆さんが、I/O Extended というイベントを各地で開催しています。今年は、Google I/O 2022 で発表のあったセッションの解説や振り返りなど、プロダクト別のさまざまな情報を共有する報告会がオンラインにて開催予定です。

開催される予定のイベントの概要は下記のとおりです。イベントごとにお申し込み方法が異なりますので、参加をご希望の方は、各リンクから詳細をご覧ください。

※リンクがない・開催日時が TBC となっている箇所は、イベント情報が確定次第、随時更新されますので今しばらくお待ちください。


イベント概要


GDG およびコミュニティ主催

I/O Extended Japan 2022

日時 : 2022 年 6 月 5 日(日)15:00 ~ 18:00

参加方法 : YouTube Live

参加費 : 無料

主催 : GDG 四国、岡山、京都、九州、名古屋、東京 

※上記 6 チャプターが本イベントを共催いたします 

 

DroidKaigi: Weekend Chat Vol.22~Vol.25 I/O、今年の新技術

日時 : 2022 年 5 月 27 日(金)20:00 ~ 21:30

参加方法 : YouTube Live

参加費 : 無料

主催 : DroidKaigi 


Android Bazaar and Conference 2022 Spring

日時 : 2022 年 5 月 28 日(土)10:30 ~ 16:30

参加方法 : YouTube Live(川崎市産業振興会館から YouTube 配信)

参加費 : 無料

主催 : 特定非営利活動法人 日本 Android の会 / 日本 Android の会 

共催・後援 : 公益財団法人 川崎市産業振興財団 

 

  

Google 主催

Android Roadshow Day 1 (オンライン)

日時 : 2022 年 6 月 15 日(水)10:00 ~ 12:00
参加費 : 無料 
参加方法 : ご参加登録はこちら

* ご参加(ご視聴)にはご登録が必要です



企業主催



※ リンクがない箇所は、情報が入り次第更新していきます。


※ I/O 報告会を開催したいと考えており、本記事に情報を追加してほしい、というコミュニティオーガナイザーの方がいらっしゃいましたら、こちらのフォームから情報をお寄せください。


皆さまのご参加を心よりお待ちしております。



Posted by Takuo Suzuki - Developer Relations Team

この記事はシニアスタッフ ソフトウェア エンジニア、Mike Procopio による Google Developers Blog の記事 "Announcing the Apps Script connector for AppSheet: Automate workflows for Google Workspace" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この度、Apps Script connector for AppSheet をリリースしました。これにより、ノーコードの AppSheet アプリから Apps Script コードの関数を呼び出せるようになります。AppSheet アプリから Apps Script の機能にアクセスできるようになるので、AppSheet アプリでできることが大幅に増えます。たとえば、AppSheet アプリと Google Workspace を組み合わせて、ドライブ、ドキュメント、スプレッドシート、Admin SDK などの Workspace API を利用すれば、Apps Script を使ってワークフローを自動化できます。また、YouTube、Google アナリティクス、BigQuery などのその他の Google サービスと組み合わせることもできます。

この記事はシニアスタッフ ソフトウェア エンジニア、Mike Procopio による Google Developers Blog の記事 "Announcing the Apps Script connector for AppSheet: Automate workflows for Google Workspace" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この度、Apps Script connector for AppSheet をリリースしました。これにより、ノーコードの AppSheet アプリから Apps Script コードの関数を呼び出せるようになります。AppSheet アプリから Apps Script の機能にアクセスできるようになるので、AppSheet アプリでできることが大幅に増えます。たとえば、AppSheet アプリと Google Workspace を組み合わせて、ドライブ、ドキュメント、スプレッドシート、Admin SDK などの Workspace API を利用すれば、Apps Script を使ってワークフローを自動化できます。また、YouTube、Google アナリティクス、BigQuery などのその他の Google サービスと組み合わせることもできます。

Google AppSheet

AppSheet は、カスタムのアプリやワークフローをノーコードで開発し、ビジネス プロセスを自動化するための Google のプラットフォームです。これを使うと、コードを書くことなく、エンドツーエンドのアプリを開発してデプロイし、自動化を行うことができます。


Google Appsheet でアプリの定義を編集する


ノーコードの概要

Apps Script コネクタ機能の説明に入る前に、 ノーコードの意味について考えてみましょう。AppSheet などのノーコード型プラットフォームを利用すると、 シチズン デベロッパー がウェブベースのユーザー インターフェースを使い、データの解析を通して、短時間で自動的にアプリを開発できます。通常は、データソースとして、Google スプレッドシート、MySQL、Salesforce、その他のデータベースを利用します。こういったアプリの作成には、従来のソフトウェア エンジニアリングの経験は不要です。そのため、幅広いスキルを持つビジネス テクノロジストやアナリストがアプリを開発して、業務を簡易化したり、効率化したりできます。

AppSheet のようなノーコード型プラットフォームでは、コードを書いてアプリを動かすのではなく、ウェブベースのエディタ UI でアプリの動作を定義します。たとえば、アプリはどう動作すべきか、どんなデータソースを使うのか、データにはどんな意味があるのか、ユーザーにどんな UI を表示するのか、どんなイベントを管理するのか、イベントの発生時にどんなアクションを実行するのかなどを指定します。そのアプリは、UI を含むエンドツーエンドのデータ駆動型アプリとして本番環境にデプロイします。これはすべて、実際のコードを「書く」ことなく実現できます。通常のウェブアプリやネイティブ アプリにしか見えないので、エンドユーザーが違いを意識することはありません。


ノーコードが効果的な理由

ノーコード型プラットフォームは、大部分のアプリで実際に効果的に機能しています。その理由は、多くのアプリの機能が非常に似かよっているからです。特に、社内のビジネス プロセスを扱うアプリはよく似ています。このようなアプリには、多くの共通点があります。データを格納するデータソース、データ「レコード」という概念、データの収集や編集を行う UI やフォーム、ユーザーに固有なデータ表示画面、データ変換を定義する式、データが変更されたときに実行されるアクション、管理者による権限の制御などです。

例として、社員の出張申請書を作成したり承認したりするアプリを考えてみましょう。このアプリには、経費報告書を作成したり承認したりするアプリとの共通点がたくさんあります。どちらのアプリでも、社員がレコードを作成し、そのレコードに対して審査や追記が行われ、変更が発生するとユーザーに通知され、最終的に申請は完了してクローズされます。同じように、社員に貸与されるコンピュータ機器を追跡する社内アプリとの間にも、多くの共通点があります。たとえば、汎用的な在庫追跡、フルフィルメント、注文システムなどです。

ノーコード型プラットフォームの課題は、常に表現力と高レベルの抽象化とのバランスを取る点にあります。幸いにも、データ、データ ライフサイクル、プロセスで想定される中核部分をしっかりと理解してしまえば、ビジネス プロセスはほぼそれに従います。この領域でノーコード型プラットフォームが効果的なのは、そのためです。しかし、アプリの要件が、ノーコード型プラットフォームでできること以上に広がることもあるかもしれません。新しい Apps Script コネクタは、ノーコード型アプリの表現力(機能)を大幅に高めます。そのため、要件やビジネス プロセスが進化しても、それに対応してアプリを強化することができます。


Google Workspace と Workspace API と Apps Script

Google Workspace は、Google のクラウドベース生産性スイートです。これを使うと、あらゆる規模のチームが連携して制作や共同作業をすることができます。皆さんにとって、Gmail、カレンダー、ドライブ、ドキュメント、スプレッドシート、スライドなどのたくさんのアプリはおなじみのものでしょう。各アプリには充実したデベロッパー API も搭載されており、アプリのデベロッパーがプログラムから機能を利用できるようになっています。たとえば、ドライブ API を使うと、ユーザーがファイルをアップロードしたりダウンロードしたりするコードを作成できます。Gmail API ならメッセージ機能を統合でき、Google ドキュメント API ならスクリプトから Google ドキュメントを編集できます。


Chat、Gmail、ドキュメントのプレビューを組み込んだ Google Workspace を使う


Apps Scriptローコード 型プラットフォームで、これを使うと、Google Workspace の統合、自動化、拡張を行うビジネス ソリューションをすばやく簡単に開発できます。使いやすい高レベルな API の「ラッパー」が提供されているので、Google Workspace や外部サービスとのカスタム統合が可能です。さらに、Apps Script を使うと、YouTube、Google アナリティクス、BigQuery などの Google のサービスを組み込むこともできます。これは充実したプラットフォームであり、スクリプトを書くことで、複雑なビジネス ロジックやマクロを実装したり、サードパーティ ベンダーのデータ交換システムや機械学習分類サービスなどの外部サービスを呼び出したりできます。


Google Apps Script コードエディタでスクリプトを編集する


Apps Script connector for AppSheet の紹介

今週リリースされた Apps Script connector for AppSheet が、AppSheet、Apps Script、Google Workspace、そして Google Workspace の多くのデベロッパー API のすべてをつなぎます。これにより、Apps Script の関数を呼び出してデータを渡せるようになるので、AppSheet を使ったノーコード型アプリでできることが大幅に広がります。これは、 ノーコード (AppSheet)と ローコード (Apps Script)の橋渡しをする機能と考えることもできるでしょう。重要なことは、Apps Script スクリプトを書く人は、スクリプトを呼び出すノーコード型 AppSheet アプリの作成者と同じでなくてもよい点です(ほとんどの場合は、違う人でしょう)。

Apps Script デベロッパーから見れば、この機能によって、いくつかの重要な可能性が開かれることになります。AppSheet の特に大きなメリットは、UI を含む実際のエンドツーエンド アプリ(フロントエンド)を簡単にデプロイできることです。既存の Apps Script コードを呼び出せる新機能を使えるので、ノーコード型 AppSheet アプリを作成したり、それを使って既存のフロントエンドを置き換えたりするという選択肢がゲームチェンジャーになる可能性があります。


Apps Script connector for AppSheet の使用

AppSheet でこれを設定するのは簡単で、スクリプト自体を除けば、他にコードは必要ありません。基本的な考え方としては、アプリの作成者が AppSheet の「タスク」を設定して、呼び出したい Apps Script スクリプトを選びます。タスクとは、AppSheet Automation がトリガーされたときに実行されるアクションを指します。

通常、このようなアクションは、AppSheet のデータソースの特定のデータ行に対して実行されます。たとえば、アプリのエンドユーザーが新しいデータレコードを作成したときに、自動処理をトリガーすることができます。また、Apps Script 関数のパラメータに渡す値は、アクティブなデータレコードの値に基づいて指定することもできます。


Google AppSheet で自動処理タスクを編集する


これは、次の 5 つの手順で設定できます。

  1. AppSheet で [Automation] 画面を選択し、新規 ボット を作成して、管理するイベントを関連付けます。最後に、 タスク[Call a script] オプションを選択します。

    AppSheet の自動処理タスクを設定し、Apps Script 関数を呼び出す

  2. 続いて、[Apps Script Project] で呼び出すスクリプトを選択します。このコードは、Apps Script エディタを使って作成し、アプリ作成者の Google ドライブに格納されます(他のユーザーが共有したものでも構いません)。

    呼び出す Apps Script プロジェクトを Google ドライブから選択する

  3. プロジェクトを選択すると、Apps Script プロジェクト内の呼び出し可能な関数の一覧が [Function name] ドロップダウンに表示されます。ここで、AppSheet から呼び出す関数を選択します。
  4. 呼び出す関数を選択すると、パラメータ(関数を呼び出すときに渡す追加データ)の一覧が表示されます。

    logTravelRequestUpdate() Apps Script 関数に渡すパラメータが表示される

  5. 関数の各パラメータについて、AppSheet の Expression Assistant を使って、自動処理を呼び出すときにパラメータとして渡す値を指定します。式では、単なる AppSheet アプリのデータソース列を使うことも、それよりも複雑な関数や複数の列の計算結果を使うこともできます。

  6. AppSheet の Expression Assistant を使って Apps Script 関数のパラメータに渡す値を選択する

最後に、AppSheet エディタでタスクを保存します。[Save] ボタンを使用してください。

これで完了です。自動処理がトリガーされると(ユーザーが新しいデータ行を追加したときなど)、AppSheet の自動処理エンジンが指定した Apps Script 関数を呼び出します。その際に、式を評価した値が関数の引数として渡されます。関数呼び出しの詳細は、AppSheet の Automation Monitor から確認できます。


サンプルコード

次に簡単なサンプルを示します。上のスクリーンショットで紹介した Travel Request Tool AppSheet アプリに基づくもので、実際に試してみることができます(下のサンプル スクリプトのセクションで、別の例も紹介します)。次のコードは、社員の出張申請書の詳細情報を、「監査ログ」を模した Google ドキュメントに書き込む Apps Script 関数です。ここでは、Apps Script で利用できる DocumentApp ラッパー ライブラリを通して Google ドキュメント API を使っています。


 TravelRequestAuditLogger.gs 

function logTravelRequestUpdate(RequestDate, Requestor, Origin, ...) {
  var TRAVEL_REQUEST_AUDIT_LOG_DOCID = 'your_docid_here'
  var doc = DocumentApp.openById(TRAVEL_REQUEST_AUDIT_LOG_DOCID)
  var body = doc.getBody();

  var dataParagraph = body.insertParagraph(0, '');
  var headerText = dataParagraph.appendText('*** NEW AUDIT LOG ENTRY ***\n');
  headerText.setBold(true);

  // Add in the audit log entry metadata.
  dataParagraph.appendText('New Travel Request Tool audit log entry...\n');

  dataParagraph.appendText('RequestDate: ' + RequestDate + '\n');
  dataParagraph.appendText('Requestor: ' + Requestor + '\n');
  dataParagraph.appendText('Origin: ' + Origin + '\n');

  // ... additional values here to append to Google Doc
}

この関数が呼び出されると(新しい出張申請書が作成されて AppSheet の自動処理から呼び出される場合など)、AppSheet から渡された値に応じたテキストが Google ドキュメントに追加されます。ドキュメントが更新されると、次のようになります。


Apps Script の Google ドキュメント API と AppSheet から渡された値を使って作成した Google ドキュメントの出力例


スタートガイド

すぐに使ってみたい場合やコミュニティのサポートを受けたい場合に役立つリソースの一覧を作成しています。


サンプル スクリプト

この機能を使ってみる際に役立つ 3 つのサンプル スクリプトを紹介します。

サンプル Google Workspace プロジェクト - ドキュメント、スプレッドシート、スライドの作成とメールの送信

カレンダー イベントの作成 - カスタマイズ可能なカレンダー イベントの作成

インタラクティブ Chat メッセージの送信 - リンクを開くメッセージやイメージを表示するメッセージを Google Chat で送信

この機能を発表できたことをとてもうれしく思っています。皆さんが Google Workspace で作るものを見るのが楽しみです。今後も AppSheet や Google Workspace プラットフォームのお知らせを受け取りたい方は、デベロッパー ニュースレターへの登録をお願いします


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google オープンソース セキュリティ チーム(GOSST)、Asra Ali、Laurent Simon による Google Online Security Blog の記事 "Improving software supply chain security with tamper-proof builds" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
この記事は Google オープンソース セキュリティ チーム(GOSST)、Asra Ali、Laurent Simon による Google Online Security Blog の記事 "Improving software supply chain security with tamper-proof builds" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

最近、世界のオープンソース ユーザーを震撼させるソフトウェア攻撃が話題になっていますが、そのような攻撃の多くは、サプライ チェーンの不完全性に起因しています。つまり、ビルドサーバーに侵入した攻撃者は、悪意のあるソースファイルを使って侵害したビルド プラットフォームに悪意のあるアーティファクトを注入し、信頼されたビルダーをバイパスして悪意のあるアーティファクトをアップロードします

こういった攻撃は、配信されるアーティファクトが想定されるソフトウェアの制作元によるものでないことを検知する仕組みがあれば、防ぐことができたはずです。しかし、これまでは、ソフトウェア アーティファクトがいつ、どこで、どのように生成されたかがわかる検証可能な情報(来歴と呼ばれる情報)を作成するのは困難でした。この情報があれば、ユーザーはアーティファクトをソースまでさかのぼって検証したり、使用するソフトウェアについてのリスクベースのポリシーを作成したりできます。現在、来歴の生成は広くサポートされてはおらず、既存のソリューションでは、ビルドプロセスを Tekton Chains などのサービスに移行しなければならない場合もあります。

このブログ投稿では、偽造できない来歴を生成する新手法について説明します。この手法では、分離に GitHub Actions ワークフローを、正当性の証明に Sigstore の署名ツールを利用します。この手法を使うと、GitHub ランナーを利用するプロジェクトで SLSA 3(4 つある SLSA「レベル」の 3 つ目で、数字が大きいほど信頼性が高い)を実現でき、アーティファクトが正当で信頼できるものであることをユーザーに対して証明できます。

来歴

SLSA(「Supply-chain Levels for Software Artifacts」)は、ソフトウェア アーティファクトのサプライ チェーン レベルを表すフレームワークで、開発サイクル全体でプロジェクトの完全性を維持するためのものです。ユーザーは、リリースされたソフトウェアの最終製品をソースまでさかのぼることができます。高い SLSA レベルを実現することで、アーティファクトがデベロッパーの意図したものであることを示す信頼性が向上します。

このブログ投稿では、ビルドの来歴に注目します。ビルドの来歴は、ユーザーにとって重要なビルド情報を提供します。たとえば、誰がリリース プロセスを実行したのか、このビルド アーティファクトは悪意のある改ざんに対して保護されているか、といった内容です。ソースコードの保護方法を表すソースの来歴については、今後のブログ投稿で触れたいと思いますので、ご期待ください。

偽造できないビルド来歴を生成する Go プロトタイプ

改ざんできないビルドの証拠を作成し、ユーザーがそれを検証できるようにするには、以下のことが必要です。
  1. ビルドプロセスから来歴生成処理を分離する
  2. ワークフローに干渉するメンテナから分離する
  3. 来歴の検証時にビルダーの身元を確認できる仕組みを提供する
最初の 2 つのポイントに記述されている分離を行うことで、ユーザーは来歴が忠実に記録されたものであるという信頼を得ることができます。これが保証されたエンティティを、信頼されたビルダーと呼びます。

私たちの Go プロトタイプは、3 つの課題すべてを解決します。加えて、ビルドは信頼されたビルダーの中で行われます。これは、ビルドで SLSA 3 の一時性要件と分離要件が達成されていることを示す保証になります。

機能の仕組み

信頼されたビルダーは、次の手順で作成します。信頼されたビルダーは、ビルドとメンテナの干渉から分離された環境で来歴を生成するために必要になります。

ステップ 1: GitHub ランナーで再利用可能なワークフローを作成する

GitHub の再利用可能なワークフローを利用すると、メンテナの呼び出し元ワークフローとビルドプロセスの両方から分離した仕組みを実現できます。このワークフローで Github Actions を使い、それぞれのジョブについて仮想マシン(VM)の新しいインスタンス(これをランナーと呼びます)を作成します。別の VM を作成することで、信頼されたビルダーに必要な分離を実現します。その結果、複数の異なる VM によってプロジェクトがコンパイルされ、SLSA の来歴が生成されて署名されます(下の図を参照)。

GitHub にホストされたランナーでワークフローを実行することで、実行するコードが実際に意図したワークフローであることが保証されます。セルフホストのランナーでは、この点は保証されません。このプロトタイプでは、ワークフローで定義された厳密なコードを実行するために、GitHub を利用しています。

再利用可能なワークフローでは、メンテナから干渉を受ける可能性もなくなります。この仕組みがない場合、メンテナがビルダーに干渉するようなワークフローを定義する可能性があります。再利用可能なワークフローを扱う唯一の方法は、呼び出し側のワークフローに公開される入力パラメータを使うことです。そのため、メンテナが環境変数ステップサービスデフォルトによって情報を改変することはできなくなります。

この手法では、いずれかのジョブ(ビルドステップなど)が、別のジョブ(来歴ステップ)によって使われる他のアーティファクトを改ざんする可能性をなくすため、信頼されたチャンネルを使ってデータの完全性を維持しています。ジョブ出力を使ってハッシュを送信し(サイズ制限があるため)、そのハッシュを使って信頼されていないアーティファクト レジストリを通して受け取ったバイナリを検証します。

ステップ 2: OpenID Connect(OIDC)を使って外部サービス(Sigstore)に対してワークフローの身元を証明する

OpenID Connect(OIDC)は、ウェブの ID プロバイダ(Google など)で広く使われている標準で、サードパーティに対してユーザーの身元を証明します。現在の GitHub のワークフローは、OIDC をサポートしています。ワークフローが実行されるたびに、ランナーは GitHub の OIDC プロバイダからの一意な JWT トークンを生成できます。このトークンには、ワークフローの身元に関する検証可能な情報が含まれています。たとえば、呼び出し元リポジトリ、コミットのハッシュ、トリガー、現在の(再利用可能な)ワークフローのパスと参照などです。

ワークフローは、OIDC を使って Sigstore の Fulcio ルート認証局に対して自身の身元を証明します。Sigstore は、外部の検証サービスとして振る舞います。Fulcio は、ランナーで生成された一時的な署名鍵を証明する短命の証明書に署名し、それをワークロードの身元と結びつけます。来歴への署名記録は、Sigstore の透明なログ管理サービスである Rekor で保持されます。この署名証明書を信頼性アンカーとして使うと、ユーザーが来歴の正当性や来歴が偽造できないことを検証できます。来歴は、信頼されたビルダーの中で作成されている必要があります。

検証

ユーザーは、以下の手順でアーティファクトと署名された来歴を検証できます。
  1. 対応する Rekor ログエントリを検索し、署名を検証する
  2. 署名証明書から信頼されたビルダーを抽出し、その身元を確認する
  3. 来歴情報が想定されるソースとビルドと一致することを確認する
詳しくは、公式リポジトリの実例をご覧ください。

ユーザーは、以上の手順を経ることで、信頼されたビルダーによって来歴で示されたコミットのハッシュから生成されたバイナリであるという保証を得ることができます。来歴に含まれる情報が偽造できないことは確かなので、ビルドの「レシピ」を信頼することができ、ソースまでさかのぼってアーティファクトの正当性を追跡することもできます。

補足 : 鍵なし署名

この手法には、追加のメリットがあります。それは、メンテナが署名に使う暗号鍵の管理や配布をする必要がないため、鍵の管理という悪名高い難題を回避できることです。OIDC プロトコルでは、ハードコードされた長期間有効なシークレットを GitHub に格納する必要はないため、不適切な鍵管理によって SLSA の来歴が無効になるという問題が起きる可能性はありません。バイナリ アーティファクトがしかるべき来歴を生成した信頼されたビルダーでビルドされたことは、OIDC を利用するだけで検証できます。

次のステップ

SLSA フレームワークを活用すれば、大規模環境でソフトウェアのサプライ チェーンの完全性を確実に保証できることが実証されています。このプロトタイプから、人気の CI/CD システムの最新機能やオープンソースのツールを使えば、考えられている以上に簡単に高い SLSA レベルを実現できることがわかります。改ざん防止(SLSA 3 以上)に対応したビルドサービスの採用が増えれば、オープンソース エコシステムはより充実し、現在のサプライ チェーンにおける簡単に悪用できる脆弱性を 1 つクローズすることにつながります。

ぜひこの機能を試し、採用することをおすすめします。また、プロジェクトへの改善要望も歓迎します。フィードバック、コメント、提案は、slsa-github-generator-go と slsa-verifier のプロジェクト リポジトリからお送りください。これから数週間のうちに、v1 を正式リリースする予定です。

今後の投稿では、安全なリポジトリ設定を証明する偽造できないソース来歴を追加する方法や、他のビルド ツールチェーンやパッケージ マネージャなどで同じ手法を使う方法について紹介したいと思います。お楽しみに!


Reviewed by Eiji Kitamura - Developer Relations Team

この記事はテクニカル ライター、Peter Jacobsen による Google Developers Blog の記事 "Use OAuth 2.0 tokens on your website, app, and servers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
この記事はテクニカル ライター、Peter Jacobsen による Google Developers Blog の記事 "Use OAuth 2.0 tokens on your website, app, and servers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

OAuth 2.0 は、インターネットでトークンベースの認可を行うためのオープンな標準認可フレームワークです。OAuth 2.0 のアクセス トークンは、OAuth 2.0 クライアントがリソース サーバーにリクエストをする際に使用する文字列で、ユーザー ID などの情報を OAuth 2.0 クライアントから隠蔽します。リソース サーバーにリクエストをする際には、アクセス トークンのみを使用します。

オフライン リフレッシュ トークン

アクセス トークンは一定時間で有効期限が切れ、関連する API リクエストに利用できない無効な認証情報になります。トークンに関連付けられたスコープに対してオフライン アクセスをリクエストする場合、アクセス トークンを更新することができます。このとき、ユーザーにパーミッションを要求するプロンプトを表示する必要はなく、ユーザーがそこにいる必要もありません。

リフレッシュ トークンの有効期限は、アクセス トークンよりも少し長くするというのがベスト プラクティスです。たとえば、アクセス トークンの有効期限を 30 分に設定する場合、リフレッシュ トークンの有効期限は 24 時間またはそれ以上にします。

詳しくは、アクセス トークンの更新(オフライン アクセス)をご覧ください。

オンライン アクセス

アプリによっては、短い間隔でユーザーを再認証するリクエストをする可能性があります。その場合は、リフレッシュ トークンではなくアクセス トークンのみを使います。こういったアプリは、リフレッシュ トークンを使ったオフライン アクセスと見なされるアプリとは違い、オンライン アクセスとなります。

詳しくは、アクセス トークンの更新(オフライン アクセス)トークンを更新するをご覧ください。

JSON Web Token(JWT)とトークンの有効期限

Cloud IoT の認証をするには、各デバイスで JWT を作成する必要があります。JWT は、デバイスと MQTT または HTTP ブリッジとの間の、短時間だけ有効な認証に使われます。

JWT は、ヘッダー部、ペイロード部、署名部という 3 つのセクションで構成され、ペイロード部には一連のクレームが含まれています。ヘッダー部とペイロード部は、JSON オブジェクトを UTF-8 のバイト列にシリアライズして Base64 URL エンコーディングでエンコードしたものです。

JWT のヘッダー部、ペイロード部、署名部は、ピリオドで連結されます。その結果、通常の JWT は次のような形式になります。

{Base64url encoded header}.{Base64url encoded payload}.{Base64url encoded signature}

詳細については、JSON Web Token(JWT)の使用JWT トークンの有効期限を管理するをご覧ください。

一般的なトークンの有効期限のパラダイム

トークンの有効期限の管理には、さまざまなポリシーや戦略を利用できます。以下のような方式が考えられます。

  • HTTP レスポンスをモニタリングして 401 HTTP レスポンスを検出し、適切に対応する
  • リソース サーバーに HTTP リクエストを行う前に、先回りでトークンの有効期限を確認し、有効性を判断する
  • リクエストの際に有効なトークンが期限切れして 401 HTTP レスポンスが発生する可能性がある場合に、上記 2 つの戦略を組み合わせて期限切れに対処する

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 102: Window Controls Overlay, a Host of Finished Origin Trials, PWAs as File Handlers and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 4 月 28 日の時点で Chrome 102 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

この記事は Chromium Blog の記事 "Chrome 102: Window Controls Overlay, a Host of Finished Origin Trials, PWAs as File Handlers and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 4 月 28 日の時点で Chrome 102 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

インストールした PC ウェブアプリ向けのウィンドウ コントロール オーバーレイ

ウィンドウ コントロール オーバーレイは、ウィンドウ全体を覆うようにアプリのクライアント領域を拡張します。この領域には、タイトルバー、ウィンドウのコントロール ボタン(閉じる、最大化 / 復元、最小化)も含まれます。ウェブアプリのデベロッパーは、ウィンドウ コントロール オーバーレイを除くウィンドウ全体の描画と入力ハンドリングをする必要があります。この機能を使うと、デベロッパーはインストールされた PC ウェブアプリをオペレーティング システムのアプリのように見せることができます。詳しくは、PWA のタイトルバーのウィンドウ コントロール オーバーレイをカスタマイズするをご覧ください。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。オリジン トライアルとして新機能を試して、ユーザビリティ、実用性、有効性についてのフィードバックをウェブ標準コミュニティに提供することができます。以下の項目を含めて、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。 

キャプチャ ハンドル

新しいメカニズムにより、アプリケーションが動画キャプチャをする別のアプリケーションに情報を公開できるようにします。これにより、キャプチャするアプリケーションとキャプチャされるアプリケーションを連携できるようになります。たとえば、プレゼンテーションの動画をキャプチャするビデオ会議アプリケーションで、ビデオ会議タブにユーザー向けのコントロールを表示して、キャプチャするタブのプレゼンテーションを操作することができます。

ネットワーク状態のパーティショニング

サイド チャンネルを使用したクロスサイト トラッキングを防ぐため、ネットワーク状態がネットワーク パーティション キーでパーティショニングされます。これは、トップフレームのサイトに加え、フレームのサイトで構成される可能性があります。この「ネットワーク状態」には、接続(H1、H2、H3、websocket)、DNS キャッシュ、ALPN / H2 サポートデータ、TLS / H3 再開情報、Reporting / NEL 構成とアップロード、Expect-CT 情報が含まれます。クロスサイト トラッキングは、ユーザーにとってプライバシーに対する大きな懸念となっています。本機能は、この問題に対処するうえで欠かせない部分の 1 つです。

Speculation Rules

Speculation Rules は、ナビゲーション前にプリフェッチできる外部リンクを定義するための柔軟な構文を提供します。また、可能な場合は、プライベート プリフェッチ プロキシの使用などの追加の拡張も提供します。

Web Bundle によるサブリソースの読み込み

この機能は、複数のリソースをバンドルできるフォーマットを使って大量のリソースを効率的に読み込むための新たなアプローチです(例 : Web Bundle)。

今回のリリースに追加されたその他の機能

ファイル ハンドラ Web App Manifest メンバー

ファイル ハンドラは、ウェブ アプリケーションが指定された MIME タイプや拡張子のファイルを扱えることを宣言できるようにします。ユーザーがウェブ アプリケーションでファイルを開こうとすると、そのウェブ アプリケーションがイベントを受け取ります。

PWA をファイル ハンドラにするには、Web App Manifest に file_handlers メンバーを追加します。メンバーの詳細については、仕様をご覧ください

inert 属性

新しい inert 属性を使うと、DOM ツリーの一部を不活性としてマークできます。不活性なノードは、以下のように動作します。

  • ヒットテストは、pointer-events CSS プロパティを 'none' に設定した場合と同じように振る舞います。
  • テキスト選択機能は、user-select CSS プロパティを 'none' に設定した場合と同じように振る舞います。
  • 編集可能な場合、ノードは編集不可のように振る舞います。
  • ページ内検索の場合、ユーザー エージェントはノードを無視しても構いません。

詳細については、inert の紹介をご覧ください。

ローカル フォントへのアクセス

ウェブ アプリケーションで、ローカル フォントとそれぞれのメタデータをエミュレーションできるようになります。この新しい API を使うと、ウェブ アプリケーションからローカル フォント内に格納されているテーブルデータにアクセスすることもできるので、カスタム テキスト スタックを使ってアプリケーション内にフォントをレンダリングできます。

ナビゲーション API

新しい Navigation インターフェース(window からアクセス可能)を使うと、アプリケーションでナビゲーションをインターセプトしたり、ナビゲーションを開始したり、アプリケーションの履歴エントリを確認したりできます。これは、window.historywindow.location よりも利便性が高く、単一ページウェブ アプリケーションのニーズに特化した仕組みを提供します。

hidden 属性の新しい until-found 値

Chrome で、hidden 属性に新しい値 until-found が追加されます。これにより、ページ内検索、テキスト フラグメントへのスクロール、フラグメント ナビゲーションで要素が検索可能になります。これらの検索とナビゲーション機能で hidden=until-found 要素内の対象にスクロールする場合、新しく表示されるコンテンツまでスクロールされるように、ブラウザはその要素から hidden 属性を削除し、その要素に対して beforematch イベントを発行します。詳細については、hidden=until-found で折りたたまれたコンテンツにアクセスできるようにする - Chrome デベロッパーをご覧ください。

オリジン プライベート ファイル システム拡張機能 : AccessHandle

オリジン プライベート ファイル システム(File System Access API の一部)が拡張され、データアクセスのパフォーマンスを改善する新たなサーフェスが加わります。この新しいサーフェスは、ファイルの内容へのインプレース書き込みと排他的書き込みを提供するという点で、既存のものとは異なります。この変更は、フラッシュされていない更新を整合性のとれた形で読み取る機能や、専用ワーカーで同期的に同じ処理を行う機能とともに、パフォーマンスを大幅に向上して新たなユースケースの可能性を開くものとなります。

サブリソースの Private Network Access Preflight リクエスト

ターゲット サーバーから明示的なパーミッションをリクエストする CORS Preflight リクエストが、サブリソースの Private Network Access のスケジュール前に送信されるようになります。プリフライトが失敗すると DevTools に警告が表示されますが、リクエストはこれまでどおり実行されます。これは、互換性を破る変更にはならない見込みです。ウェブサイトで新しいプリフライト リクエストが無視されたり失敗したりする場合は、これまでどおり動作します。

Private Network Access とは、パブリックなウェブサイトからプライベート IP アドレスや localhost へのリクエスト、またはプライベートなウェブサイト(イントラネットなど)から localhost へのリクエストを指します。プリフライト リクエストを送ることで、ルーターなどのプライベート ネットワーク デバイスに対するクロスサイト リクエスト フォージェリ攻撃のリスクを緩和できます。多くの場合、プライベート ネットワーク デバイスはこのような脅威から保護されていません。

Secure Payment Confirmation API の変更

今回のリリースには、Secure Payment Confirmation API への 3 つの変更点が含まれています。具体的には、PaymentMethod() コンストラクタに渡されるデータが変更されます。

  • 新しい必須プロパティ data.rpId。リライング パーティ ID を含めます。現在の実装でこれを指定していない場合、更新する必要があります。
  • 新しい省略可能プロパティ data.instrument.iconMustBeShown。カードアート アイコンをダウンロードできない場合に、プレースホルダー アイコンが使われるようにします。このフィールドを false に設定すると、アイコンがダウンロードできる場合にのみ決済を進められるようになります。デフォルト値は true です。
  • 新しい省略可能プロパティ data.payeeName。呼び出し元が、既存の data.payeeOrigin の代わりに、またはその横に、受取人の自然な名前を表示できるようにします。

requestDevice() の WebHID exclusionFilters オプション

HID.requestDevice() に渡す options オブジェクトに exclusionFilters プロパティが含まれるようになります(HID には navigator.hid でアクセスできます)。このプロパティを使うと、ブラウザのピッカーから一部のデバイスを除外できます。これを使うことで、正しく動作しないことがわかっているデバイスを除外できます。これまで、デベロッパーはカスタムのコードで選択されたデバイスをテストし、そのデバイスが動作しない場合、別のデバイスを選択するようユーザーに促す必要がありました。exclusionFilters プロパティ(用語はテキストで検索する必要があります)は、既存の options と同じメンバーを持つオブジェクトの配列です。

requestDevice() の options 引数の使用方法の例を示します。この例では、最初にベンダー ID 0xABCD でデバイスへのアクセスをリクエストします。このデバイスには、usage ページ コンシューマ(0x000C)と usage ID コンシューマ コントロール(0x0001)のコレクションも含まれている必要があります。プロダクト ID 0x1234 のデバイスは動作していません。

const [device] = await navigator.hid.requestDevice({
 filters: [{ vendorId: 0xabcd, usagePage: 0x000c, usage: 0x0001 }],
 exclusionFilters: [{ vendorId: 0xabcd, productId: 0x1234 }],
});

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

ユーザー アクティベーションによらない PaymentRequest.show() のサポート終了

サイトで、ユーザー アクティベーションによらない PaymentRequest.show() を呼び出すことはできなくなります。ユーザー アクティベーションによらない PaymentRequest.show() のトリガーを許可すると、悪意のあるウェブサイトによって不正利用される可能性があります。ユーザーを保護するため、ユーザー アクティベーションが必須となるように仕様が変更されました。購入操作が中断されることがないように、このメソッドの呼び出しは click などのユーザー イベントの内部で行ってください。

Firefox は PaymentRequest に対応していませんが、Safari の実装では、すでに show() の呼び出しにユーザー アクティベーションが必須になっています。

SDP Plan B の削除

WebRTC でセッションを確立するために使われる Session Description Protocol(SDP)は、Chromium では 2 種類の方言 Unified Plan と Plan B によって実装されています。Plan B はクロスブラウザの互換性がないため、削除されます

このバージョンの Chrome では、Plan B が使われると例外がスローされます。この例外を避ける必要があるデベロッパーは、2022 年 5 月 25 日までの逆トライアルに参加できます。12 月に終了した以前の逆トライアルに参加していて、現在のトライアルにも参加したい方は、新しいトークンをリクエストする必要があります。


Reviewed by Eiji Kitamura - Developer Relations Team

学習ツール「Google Cloud Skills Boost」を使って Google Cloud をコミュニティと一緒に学ぶ、無料の初級者向け新プログラムです。今回は BigQuery を中心としたデータ分析に関するラボを扱います。

プログラム 概要

  • プログラム期間 : 2022 年 6 月 2 日 ~ 6 月 30 日
  • キックオフ セッション : 2022 年 6 月 2 日(木)16:00 ~ 18:00
    (アーカイブでも視聴可能)

学習ツール「Google Cloud Skills Boost」を使って Google Cloud をコミュニティと一緒に学ぶ、無料の初級者向け新プログラムです。今回は BigQuery を中心としたデータ分析に関するラボを扱います。

プログラム 概要

  • プログラム期間 : 2022 年 6 月 2 日 ~ 6 月 30 日
  • キックオフ セッション : 2022 年 6 月 2 日(木)16:00 ~ 18:00
    (アーカイブでも視聴可能)
  • 対象 : Google Cloud を学びたい大学生以上の方
  • 費用 : 無料
  • 実施方法 : オンライン

本プログラム参加者は、Google Cloud Skills Boost を 30 日間無料で利用できます。

Google Cloud Skills Boost を初めてご利用いただく方にもご安心いただけるように、6 月 2 日のキックオフ セッションで使い方を説明し、いくつかのラボを解説つきで実施します。(本セッションは、アーカイブでもご覧いただけます。セッションに参加できなくても、プログラムに参加して学習することは可能です)。

また、学習においての不明点は、期間中に開催されるコミュニティ主催の勉強会やもくもく会に参加してご質問いただけます。そして、Skills Boost のクエストを完了してスキルバッジを取得された方には、先着で Google Cloud 特製グッズなどを獲得できるチャンスがあります。

記念品 :

  • 1 スキルバッジを獲得した先着 1000 名様に、Google Cloud 特製トートバックをプレゼント
  • 2 スキルバッジを獲得した先着 200 名様に、Google Cloud 特製トートバックと携帯保護ケースをプレゼント
  • 3 スキルバッジを獲得した先着 30 名様に Google Cloud 特製トートバック、携帯保護ケースと Google Cloud 認定資格試験バウチャー 1 回分をプレゼント
  • 2 つ以上のスキルバッジを獲得、かつ Twitter で #みんなで学ぼうGoogleCloud をつけてコメントしてくださった方から抽選で 10 名様に、Chromecast with Google TV をプレゼント


コミュニティやグループを主催する方、チューターとして参加を希望する方はこちらでご登録ください。また、本プログラムにも必ずご登録ください。

コミュニティ主催の勉強会は随時情報を更新していきます。


イベント概要

GDG 及びコミュニティ主催

Google Cloud Study Jam by GCPUG 女子会

日時: 2022 年 6 月 4 日(土)10:00〜12:00

場所: 本イベントはオンライン開催となり Google Meetにて開催します

参加費: 無料

定員: 20名(先着順)

対象: Google Cloud を学びたい大学生以上の方。男性の参加もOKです!

主催: GCPUG 女子会


これから Google Cloud を学びたい方は、ぜひご参加ください。

お申し込みはこちらからお願いします。



この記事は Chromium Blog の記事 "Chrome 101: Federated Credential Management Origin Trial, Media Capabilities for WebRTC, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 3 月 31 日時点で、Chrome 101 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

この記事は Chromium Blog の記事 "Chrome 101: Federated Credential Management Origin Trial, Media Capabilities for WebRTC, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 3 月 31 日時点で、Chrome 101 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。

ユーザー エージェント文字列情報の削減

Chrome では、HTTP リクエストでユーザー エージェント文字列によって公開される情報量の削減を試行しています。navigator.userAgentnavigator.appVersionnavigator.platform についても、同様の削減をします。これは、ユーザー エージェント文字列がパッシブなユーザー フィンガープリンティングに使われることを防ぐための措置です。このオリジン トライアルに参加したい方は、Chrome オリジン トライアルのエントリをご覧ください。その他の機能のサポート終了や削除については、本記事の末尾をご覧ください。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試して、ユーザビリティ、実用性、有効性についてのフィードバックをウェブ標準コミュニティに提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

Federated Credential Management API

Federated Credential Management API(FedCM)は、プライバシーを保護できる ID フェデレーションを行うためのもので、サードパーティ Cookie のようなクロスサイト トラッキングを使わずに ID フェデレーションのユースケースを継続できるように設計されています。Chrome 101 でこの機能のオリジン トライアルが始まるのは、Android のみです。PC 向けのサポートは、Chrome 後ほど追加する予定です。

完了したオリジン トライアル

Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

Priority Hints

Priority Hints は、リソースの相対的な重要度をブラウザに示し、リソースが読み込まれる順序をより細かくコントロールする方法を提供します。

今回のリリースに追加されたその他の機能

AudioContext.outputLatency

AudioContext.outputLatency プロパティは、ユーザー エージェントがホスト システムにバッファの再生をリクエストしてから、オーディオ出力デバイスがバッファ内の最初のサンプルを処理するまでの時間を秒数で見積もったものです。スピーカーやヘッドフォンなど、音響シグナルを生成するデバイスの場合、オーディオ出力デバイスが処理する時間とは、サンプルのサウンドが生成された時間です。このプロパティは、デベロッパーが入力と出力の間のレイテンシを補償したい場合に役立ちます。また、動画とオーディオのストリームを同期する際にも便利です。

Firefox では、すでにこのプロパティが実装されています。

font-palette とカスタム @font-palette-values パレット

font-palette CSS プロパティを使うと、カラーフォントからパレットを選択できます。@font-palette-values at-rule と組み合わせると、カスタム パレットを定義することもできます。この機能は、ダークモードやライトモードでアイコンや絵文字フォントを使うデザインや、コンテンツのカラーパターンと調和させるためにマルチカラー アイコン フォントで font-palette を使う場合に便利です。

hwb() CSS 関数

HWB(色相、白さ、黒さを表す英語の頭文字)は HSL と同じく、sRGB カラーを指定する方式ですが、人間にとって扱いやすいのは HWB の方です。hwb() 関数を使うと、CSS で HWB 値を指定できます。この関数は、3 つの引数を受け取ります。1 つ目は hue で、色相を角度で指定します(範囲 [0, 360] 以外の数値も利用できます)。残りの 2 つの whitenessblackness は、パーセントで指定します。

window.open() の popup 引数で 'true' を評価

この機能は、window.open()popup 引数の解析に関する最近の仕様変更に従ったものです。これまでは、popup を 'true' に設定すると、window.open() は false を表すものとして解釈していました。これは直感的でなく、混乱を生みます。この変更により、boolean 機能が使いやすく、わかりやすくなります。

WebRTC の MediaCapabilities API

MediaCapabilities API が拡張され、WebRTC ストリームをサポートします。MediaCapabilities API では、ある設定がサポートされているかどうかや、動画がスムーズに再生できそうかといった情報が提供されます。そのため、ウェブサイトは、動画再生に使うコーデックや解像度などを情報に基づいて決定できます。
この機能がない場合、ウェブアプリは適切な設定を推測するしかないため、解像度やフレームレートが不必要に低くなったり、フレームレートが高すぎるとスタッタリングが発生したりするなど、品質の低下につながる可能性があります。

Secure Payment Confirmation API V3

Secure Payment Confirmation API バージョン 3 に含まれる以下の機能が実装されます

  • 必須入力のリライング パーティ ID。これは必須なので、既存のコードを更新する必要があります。
  • instrument アイコンのダウンロード失敗を許容するかどうかを表す省略可能な boolean。
  • 省略可能な入力としての payeeName プロパティ。

USBDevice forget()

ウェブ デベロッパーは、USBDevice forget() メソッドを使うことで、ユーザーが許可した USBDevice へのパーミッションを自発的に取り消すことができます。

WebUSB sameObject の動作

USBConfigurationUSBInterfaceUSBAlternateInterfaceUSBEndpoint インスタンスが厳密なイコール("===")になるのは、同じ USBDevice のアクセッサから取得した場合のみになります。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

サードパーティ コンテキストでの WebSQL の削除

サードパーティ コンテキストでの WebSQL が削除されます。Web SQL Database 標準が最初に提案されたのは 2009 年 4 月で、2010 年 11 月に検討が中止されました。Gecko はこの機能を実装しておらず、WebKit では 2019 年に非推奨となりました。W3C は、代替手段として Web StorageIndexed Database を推奨しています。

デベロッパーは、WebSQL 自体が非推奨であり、利用率が十分低くなった際に削除される予定であることを想定する必要があります。


Reviewed by Eiji Kitamura - Developer Relations Team