デジタル カンファレンス Google Cloud Day: Digital ’21 開催まで、あと 1 か月半となりました。セッション情報が公開されましたので、気になるセッションをぜひこちらからチェックしてみてください。
今回は、初日の「基調講演」と、翌週に開催される「ハンズオン祭」をご紹介します。
今年の基調講演は、昨年よりさらにパワーアップして、二部構成でお送りします。
前半（10:00-10:45）は「Data-powered innovation」をテーマに、データの利活用や働き方改革を Google Cloud を導入して進めている企業のリーダーに、ご登壇いただきます。また、Google Cloud からは最新のクラウド ソリューションをご提案します。
後半（11:00-11:45）は「Open Cloud leading transformation」をテーマに、システムのモダナイゼーションと、従来システムとのハイブリッド クラウド環境によってトランスフォーメーションを実現している企業から、その体験をご紹介いただきます。そして、Google Cloud からは、パートナーエコシステムをより強化している中で Anthos のソリューションをご紹介します。
登壇企業（敬称略）:
株式会社 ファーストリテイリング、LIXIL 株式会社、京都大学、ウーブン・プラネット・ホールディングス株式会社、エムスリー株式会社、株式会社エヌ・ティ・ティ・データ、日本ヒューレット・パッカード株式会社
基調講演、ブレイクアウト セッションでの学びを、翌週 6 月 01 日 (火) - 03 日 (木) に開催される「ハンズオン祭」で実践しましょう。
はじめて Google Cloud を利用される方は「はじめてみよう Google Cloud」で、製品の概要や各種機能を、実際に手を動かして体験いただけます。
「Study Jam」では、Qwiklabs（30 日間無料特典つき） を使って Google Cloud を体験でき、Google エンジニアへの質問も可能です。
ハンズオン祭のいずれかのセッションに出席された方の中から、抽選で 50 名様に Google Cloud 特製手ぬぐいをプレゼントします。
※ハンズオン祭への参加は、Google Cloud Day: Digital '21 とは別にお申し込みが必要となります。以下のリンクからご興味のあるセッションへ、それぞれお申し込みください。
☁ 6 月 1 日（火）
10:00 - 13:00 Study Jam Cloud Developer 編 https://goo.gle/2QS4Ymx
14:00 - 17:00 はじめてみよう Google Cloud Cloud Run 編 https://goo.gle/31BKHDT
☁ 6 月 2 日（水）
10:00 - 13:00 Study Jam Cloud DevOps 編 https://goo.gle/2QVjWs6
14:00 - 17:00 はじめてみよう Google Cloud Kaggle (BQ, BQML) 編 https://goo.gle/39yMC0l
☁ 6 月 3 日（木）
10:00 - 13:00 Study Jam Machine Learning 編 https://goo.gle/3dmMZfM
14:00 - 17:00 はじめてみよう Google Cloud Dialogflow CX 編 https://goo.gle/2Oe4hmI
日程 :
2021 年 5 月 25 日 ( 火 ) - 27 日 ( 木 ) : 基調講演、ブレイクアウト セッション
2021 年 6 月 01 日 ( 火 ) - 03 日 ( 木 ) : ハンズオン祭
対象 : 開発者、ビジネスの意思決定者やリーダー
ハッシュタグ : #GoogleCloudDay
お問い合わせ先 : Google Cloud Day: Digital 事務局
google-cloudday-tokyo-office@google.com
————————————————————
Developer Student Clubs（DSC）プログラムは、Google Developer Technologies に関心のある大学生向けのコミュニティ グループであり、学生の開発・リーダーシップ能力の向上を支援するプログラムです。
米国を始め、ヨーロッパ、オーストラリア、東南アジア、アフリカ、インド、中東・北アフリカ、ラテンアメリカ地域などなど、合わせて 106 カ国以上、1265 拠点から世界中の学生たちが活動している DSC プログラム。今年、日本にも展開します。
非推奨の機能をサポートする最後のバージョンが廃止されると、その機能をサポートするバージョンはなくなり、機能の継続的な使用は保証されませんので、ご注意ください。
API や SDK における非推奨の微妙な違いについては、非推奨に関するドキュメントをご覧ください。現在非推奨となっているすべての機能を記載しています。
なお、Maps JavaScript API はモバイル向けの SDK とは異なります。バージョンは四半期ごとのスケジュールでリリースされたり廃止されたりするため、常に最新バージョンをデフォルト（v=weekly）で読み込むことをおすすめします。Maps JavaScript API の定期的な更新に備える方法について、詳しくはこちらをご覧ください。
Chrome for Android に特化して、あらゆる種類の Android デバイスにとって快適なブラウザを作るという、他にはない挑戦をしています。今回のリリースでは、パッケージングとランタイムの最適化を適用し、ポケットの中の Chrome のパフォーマンスを向上させています。
モバイル デバイスのセキュリティ評価は難しく、信頼できる方法で企業のクレイムを検証するには、独立した業界の認証（Certification）によるものである必要があります。スマートフォンの場合、特に確実なエンドツーエンドの認証（Certification）に Common Criteria（CC）Mobile Device Fundamentals（MDF）Protection Profile があります。Common Criteria は、31 か国に広がる大規模なセキュア IT プロダクトの相互認証（mutual recognition）を確立する原動力です。ここ数年間、すべての OS のバージョンで継続的に認証（Certification）を受けているスマートフォン メーカーは、Google、Samsung、Apple の 3 社のみです。2 月初頭には、現在サポート対象で、Android 11 を実行する Pixel スマートフォンのすべての認証（Certification）が完了しました。Google は、最新の OS バージョンで認証（Certification）を受けた最初のメーカーです。
この認証（Certification）は、コンシューマや企業が直面する現実の脅威に対するデバイスの防御力を評価するために設計されています。次の表は、CC MDF 保護プロファイルに示されている脅威と対策の概要です。
脅威
対策
ネットワークの盗聴 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する
ネットワーク攻撃 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する
通信の保護 - 安全な暗号化通信を保証する IPsec、DTLS、TLS、HTTPS、Bluetooth などの標準プロトコル
認可と認証 - ネットワークやバックエンドの安全な認証（Authentication）
モバイル デバイス設定 - ユーザーや企業の管理者が定義するセキュリティ ポリシーを設定して適用する機能
物理アクセス - 物理アクセス可能な攻撃者は、モバイル デバイスから認証情報を含むユーザーデータの取得を試みる可能性がある
ストレージの保護 - デバイスに含まれるデータを安全に保存（すなわち、保存データの暗号化）
認可と認証 - パスワード、PIN、指紋、顔認証など、既知のロック解除要素を利用した安全なデバイス認証（Authentication）
エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供
この認証（Certification）が重要なのは、認定を受けたラボが実際にデバイスを評価し、さまざまなテストをして以下を確認しているためです。
概念的には、評価対象（TOE）はデバイスのハードウェア（システム オン チップ）とオペレーティング システム（Android）の組み合わせです。上記の脅威に対する対策を検証するため、ラボは以下のセキュリティ機能を確認します。
これが企業にとって重要な理由
Pixel のセキュリティが企業のニーズを確実にサポートできることは、非常に重要です。規制が厳しい業界の多くでは、機密データが考えられる限り最も強固な保護を受けられるように、Common Criteria 認証（Certified）デバイスの利用が義務付けられています。Android Enterprise 管理フレームワークでは、企業がデバイスの管理などをし、エンドユーザーが実行できる操作を制限したり、デバイスを監査してすべてのソフトウェアが適切に設定されていることを保証したりできます。たとえば、企業の IT 管理者は、カメラ、位置情報サービス、アプリのインストール プロセスなどの機能に対するポリシーを強制できます。
これがコンシューマにとって重要な理由
セキュリティは企業だけが心配することではありません。Common Criteria 認証（Certification）で検証している多くの保護は、コンシューマにも適用されます。たとえば、Wi-Fi に接続するとき、ウェブのブラウズを誰にも盗聴されないことを確認したいと思うでしょう。デバイスの紛失や盗難の際は、ロック画面によって他人が個人情報にアクセスする可能性が減ると確信したいはずです。
Google は、すべてのユーザーにセキュリティとプライバシーをお届けしたいと考えています。Pixel デバイスがこの認証（Certification）基準以上を確実に満たせるようにしたいと考えているのはそのためです。今後もこの基準を満たすために注力しますので、どうぞご安心ください。Pixel スマートフォンでは、スイッチを入れた瞬間から充実したセキュリティを利用できます。
これが Android エコシステムにとって重要な理由
認証（Certification）はサードパーティによる検証として有用な形態ですが、以下の、Google が 3 C と呼ぶものに該当することがよくあります。
ここ 3 年間は、OEM パートナーを対象に、この複雑さを軽減するための作業をしてきました。その結果、必要なセキュリティ要件を満たすために要求される機能が Android オープンソース プロジェクトに直接組み込まれることをお知らせします。さらに、すべての管理要件と監査要件を Android Enterprise Management フレームワークに追加しました。昨年は、このために開発したツールを GitHub に公開しました。他の Android OEM が認証（Certification）を受ける際に、この作業のメリットを活用できるようにするためです。
新しい Android OS バージョンでの Pixel スマートフォンの認証（Certification）は継続しますが、Google はその他の Android OEM も、この認証（Certification）や、以下のその他の認証（Certification）を取得できるように取り組んでいます。
今後も、企業とコンシューマの両方を対象にしたセキュリティ対策に注力してまいります。業界の皆さんがこの作業に加わってくれることを歓迎いたします。
特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 3 月 11 日時点で、Chrome 90 はベータ版です。
デスクトップ版の Chrome に AV1 エンコーダが搭載されます。このエンコーダは、組み込みの WebRTC を利用したテレビ会議に特に最適化されています。AV1 には、以下のようなメリットがあります。
WebRTC は最近正式に W3C と IETF の標準になったので、この追加は特に重要です。
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルをしています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
mediaDevices.getCurrentBrowsingContextMedia() メソッドを使うと、getDisplayMedia() と同様に、現在のタブの動画（可能な場合は音声も）から MediaStream をキャプチャできます。getDisplayMedia() とは異なり、この新しいメソッドを呼び出すと、許可するか拒否するかを選択する単純なダイアログ ボックスが表示されます。ユーザーが許可した場合は、現在のタブがキャプチャされます。getCurrentBrowsingContextMedia() のその他の動作は、すべて getDisplayMedia() と同じです。このオリジン トライアルは、Chrome 92 まで行われる予定です。
カメラやマイク、画面キャプチャ、コーデックのデコーダ部分などの出力や、コーデックのデコーダ部分への入力など、MediaStreamTrack のローメディアを操作する API です。WebCodecs インターフェースを使ってローメディアのフレームを表現し、ストリームを使って公開します。この仕組みは、WebRTC Insertable Streams API が RTCPeerConnection からエンコード済みデータを公開する方法と同様です。次のようなユースケースをサポートすることを想定しています。
このオリジン トライアルは、Chrome 92 まで行われる予定です。
WebAssembly が例外ハンドリングをサポートするようになりました。例外ハンドリングを利用すると、コードで例外がスローされたときに制御フローを抜けることができます。例外は、WebAssembly モジュールの既知の例外でも、インポートされて呼び出された関数がスローした未知の例外でも構いません。このオリジン トライアルは、Chrome 94 まで行われる予定です。
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
ライティング推定を利用すると、サイトから WebXR セッション内の環境光条件の推定値を照会できます。これにより、環境光を表す球面調和関数と、「反射」を表すキューブマップ テクスチャの両方を取得できます。ライティング推定を追加すると、モデルが自然になってユーザーの環境への「適合度」が上がる可能性があります。
aspect-ratio プロパティを使うと、ある要素の横か縦のサイズだけが指定された場合に、もう片方のサイズを自動計算できます。もともとこのプロパティは、アニメーション時に補完されない（つまり、ターゲット値にスナップする）ものとして導入されました。この機能により、あるアスペクト比から別のアスペクト比に変化するときに、スムーズな補完が行われるようになります。
aspect-ratio
カスタム要素が、状態を表す CSS 疑似クラスを介してカスタム要素の状態を公開するようになります。ビルトイン要素には状態が存在します。これは、ユーザーのインタラクションなどによって時間とともに変化する場合があり、疑似クラスを通してウェブ制作者に公開されます。たとえば、フォームのコントロールの中には、"invalid" 状態を持つものがあり、これが :invalid 疑似クラスで公開されています。カスタム要素も状態を持つので、ビルトイン要素と同じように状態を公開できるのは妥当です。
以下のフォーム コントロールの CSS プロパティ appearance と -webkit-appearance のデフォルト値が、'auto' に変更されます。
appearance
-webkit-appearance
'auto'
<input type=color>
<select>
<input type=date>
<input type=datetime-local>
<input type=month>
<input type=time>
<input type=week>
これらのコントロールのデフォルトのレンダリングは変更されません。
overflow に clip 値を指定すると、ボックスのコンテンツがボックスのオーバーフロー クリップエッジでクリップされます。さらに、スクロール インターフェースは提供されず、ユーザーやプログラムはコンテンツをスクロールできなくなります。また、ボックスはスクロール コンテナとは見なされず、新しいフォーマッティング コンテキストは開始されません。そのため、この値を使うと、overflow: hidden を使う場合よりもパフォーマンスが向上します。
overflow
clip
overflow: hidden
overflow-clip-margin プロパティを使うと、要素が境界のどのくらい外側まで描画できるかを指定できます（その範囲を超えるとクリップされます）。デベロッパーは、このプロパティを使ってクリップ境界を拡張することもできます。これは、インク オーバーフローを表示したい場合に特に便利です。
overflow-clip-margin
Permissions-Policy HTTP ヘッダーは、アクセス許可や機能の委譲を制御する既存の Feature-Policy ヘッダーを置き換えます。このヘッダーを使うと、どのオリジンに機能へのアクセスを許可するかをサイトで厳密に制限できます。
Permissions-Policy
Feature-Policy
Chrome 74 で導入された Feature Policy API は、最近 "Permissions Policy" という名前に変わり、それに伴って HTTP ヘッダーの名前も変更されました。同時に、コミュニティは HTTP の構造化フィールド値に基づいた新しい構文を決定しています。
Cross-Origin-Read-Blocking が利用する盗聴されない MIME タイプのリストに application/x-protobuffer を追加し、これを投機的実行攻撃から守ります。application/x-protobuf は、すでに盗聴されない MIME タイプとして保護されています。application/x-protobuffer もよく使われている MIME タイプで、protobuf ライブラリによって "ALT_CONTENT_TYPE" として定義されています。
Cross-Origin-Read-Blocking
application/x-protobuffer
application/x-protobuf
"ALT_CONTENT_TYPE"
FileSystemWritableFileStream.write() にファイルの末尾を超えるデータを渡した場合、0x00（NUL）を書き込んでファイルを拡張します。これにより、疎なファイルを作成できるので、書き込むデータが順不同で届く場合に、コンテンツをファイルに保存する処理を大幅に簡略化できます。 この機能がないと、ファイルのコンテンツを順不同で受け取るアプリケーション（たとえば、BitTorrent のダウンロード）は、事前に、または書き込み中にファイルのサイズ変更が必要になった場合に、手動でそれを行う必要があります。
FileSystemWritableFileStream.write()
0x00
NUL
現在、ウェブ制作者が作成できる範囲型は Range のみです。しかし、Range オブジェクトは「ライブ」であり、これをメンテナンスするのはコストがかかる場合があります。ツリーが変更されるたびに、影響を受けるすべての Range オブジェクトの更新が必要です。新しい StaticRange オブジェクトは、ライブではない軽量の範囲型を表すので、Range と同じようなメンテナンス コストはかかりません。StaticRange を作成可能にすることで、ウェブ制作者は DOM ツリーの変更に応じて更新する必要がない範囲にこれを利用できます。
Range
StaticRange
<picture> 要素内で <source> 要素を使う場合、width と height プロパティがサポートされます。これにより、Chrome が <picture> 要素のアスペクト比を計算できるようになります。これは、<img>、<canvas>、<video> の各要素の動作と一致します。
<picture>
<source>
width
height
<img>
<canvas>
<video>
新しい OscillatorNode オブジェクトを作成するときに、periodicWave に null を設定できなくなります。この値は、OscillatorNode() コンストラクタに渡される options オブジェクトに設定されます。WebAudio 仕様では、この値に null を設定することは許可されていません。これにより、Chrome の動作が仕様と Firefox に一致します。
OscillatorNode
OscillatorNode()
このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 9.0 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。
Array、String、TypedArray が at() メソッドをサポートします。このメソッドは、負の数による相対インデックスをサポートします。たとえば、次のコードは指定された配列の最後の項目を返します。
at()
let arr = [1,2,3,4]; arr.at(-1);
このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
'plugin-types' ディレクティブを使うと、<embed> または <object> html 要素で読み込めるプラグインの種類をデベロッパーが制限できます。これにより、デベロッパーはページ内の Flash をブロックできます。Flash のサポートは終了したので、このポリシー ディレクティブは不要になりました。
<embed>
<object>
Chrome では、WebRTC の非標準である RTP データ チャンネルのサポートを削除しました。ユーザーは、標準の SCTP ベースのデータ チャンネルを使用する必要があります。
Chrome は navigator.plugins と navigator.mimeTypes に対して空を返します。Flash が削除されたことで、これらのプロパティから何かを返す必要はなくなりました。
navigator.plugins
navigator.mimeTypes
