土地利用データを使ってゲームプレイをデザインする機能も追加しました。これにより、その位置の土地の表面の種類に関する情報を入手できるようになります。ここで皆さんは、砂漠でサボテンを生長させたり、草原でプレイヤーに昆虫を捕まえさせたり、アライグマを裏通りのごみ収集箱に置いたりすることが可能になります。掃除機を振り回してさまざまな生物、建物などを吸い込む宇宙怪物を作るというのはいかがでしょうか？




また、地形標高の機能も追加しました。これは、平面的な世界で退屈している人にとっては、非常に興味がそそられる機能です。この機能により、丘、山、都市を好みのスタイルに設計し、一層カスタマイズされた位置情報の要素をゲームに組み入れることができます。




素晴らしいものを構築しよう

没入型のリアルワールド ゲームのデザインは、ゲームプレイを現実の世界に単に置くこと以上のことを行うことになります。プレイヤーがそのゲームを体験する上で不可欠な実在する場所を作ることです。プレイヤーが、いつ、どこでプレーし、その時彼らの周囲に何が存在しているのかを把握します。Google Maps のデータと Google のインフラストラクチャによって、ゲームの世界を現実世界に変えるということです。2005 年より、Google は世界の地図を作製してきました。そして、今、現実世界について知っている情報を自身のゲームで生かすことができるのです。


詳しくは、Google Maps Platform に関するウェブサイト g.co/mapsplatform/gaming を閲覧ください。




Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps テクニカルアカウントマネージャ

Pinar Ozlen
 ソフトウェア エンジニア


Firebase Cloud Messaging（FCM）をお使いなら、さまざまな方法でメッセージを送信できることをご存知でしょう。特定の端末上のアプリをターゲットにすることも、トピック API を使ってたくさんのユーザーをターゲットにすることもできます。FCM の API は、リクエストの処理に失敗するとエラーコードとその説明を返すので、失敗したことがわかります。ただし、それが当てはまるのは、皆さんと FCM バックエンド間のリクエストの一部だけです。では、FCM がメッセージ リクエストを受けると、何が起こるのでしょうか。
この投稿では、Firebase Cloud Messaging のインフラストラクチャと、メッセージが実際に端末に配信される仕組みについて解説します。


メッセージの受け入れ

FCM が API リクエストに対して成功応答を返した場合、これは単に、FCM が端末または端末にメッセージを配信するサービス（例: iOS 端末に配信する場合は Apple Push Notification サービス、Firefox ブラウザに配信する場合は Mozilla Push Service）にメッセージ配信の試行を始めるという意味にすぎません。この試行は、以下のいずれかの条件が満たされるまで繰り返されます。
  1. メッセージの有効期限が切れる: メッセージの有効期限は、API を通して設定できます。FCM が再試行する期間は最長 28 日間で、これが既定値になっています。
  2. リクエストしたメッセージが別のメッセージで置き換えられる: 折りたたみキーを設定することで、メッセージを新しいバージョンのメッセージで置き換えることができます。その一例として、最新のスコアをユーザーに伝えるスポーツ アプリがあげられます。意味があるのは最新メッセージだけです。
  3. 端末が 1 か月以上オンラインになっていない: FCM が端末の接続についての情報を持っており、端末が 1 か月以上オンラインになっていないことがわかっている場合、FCM はメッセージを受け入れますが、実際には配信を試行しません。端末が再びオンラインになると、FCM は保留中のメッセージが削除されたことをアプリに通知します。
    1. Android では、端末が再びオンラインになると、FCM が onDeletedMessages() を呼び出します。
    2. iOS では、アプリが開かれたときに FCM が FIRMessagingMessagesDeletedNotification を呼び出し、保留中のメッセージが削除されたことをアプリに通知します。 注: 保留中のメッセージが有効期間を過ぎた場合、これらの関数が呼ばれることはありません。


メッセージの配信

実際の端末へのメッセージの配信と、FCM が提供できる配信情報の量には、多くの要素が影響しています。

共通の要素

  1. 端末がオフラインになっている: 端末がオンラインでない場合、FCM はメッセージを配信できません。オフラインになる端末は多く、二度とオンラインにならない端末もあります。FCM はこのような端末のアプリに送られたメッセージも受け入れを続けますが、端末が再びオンラインにならない限り、メッセージが配信されることはありません。
  2. メッセージの優先度: FCM API を使ってメッセージの優先度を高または通常に設定することができます。Android、iOS のどちらのプラットフォームでも、電池を最適化しつつ、設定に応じてメッセージを配信します。

Android の要素

  1. Doze モード: FCM は、端末が Doze モードになっている場合、それが解除されるまで優先度が通常のメッセージの配信を控えます。優先度高のメッセージは即座に送信されますが、端末の Android アプリ スタンバイ バケット ポリシーによる制限を受けます（Android P 以降）。
  2. アプリ スタンバイ バケット: Android P 以降では、すべてのアプリがアプリ スタンバイ バケットに従います。そのため、メッセージの優先度を高に設定しても、アプリを復帰させるための割り当てが十分でない場合、端末がメッセージの配信を遅らせる場合があります。詳細については、こちらをご覧ください。
  3. バックグラウンド制限: Android は、アプリがバックグラウンドで実行されているときは、機能を制限します。アプリを強制的に停止した場合や、アプリがこの制限に従っていない場合、メッセージがアプリに配信されない場合があります。
  4. ユーザーによるバックグラウンド制限: FCM は、ユーザーがバックグラウンド制限を設定しているアプリにはメッセージを配信しません。
  5. アンインストールされたアプリ: FCM が端末へのメッセージ配信を試みたもののアプリがアンインストールされていた場合、端末はただちにメッセージを破棄し、登録トークンを無効にします。それ以降、その端末にメッセージを送信しようとすると、API のレスポンスは 'NotRegistered' エラーとなります。
注: プロジェクトのメッセージ配信イベントを分析したい場合は、FCM データを BigQuery にエクスポートして分析できます。

iOS の要素

FCM は、iOS 端末に対して次の 2 つの方法でメッセージを送信します。
  1. APN チャンネル: 最もよく使われるのは、APN 経由でメッセージを送信する方法です。FCM v1 HTTP API を使ってメッセージ配信をリクエストしている場合や、以前の FCM API を使って表示メッセージを送信している場合は、FCM が APN にアクセスして通知を配信します。APN がメッセージ リクエストを受け入れると、端末に通知を配信するのは APN の役割になります。この場合、FCM 自体は配信情報を収集しません。APN から送信されるメッセージは、他の APN メッセージと同様のメッセージ配信要素の影響を受けることになります。APN 経由の iOS 端末への配信に影響を与える要素の詳細については、こちらをご覧ください。
  2. FCM ダイレクト チャンネル: iOS 端末にメッセージを送るもう 1 つの方法は、FCM ダイレクト チャンネルです。以前の FCM API を使ってデータのみのメッセージを送信し、かつ shouldEstablishDirectChannel メソッドでダイレクト チャンネル接続を有効にしている場合、メッセージはダイレクト FCM チャンネル経由で配信されます。アプリがバックグラウンドで動作している、または閉じられている場合、FCM バックエンドはメッセージ キューを使って保留中のメッセージを追跡します。アプリがフォアグラウンドになって再接続されると、チャンネルが自動的にクライアントに保留中のメッセージを送信します。これは、クライアントからの確認応答を受信するまで繰り返されます。 注: iOS で表示用の通知の配信情報にアクセスしたい場合は、FCM Reporting Dashboard を使用できます。このダッシュボードは、Firebase 向け Google アナリティクスのデータ共有機能を使い、Android および iOS の Firebase SDK 経由で表示用の通知の配信情報を収集します。

ウェブの要素

  1. Android の制限: Android のブラウザでウェブアプリを実行している場合、「Android の要素」に記載したすべての制限がウェブにも適用されます。
  2. プッシュ サービス: Push API 対応のブラウザ上で動作しているウェブアプリにプッシュ通知を配信し、そのブラウザが別のプッシュ サービスを使ってメッセージを配信している場合、FCM はそのプッシュ サービスにメッセージを渡して配信してもらいます。メッセージを渡した後は、メッセージを配信するのはそのプッシュ サービスの役割となります。そのため、プッシュ サービスによっては、別の制限が課される可能性があります。
メッセージの受け入れと配信の詳細については、メッセージの有効期間およびメッセージ配信についてをご覧ください。


Reviewed by Khanh LeViet - Developer Relations Team


画像認識用ニューラルネットワーク Inception V1 の層の 1 つを Activation Atlas で表示した詳細イメージ。ネットワークが画像を分類するために、さまざまに異なる種類の画像検出を適用していことがわかる。たとえば、果物のような構造、ハチの巣状のパターン、織物のような質感など。

次に示す例は、ImageNet データセットでトレーニングした CNN である Inception V1 に対して Activation Atlas を適用したものです。CNN では一般に、画像を受け取ってそれにラベルを付けます。具体的には、事前に決められている「カルボナーラ」「シュノーケル」「フライパン」といった 1,000 種類ほどのラベルをそれぞれの画像に付けておきます。これを行うために、ネットワークは 10 個ほどの層を使って画像データを段階的に評価していきます。それぞれの層は数百個のニューロンから成り、その個々のニューロンは画像のさまざまな部分に反応して活性化します。ある層のあるニューロンは犬の耳に反応したり、入力側の層のあるニューロンはコントラストの強い縦線に反応したりします。

Activation Atlas は、100 万枚の画像からニューラル ネットワークの各層の内部的な活性化状態を集めることで構築されています。この活性化状態は複雑な高次元ベクトルの集まりで表現されています。それを、UMAP でわかりやすい 2 次元のレイアウトに投影します。UMAP は、高次元データからその本質的な構造を取り出すための次元削減の技術です。

これで活性化ベクトルを整理できますが、すべての活性化状態を収集すると一目ではわからないほど膨大な数になるので、それを集約して実際に扱える程度に減らす必要があります。そこで、作成した 2 次元レイアウトの上にグリッドを描画します。グリッド内のそれぞれのセルで、セルの境界内にあるすべての活性化状態の平均を計算し、特徴の視覚化によって個々のセルを表す画像を作成します。
左: ランダムな 100 万個のイメージをネットワークに入力し、画像ごとに空間的な活性化状態を 1 つ、ランダムに収集する。中央: 活性化状態を UMAP に渡し、2 次元まで次元を減らす。その結果をプロットする。似たような活性化状態は互いに近くに配置される。右: グリッドを描画し、セルに対応する活性化状態の平均を計算して、平均化した活性化状態の特徴を反転させる。

下の図は、ニューラル ネットワークのある 1 つの層だけを Activation Atlas で表したものです（先に触れたように画像認識モデルは通常たくさんの層を備えます）。これは、ネットワークがこの層で学習した視覚的概念をすべて網羅する図です。こうした Activation Atlas による可視化の結果はあまりに膨大すぎて、見慣れないうちは意味がわからないかもしれません。このたくさんのさまざまな模様が、画像認識モデルが作り出したさまざまな視覚的抽象化と概念を反映しています。

Inception V1 の多くの層の 1 つ（mixed4c）を Activation Atlas で表現した概要図。ネットワークの中ほどに存在する層を表している。
この付近では、さまざまな種類の葉や植物を検出していることがわかる。
ここでは、さまざまな水域、湖、砂州を検出している。
ここには、さまざまな建物や橋がある。
前述のように、このネットワークには、ほかにもたくさんの層があります。ネットワークの奥に向かうにつれて概念が細分化されていくことを確かめるため、この層の前の層を見てみましょう（それぞれの層は、前の層の活性化を受けて活性化します）。
前の層である mixed4a には、漠然とした「哺乳類」の領域がある。
ネットワークの次の層の mixed4b では、動物と人が分かれ、その間には果物や食べものが現れている。
mixed4c 層では、以上のような概念がさらに細分化され、小さな「半島」状になって区別されている。
層を重ねるごとに全体的な構造が進化していきますが、個々の概念も具体的で複雑なものになっていくことがわかります。3 つの層について、具体的な分類項目である「キャベツ」に関係する領域に注目してみると、それがよくわかります。
左: 最初に近い層。ほかの層に比べると、具体性が低い。中央: 中ほどの層では、明らかに葉のようなイメージだが、種類まではわからない。右: 最後の層では、葉が球状に丸まっているキャベツ特有のイメージになっている。

もう 1 つ、注目すべき現象があります。層を重ねるごとに概念が細かくなっていくだけでなく、古い概念を組み合わせて新しい概念が現れているように見えます。

中ほどの層である mixed4c（左および中央）では、砂と水は別々の概念になっている。「砂州」という分類項目は、その両方と強く結びついている。その後の層である mixed5b（右）と比較すると、2 つの概念が 1 つの活性化状態として融合していると考えられる。

特定の層全体を表す Activation Atlas の特定の領域にズームすることもできますが、ImageNet の 1,000 の分類項目の 1 つに注目し、その特定の層の Activation Atlas を作ることもできます。これを見ると、ネットワークが特定の分類項目に分類する際に、特に頻繁に使っている概念とそれをどう探しているかがわかります。たとえば、「アカギツネ」の例を見てみましょう。
ここから、ネットワークが「アカギツネ」に分類する際に、何に注目しているかがよくわかる。耳がとがっていること、赤い毛で鼻の周りが白くなっていること、背景が森や雪であることがあげられる。
ここでは、さまざまな拡大率や角度の「瓦屋根」を検出している。
「アイベックス」では、角と茶色い毛皮を検出していることがわかる。それだけでなく、アイベックスがいる岩場などの環境も検出している。
瓦屋根の場合と同じく、「チョウセンアザミ」でもさまざまな大きさのチョウセンアザミの画像を検出している。それに加えて、紫色の花を検出している部分もある。チョウセンアザミの花を検出しようとしているものと考えられる。
このような Activation Atlas から、モデル内で細やかな視覚的抽象化が行われていることがわかります。それだけでなく、概念的なレベルの間違いが起きていることがわかる場合もあります。たとえば、「ホホジロザメ」の Activation Atlas を見てみると、水と三角形のひれが出てきます。これは予想どおりですが、野球ボールのようなものがあることもわかります。ここから、このモデルが覚えてしまった「近道」がわかります。つまり、野球ボールの赤い縫い目と、口を開けたホホジロザメを似ているものとして認識しています。

これをテストするため、野球ボールのイメージの一部を貼り付けてみると、モデルは「コククジラ」の特定のイメージを「ホホジロザメ」に分類するようになります。

この Activation Atlas が、機械学習をより身近で解釈しやすくする技術のひとつとして活用されることを期待しています。簡単に試せる Jupyter ノートブックをリリースしましたので、ブラウザで Colab を開き、1 回クリックするだけですぐに実行できます。Activation Atlas は、以前にリリースされたツール Lucid をベースとしており、わかりやすい視覚化を行うさまざまな技術を備えています。


Activation Atlas を使って皆さまが見つけた新しい発見の報告をお待ちしています。


Reviewed by Kaz Sato - Staff Developer Advocate, Google Cloud

コーラル開発ボードは、新しいプロダクトの開発用です。完全に統合されたシステムで、キャリアボードに接続された System on Module（SoM）として設計されています。この SoM は、強力な NXP iMX8M SoC と Google の Edge TPU コプロセッサを組み合わせたものです（Wi-Fi、Bluetooth、RAM、eMMC メモリも含まれています）。コンピュータ ビジョン アプリケーションのプロトタイピングを簡単に行えるように、MIPI インターフェースで開発ボードと接続できるカメラも提供します。


既存の設計に Edge TPU を追加したい場合は、コーラル USB アクセラレータを使うと、USB 2.0 や 3.0 経由でどんな Linux システム（Raspberry Pi ボードも含む）にも簡単に組み込むことができます。PCIe バージョンも近日中に登場する予定で、M.2 または mini-PCIe 拡張スロットにはめ込むことができるようになります。


生産ラインへのスケーリングの準備ができた方のために、開発ボードを元にした SOM と PCIe バージョンのアクセラレータの大量発注も受け付けます。独自のキャリアボードを作ってさらに統合を進めたい方のために、ベースボードの回路図も公開する予定です。
ソフトウェア ツールは、TensorFlow と TensorFlow Lite をベースとしています。TF Lite モデルは、量子化して Google のツールチェーンを使ってコンパイルした上で、Edge TPU で直接実行する必要があります。簡単に試せるように、トレーニングおよびコンパイル済みでコーラルボードですぐに動作させることができる 10 個以上のモデルと、それを再トレーニングするためのソフトウェア ツールを共有しています。


コーラルを使ってネットワーク接続端末を構築したい方は、Google Cloud IoT と組み合わせることができます。Google Cloud IoT は、クラウド サービスと端末上のソフトウェア スタックを組み合わせ、機械学習機能を利用するマネージド エッジ コンピューティングを実現できるようにしたものです。


コーラル製品群は、本日より入手可能です。製品ドキュメント、データシート、サンプルコードは、g.co/coral に掲載されています。今回の公開ベータ版期間中にぜひお試しください。公式リリースの際には、さらに多くの情報を共有できることを楽しみにしています。


Reviewed by Khanh LeViet - Developer Relations Team

この偉業は、Google Compute Engine の仮想マシンクラスタと、Alexander J. Yee 氏が開発した円周率ベンチマーク プログラム y-cruncher を使って達成しました。31 兆 4000 億桁は、2016 年 11 月に Peter Trueb 氏が達成した前世界記録をほぼ 9 兆桁上回っています。Yee 氏は、Bellard の公式と BBP 公式を使ってこの計算を独立に検証しました。次に示すのは、結果の末尾 97 桁です。


6394399712 5311093276 9814355656 1840037499 3573460992

1433955296 8972122477 1577728930 8427323262 4739940
y-cruncher の観点から見たこの記録の詳細は、Yee 氏のレポートに記載されています。


終わらない計算競争

確かに、ほとんどの科学用途では、数百桁を超える π が必要になることはありません。だからといって、そこで立ち止まる人は誰もいません。2009 年より、エンジニアたちはカスタマイズしたパソコンを使って数兆桁の π を計算してきました。実際、π の数の計算競争が加速したのは、最近になってからです。コンピュータ科学者たちはスーパーコンピュータをテストする方法として π を使うようになり、数学者たちも π の計算を競い合うようになりました。


しかし、π を計算する一般的なアルゴリズムである Chudnovky の公式の計算量は、 O(n (log n)3) です。わかりやすく言えば、π の数を計算するために必要な時間とリソースは、その桁自身よりもはるかに早く増加することになります。さらに、計算が進むにつれてハードウェアの停止や故障の可能性が増えるので、それを回避するのも難しくなります。


私たちは、π の計算をクラウドで行うことにしました。専用の物理マシンを使うことに比べると、Google Cloud の高パフォーマンス Infrastructure as a Service である Compute Engine を使うことには、たくさんのメリットがあります。まず、Compute Engine のライブ マイグレーション機能のおかげで、Google がインフラストラクチャを最新状態に保つために必要な作業を行っている間も、アプリケーションの実行は継続されます。今回は、25 ノードを 111.8 日にわたって稼働させました。言い換えれば 2,795 マシン日（7.6 マシン年）となります。この間に、Google Cloud は数千回のライブ マイグレーションを行いましたが、アプリケーションが中断することはなく、計算処理への影響もありませんでした。


クラウドで実行することで、計算した数をディスク スナップショットとしてそのまま公開することもできます。1 時間未満で 1 日当たり 40 ドルというわずかな額で、スナップショットをコピーし、その結果に対して処理を行い、必要がなくなれば計算リソースを破棄することができます。クラウド以前だと、このような大規模なデータセットを配布する唯一の現実的な方法は、物理ハードドライブを運ぶことでした。


さらに、クラウドで実行することによる一般的なメリットもあります。ハードウェアの選択肢には、AVX-512 をサポートした最新の Intel Skylake プロセッサなど、さまざまなものがあります。オンデマンドでインスタンスのスケールアップやスケールダウンを行うことができ、作業が終われば停止することも可能です。支払う必要があるのは、使った分だけです。

今回のプログラムの詳細を以下に示します。






2019-03-11 pi graphic_02.png
π クラスタ アーキテクチャの概要
クラスタ デザイン
主な計算ノードとして選んだのは、n1-megamem-96 インスタンスです。これは、Compute Engine で利用できる仮想マシンタイプのうち最大のもので、このプロジェクトの開始時点で Intel Skylake プロセッサを搭載していました。Skylake 世代の Intel プロセッサは AVX-512 をサポートしています。これは、512 ビットのデータ（倍精度浮動小数点数 8 つ）に対して一度に浮動小数点演算を行うことができる 512 ビット SIMD 拡張機能です。


現時点では、Compute Engine の各仮想マシンに対して、最大 64 TB の Persistent Disk をマウントできます。そこで、iSCSI プロトコルを使って Persistent Disk をリモートからアタッチし、容量を追加しました。ノードの数は、y-cruncher のディスク ベンチマーク パフォーマンスに基づいて決定しました。計算ノードとストレージ間で十分な帯域幅を確保するため、iSCSI ターゲット マシンには n1-standard-16 を使いました。下りネットワークの帯域幅と Persistent Disk のスループットは、vCPU コア数によって決まります。


具体的な計算方法

私たちの pi.delivery サービスは、ウェブから π の数にアクセスできる REST API を提供しています。いくつかのおもしろい実験によって、π を見たり聞いたりする試みも行っています。


皆さんがこの数を簡単に利用できるように、結果の π の数をスナップショットとして Google Cloud Platform で公開しています。それぞれのスナップショットには、小数が記述された 1 つのテキスト ファイルが含まれています。このイメージから、新しい Persistent Disk を作ることができます。Linux と Windows のオペレーティング システムそれぞれに対応できるように、XFS と NTFS の両方のディスク フォーマットを準備しています。スナップショットは、us マルチリージョンにあります。


スナップショットにアクセスするには、pi-31415926535897 Google Group に参加する必要があります。us-central1、us-west1、us-east1 リージョンのいずれかのプロジェクトでクローンしたディスクを保持する場合、1 日当たりおよそ 40 ドルがかかります。スナップショットは、2020 年 3 月 14 日まで保管する予定です。スナップショットは、以下の場所にあります。


XFS: https://www.googleapis.com/compute/v1/projects/pi-31415926535897/global/snapshots/decimal-digits-xfs
NTFS: https://www.googleapis.com/compute/v1/projects/pi-31415926535897/global/snapshots/decimal-digits-ntfs


プロジェクトで、XFS スナップショットをベースに pi314-decimal-digits-xfs という名前の新しいディスクを作りたい場合、たとえば次のコマンドを入力します。

gcloud compute disks create pi314-decimal-digits-xfs --source-snapshot https://www.googleapis.com/compute/v1/projects/pi-31415926535897/global/snapshots/decimal-digits-xfs
予期しない課金を防ぐため、作業が終わったら忘れずにディスクを削除するようにしてください。

gcloud compute disks delete pi314-decimal-digits-xfs

 詳しい手順やイメージの使い方については、ブートディスク以外のディスク スナップショットの復元セクションと、gcloud compute disks create コマンドヘルプをご覧ください。


一巡する

 数学や科学の世界には、破られるのを待っている記録がたくさんあります。31 兆 4000 億桁の計算はすばらしい経験でしたが、私たちは次の困難な挑戦に向かうことを楽しみにしています。それまでの間は、楽しい実験でこの日を祝いましょう。実験的ウェブサイト Showcase に掲載されている Pi Day Celebration というクラウド実験では、選んだ π の桁からカスタムアート作品を生成することができます。サンフランシスコで開催される Google Cloud Next '19 に参加予定の方は、Alexander Yee 氏を招いてこの実験の詳細や考察を解説する詳細テクニカル セッションにお越しください。DevZone では、Showcase の実験を体験したり、π を計算するライブ実験を見ることもできます。

Posted by Emma Haruka Iwao - Developer Advocate, Google Cloud
Share on Twitter Share on Facebook

Share on Twitter Share on Facebook


ストレージを暗号化しておけば、スマートフォンが誰かの手に渡ったとしても、データを守ることができます。Adiantum は、暗号化におけるイノベーションです。暗号化アクセラレーション機能を搭載していない端末でも効率的にストレージを暗号化できるように設計されており、 あらゆる 端末を暗号化できます。


現在の Android では、Advanced Encryption Standard（AES）によるストレージ暗号化が提供されています。新しい Android 端末のほとんどは、ARMv8 Cryptography Extensions による AES 暗号化がハードウェアでサポートされています。しかし、Android はさまざまな端末で実行されています。最新のフラッグシップ スマートフォンやミッドレンジ スマートフォンだけでなく、主に発展途上国で販売されているエントリーレベルの Android Go スマートフォンや、スマートウォッチ、スマート TV などもあります。安価な選択肢を提供するため、端末メーカーがローエンド プロセッサを使うこともあります。たとえば、AES をハードウェアでサポートしていない ARM Cortex-A7 などです。こういった端末では、AES は遅すぎるため、アプリの起動に時間がかかる、端末全般の動作が遅くなるなど、ユーザー エクスペリエンスの低下につながります。そのため、ストレージ暗号化は 2015 年に Android 6.0 以降のほとんどの端末で必須となっているものの、AES パフォーマンスが低い（50 MiB/s 以下の）端末はこの要件が免除されています。私たちは、暗号化は誰でも使えるべきだと考えているため、この点に対応する作業を進めてきました。


HTTPS 暗号化では、この問題は解消されています。ハードウェア アクセラレーションが利用できない場合、ChaCha20 ストリーム暗号化は AES よりもはるかに高速です。一方で、この暗号化はきわめて安全です。高速さの秘訣は、あらゆる CPU がネイティブでサポートしている演算のみ（加算、循環、XOR）を使っている点にあります。そのため Google は、HTTPS インターネット接続を保護するための新しい TLS 暗号スイートとして、2014 年に ChaCha20 と、同じくソフトウェアで高速に処理できる Poly1305 認証を選択しました。ChaCha20-Poly1305 は RFC7539 として標準化されており、AES 命令が搭載されていない端末の HTTPS パフォーマンスを大きく向上させています。


ただし、ディスクとファイルの暗号化には、固有の問題があります。ストレージ デバイス上にあるデータは、「セクタ」に分割されています。現在のセクタの一般的なサイズは、4096 バイトです。ファイルシステムがデバイスにセクタの読み込みまたは書き込みのリクエストを行うと、暗号化レイヤーがそのリクエストをインターセプトし、プレーンテキストと暗号テキストの変換処理を行います。つまり、4096 バイトのプレーンテキストと 4096 バイトの暗号テキストを相互に変換しなければなりません。しかし、RFC7539 を使うと、暗号テキストはプレーンテキストよりもわずかに大きくなります。暗号の nonce とメッセージの整合性情報を格納するために、わずかな領域が必要になるからです。この追加情報を格納する場所をソフトウェアで探すテクニックも存在しますが、効率が落ち、ファイルシステムの設計も大幅に複雑化する可能性があります。


AES でディスクを暗号化する際によく使われるソリューションは、サイズが変わらない XTS モードまたは CBC-ESSIV モードを利用する方式です。現在の Android は、ディスク全体の暗号化には AES-128-CBC-ESSIV を、ファイルベースの暗号化には AES-256-XTS を利用しています。しかし、AES のパフォーマンスが不十分な場合は、ローエンド ARM プロセッサでも十分なパフォーマンスを出せる代替方式として広く普及しているものはありません。


この問題を解決するために、Adiantum という新しい暗号化モードを設計しました。Adiantum を使うと、サイズを変えないモードで ChaCha ストリーム暗号を使えるようになります。これは、HCTR や HCH など、サイズを変えない AES ベースの暗号化として提案されている方式の考え方を取り入れることによって実現しています。ARM Cortex-A7 は、4096 バイトのセクタに対する Adiantum による暗号化と復号化を、1 バイト当たり約 10.6 サイクルで実行できます。これは、AES-256-XTS より約 5 倍高速です。
Adiantum は、XTS や CBC-ESSIV などのモードとは異なり、真のワイドブロック モードを実現しています。つまり、プレーンテキスト内のどのビットを変更しても、暗号テキストのすべてが変更され、判別できなくなります。その逆も同じことが言えます。動作の仕組みは、以下のようになっています。最初に、Poly1305 および別の非常に高速な鍵つきハッシュ関数である NH に基づく鍵つきハッシュ化によって、プレーンテキストのほぼ全体をハッシュ化します。また、「tweak」と呼ばれる値もハッシュ化します。これは、セクタごとに異なる暗号化を行うようにするためのものです。次に、このハッシュを使い、ChaCha 暗号化に使う nonce を生成します。復号化でも暗号化と同じ強度を実現できるように、暗号化の後、再度ハッシュ化を行います。この処理は、暗号化したものを復号化できるように、ファイステル ネットワークという形で構造化されています。16 バイトのブロックに対して AES-256 を 1 回実行する必要もありますが、4096 バイトの入力に比べれば、パフォーマンス的に大きな影響はありません。
ChaCha のような暗号プリミティブは、「ラウンド」として扱われています。このラウンドを繰り返すたびに、スピードと引き替えに安全性が高まります。多種多様な端末で十分高速にディスクを暗号化できるように、一般的に使われている 20 ラウンドの ChaCha ではなく、12 ラウンドの方式を選択しています。ラウンドを繰り返すたびに、攻撃の難易度は大幅に上がります。7 ラウンドの方式は 2008 年に破られており、多くの論文も発表されて攻撃方法も向上していますが、8 ラウンドを破ることができる攻撃方法は今のところ見つかっていません。実は、繰り返すラウンド数と現在破られているラウンド数の比率で見れば、AES-256 よりも ChaCha12 の方が優れています。


Adiantum はまだ生まれたばかりですが、私たちはその安全性に強い自信を持てる立場にあります。私たちの論文では、ChaCha12 と AES-256 が安全であるという前提のもと、Adiantum が優れたセキュリティ特性を持つことを証明しています。ChaCha や AES のような「プリミティブ」から XTS、GCM、Adiantum などの「構造」を作るというのは、暗号の世界では標準的な技法です。プリミティブが安全であるかどうかについては、私たちが説得力のある主張を行えることは多いものの、その証拠を提供することはできません。ただし、プリミティブが安全であれば、そこから作った構造も安全であることは証明できます。NH および Poly1305 ハッシュ関数については、前提とする必要はありません。必要な暗号特性（"ε-almost-∆-universality"）を持っていることが証明されているからです。
Adiantum は、ホウライシダという植物にちなんで名付けられました。ヴィクトリア時代の花言葉では、誠実さと慎みを表す植物とされています。

参考資料

設計の詳細、安全性の証明については、論文 Adiantum: length-preserving encryption for entry-level processors をご覧ください。IACR Transactions on Symmetric Cryptology に掲載されています。この論文は、3 月の Fast Software Encryption カンファレンス（FSE 2019）で発表される予定です。
Adiantum の一般的な実装および ARM に最適化された実装は、Android 共通カーネル v4.9 以降およびメインライン Linux カーネル v5.0 以降で利用できます。リファレンス コード、テストベクトル、ベンチマーク スイートは、https://github.com/google/adiantum で公開されています。
Android 端末メーカーは、AES のパフォーマンスが 50 MiB/秒以下かつ Android Pie を搭載する端末で、ディスク全体またはファイルベースの暗号化に Adiantum を利用することができます。AES がハードウェアでサポートされている場合は、Adiantum よりも AES の方が高速です。AES のパフォーマンスが 50 MiB/s を超える場合は、AES の使用が必須である点は変わりません。Android Q では、Adiantum が Android プラットフォームの一部となる予定です。今後、すべての新しい Android 端末で、許可されているいずれかの暗号化アルゴリズムを使った暗号化が必須となるように、Android Compatibility Definition Document（CDD）を更新する予定です。


謝辞: 本投稿は、Greg Kaiser および Luke Haviland による寄稿に基づいています。Adiantum は、Paul Crowley と Eric Biggers が設計し、Eric Biggers と Greg Kaiser が Android に実装しました。命名は、Danielle Roberts によって行われました。

Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

全体の仕組み

Firebase 向け ML Kit は、Google Cloud の持つ機械学習（ML）の専門知識を、高機能と使いやすさを兼ね備えたパッケージにして Android アプリや iOS アプリに提供するモバイル SDK です。使いやすい Base API が揃っており、独自のカスタム TFLite モデルを作成する機能もあります。

ARKit は Apple が提供するフレームワークです。デバイスのモーション トラッキング、カメラによるシーン キャプチャ、高度なシーン処理といった機能に加えて表示も手軽であることから、AR アプリ開発を簡略化できるツールとなっています。これらのテクノロジーを基に、iOS デバイスの前面または背面カメラを使用するさまざまな AR アプリを開発することができます。

このプロジェクトでは、背面カメラで撮影した ARKit フレームをキューにプッシュします。そのフレーム内のオブジェクトを検出する処理を ML Kit で実行します。

ユーザーが画面をタップすると、検出されたラベルの中で信頼度が最大値のものが ML Kit から返されます。そしてそれを元に 3D のふきだしテキストが作成されて、ユーザーのシーンに追加されます。

ML Kit が果たす役割

ML Kit は、機械学習の利用経験を問わず、すべてのモバイル デベロッパーが簡単に機械学習を導入できるツールです。より高度な使用状況に対応する必要がある場合、ML Kit で独自の TFLite モデルを作成することも可能ですが、一般的なユースケースの場合は使いやすい Base API を実装できます。テキスト認識、画像のラベル付け、顔検出などのユースケースに対応できるこれらの API は、Google Cloud でトレーニングされたモデルを利用しています。私たちのサンプルアプリでは、画像のラベル付けを使用します。

Base API は、オンデバイスとクラウドベースという 2 種類の方法で利用できます。オンデバイスの API は無料で使用でき、ローカルで実行されます。クラウドベースの場合はより正確で精度の高い応答が得られます。クラウドベースの Cloud Vision API は、最初の API 呼び出し 1,000 ユニットについては無料で利用でき、それ以上になると利用料金が発生します。Google の Cloud Vision API に基づくフルサイズ モデルの機能を利用できます。

両者を活かした方法

私たちのアプローチでは、画像にラベル付けする ML Kit のオンデバイス API を使用して、60 fps のフレームレートを維持しながら結果のライブフィードを取得することにします。ユーザーが画面をタップしたときに、現在の画像でクラウドの画像ラベル付け用 API に対し非同期呼び出しを起動します。より精度の高いこのモデルから応答を受け取ると、3D ラベルがすぐに更新されます。つまり、オンデバイス API を継続的に実行し、その結果を最初の情報源として使用しながら、より正確な Cloud API をオンデマンドで呼び出して、その結果を後からオンデバイスのラベルと置き換えるのです。

どちらの結果が表示されるか

オンデバイス API ではすべての処理がリアルタイムでローカルに実行されます。一方、Cloud Vision API では Google Cloud バックエンドへのネットワーク リクエストを実行し、大規模で精度の高いモデルを活用します。私たちはこちらの方がより正確な応答だと考えて、アプリでは、オンデバイス API で提供されたラベルを、Cloud Vision API から結果が返され次第、その結果に置き換えています。

試してみましょう

1. プロジェクトのクローンを作成します。

$ git clone https://github.com/FirebaseExtended/MLKit-ARKit.git

2. ポッドをインストールし、.xcworkspace ファイルを開いて Xcode でプロジェクトを確認します。

1. $ cd MLKit-ARKit
2. $ pod install --repo-update
3. $ open MLKit-ARKit.xcworkspace

3. サンプルアプリに Firebase ML Kit を設定します。

1. アプリに Firebase を追加する手順を行います。
2. iOS プロジェクトのバンドル ID として「com.google.firebaseextended.MLKit-ARKit」を指定します。
3. アプリに Firebase を追加する際に生成された GoogleService-Info.plist ファイルをダウンロードします。
4. Xcode で、アプリに GoogleService-Info.plist ファイルを（Info.plist の次に）追加します。

この時点で、アプリはオンデバイスの認識を利用できるようになるはずです。

4. （省略可能）サンプルアプリに Cloud Vision API を設定します。

1.Firebase プロジェクトを Blaze プランに切り替えます。
Cloud Vision API を使用できるのは Blaze レベルのプロジェクトのみです。以下の手順でプロジェクトを Blaze プランに切り替えて従量課金制のお支払いを有効にしてください。
  1. Firebase コンソールでプロジェクトを開きます。
  2. 左下で現在選択されている Spark プランの横にある [変更] リンクをクリックします。
  3. Blaze プランを選択し、Firebase コンソールに表示される手順に沿って請求先アカウントを追加します。
    ★ クラウドのラベル検出機能は、1 か月あたり最初の 1,000 ユーザーまで無料で利用できます。料金設定について詳しくは、こちらをクリックしてください。
2.Firebase コンソールの [ML Kit] セクションに移動し、上部にある [クラウドベースの API を有効化] をオンにします。

以上の設定で、アプリでは Cloud Vision API から得られたより正確な結果をラベルに適用できるようになります。

Posted by Hak Matsuda - Developer Relations Team
Share on Twitter Share on Facebook

Steve Ganem
プロダクト マネージャー

元の記事は、Google マーケティング プラットフォーム ブログに投稿されました。

 企業がマーケティング予算の最善の投資先を判断するときに決め手となるのが、ウェブとアプリという両方の場所でユーザーの行動を把握することです。多くの場合、ユーザーが最初に触れるのはウェブサイトですが、ほとんどの企業では、ユーザーがより多くの時間を費やすのはアプリでしょう。そのためマーケティング担当者は、アプリ解析によってユーザーに関する洞察を得たうえで、アプリの内部と外部の両方で対策をとる必要があります。
かねてより、私たちのアプリ解析ソリューションである Firebase 向け Google アナリティクスは、イベント、端末の種類などの項目からユーザーリストを作成する機能を提供してきました。しかし、ユーザーの行動は時間とともに変化するので、これらの基準は網羅的ではなく、動的でもありませんでした。
そこで、いくつかの大きなアップデートを行い、ユーザーリストの作成機能を改善しました。これにより、対象となるアプリのユーザーリストを簡単かつ精度よく特定できるようになります。

  1. ユーザーリストの動的評価: ユーザーリストは、デフォルトで動的になります。つまり、アナリティクスが即座に基準を満たすユーザーを自動的に追加し、満たさなくなったユーザーを自動的に削除します。リストを設定しておけば何もしなくてもユーザーが加わるので、手間をかけて定期的に再評価を行う必要はなくなります。
  2. ユーザーリストからの除外: 除外基準を追加すると、ユーザーリストの精度をさらに高めることができます。たとえば、ショッピング カートに品物を追加した人のうち、購入した人を除外したユーザーのリストを作成することができます。
  3. 有効期間: 「直近 30 日間にコンバージョンしたユーザー」というように、ユーザーリストに有効期間も追加できるようになりました。そのため、ユーザーリストやメッセージングを常に最新かつタイムリーに保つことができます。
以上の新しいツールによって、ユーザーリストは今までよりもさらに強力で柔軟、かつ行動につながるものになり、皆さんの分析をアプリのユーザーやその活動に確実に反映できるようになります。私たちは、2019 年も Firebase 向け Google アナリティクスのユーザーリスト作成機能の改善を続け、さらに精度を上げたユーザーリストを作成する方法を提供したいと考えています。

対象のユーザーリストが特定できたら、早速行動を
ユーザーについての理解が深まったら、変化するニーズに応じてユーザーの好みにあった体験を提供することもできます。たとえば、プッシュ通知や Firebase の Remote Config、Google 広告のカスタマイズ広告などが利用できます。

例として、e コマースアプリについて考えてみましょう。前述の高度なユーザーリスト機能を使うと、初めてアプリを使って カートに品物を追加したにもかかわらず、購入はしなかったユーザーのリストを作成することができます。さらに、30 日間でそのような行動をとったユーザーだけを含めることもできます。

カートの品物を購入しなかった新規ユーザーの動的ユーザーリストを作ってみる。
このユーザーリストを使うと、アプリで行った操作にぴったりのメッセージを使ってアプローチし、アプリ内宣伝やメール通知、パーソナライズド広告を通して購入を呼びかけることができます。ユーザーがアプリに戻ってきて購入を行ったり、30 日間の期限を過ぎたりすると、ユーザーリストの基準を満たさなくなるため、対象外のマーケティングを実施してユーザー エクスペリエンスに悪影響を及ぼすことはなくなります。

動的ユーザーリストを作成できる機能を活用すれば、ユーザーを今まで以上に精度よく把握できます。ユーザーリストの精度が向上すれば、ユーザーの道のりがよくわかるようになり、自信をもってマーケティング活動に投資できて、よい結果が生まれます。ユーザーに満足してもらうことで、皆さんのアプリも拡大します。

Reviewed by Khanh LeViet - Developer Relations Team
Share on Twitter Share on Facebook


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook

Cross-Origin resource policy

Cross-Origin-Resource-Policy レスポンス ヘッダーを使用すると、http サーバーは、返すリソースがクロスオリジンまたはクロスサイトで埋め込まれないようにブラウザに依頼することができます。これは、Cross-Origin Read Blocking（CORB）機能の補助機能で、CORB の対象にならないリソースの保護に特に便利です（CORB で保護できるのは、HTML、XML、JSON のみです）。

現在、Cross-Origin-Resource-Policy は、Spectre 攻撃や侵害されたレンダラーからイメージを守ることができる唯一の方法です。
CSS リダイレクトはクロスオリジン

仕様に準拠するため、（a）ネットワーク エラーにより読み込みに失敗したスタイルシート、（b）クロスオリジンから同じオリジンにリダイレクトされて戻ってきた後に読み込まれたスタイルシートは、クロスオリジンと見なされます。

WebContents が覆い隠されている場合、document.visibilityState を “hidden” に設定

Chromium の WebContents Occlusion 機能のおかげで、Page Visibility API がウェブページの表示状態を厳密に反映するようになります。ページが覆い隠されている場合も同様です。具体的には、ブラウザのタブやウィンドウが 1 つまたは複数のウィンドウに覆われている場合、document.visibilityState の値が “hidden” になります。

現時点で WebContents Occlusion 機能がサポートされているのは、Chrome OS と macOS のみです。Windows のサポートは、現在対応中です。

DOMMatrixReadOnly.scaleNonUniform()

scaleNonUniform() 関数は、現在の行列に対して右側から非均一スケール変換を乗算し、結果の行列を返します。従来の SVGMatrix との互換性を維持するため、再加算が行われています。非均一スケーリングとは、少なくとも 1 つのスケーリング要素が他と異なる変換を指します。非均一スケーリングを使うと、たとえば長方形を正方形や平行四辺形に変換できます。

EME 拡張: HDCP ポリシー チェック

アプリケーションは、最適なユーザー エクスペリエンスを実現する解像度で再生できるように、特定の HDCP ポリシーの強制が可能かを問い合わせることができるようになります。試してみたいデベロッパーの皆さんのために、サンプルが公開されています。

GamePad API: GamepadButton の touched 属性

GamePad API からゲームパッド ボタンの touched 状態を取得できるようになりました。これは、ボタンが押されているかどうかとは別に、指がボタンの上にあるかどうかを示す属性です。

link rel=preload の imagesrcset 属性と imagesizes 属性

<link> 要素が imagesrcset プロパティと imagesizes プロパティをサポートするようになりました。これらは、HTMLImageElement の srcset 属性と sizes 属性に対応するものです。  この機能を使う場合は、<link> 要素に preload キーワードと image キーワードを含める必要があります。次に例を示します。

<link rel="preload" as="image" href="pic400.jpg" imagesizes="100vw"
imagesrcset="pic400.jpg 400w, pic800.jpg 800w, pic1600.jpg 1600w">

暗黙的なルート スクローラー

暗黙的なルート スクローラーを使うと、ビューポートを占めているスクローラー（iframe や div）でドキュメントレベルのスクロール（URL バーの表示や非表示、オーバースクロール時のグロー、回転の防止など）ができるようになります。この機能には API はないので、標準化の過程には含まれません。Chrome は、ページが主に非ドキュメント スクローラーに含まれているかどうかを判断して、ドキュメント スクロール UX をスクローラーに委譲しようと試みます。

これは、以前に提案された rootScrollers API の暗黙版です。

Shadow host の ::part 疑似要素

Chrome の shadow host で ::part() 疑似要素がサポートされました。これにより、shadow host が shadow tree の一部の要素をページの外側に公開して、スタイルの設定に利用できるようになります。

PerformanceObserver.supportedEntryTypes

PerformanceObserver.supportedEntryTypes を使うと、ウェブブラウザで実装されている PerformanceEntry のタイプの特徴を検出できます。たとえば、Chrome でこれを使用すると、次のような内容をコンソールに表示できます。

["longtask", "mark", "measure", "navigation", "paint", "resource"]

CSS および XSLT スタイルシートでレスポンス URL をベース URL として使用する


通常、ウェブの URL は、ドキュメントのベース URL からの相対パスで表されます。つまり、ページ /hello/ に <img src="world.jpg"> が含まれている場合、イメージは /hello/world.jpg から読み込まれます。

これにはいくつかの例外がありますが、最も一般的なのは CSS です。スタイルシートでは、背景画像などの URL はスタイルシートの「レスポンス URL」からの相対パスで表されます。

「レスポンス」という部分の違いは重要です。ページに <link rel="stylesheet" href="/styles.css"> が含まれており、/styles.css が /foo/styles.css にリダイレクトされると、スタイルシート内の URL は /foo/styles.css からの相対パスになります。この場合、リクエスト URL とレスポンス URL は別になり、レスポンス URL がベース URL として使われます。

Service Worker が間に入ると、Chrome はこれをうまく処理できず、リクエスト URL を CSS のベース URL として使っていました。Chrome 73 ではこの問題が修正され、正しいレスポンス URL を使うようになります。

この変更は、以下のリソースタイプに適用されます。

XHR: responseURL とドキュメントにレスポンス URL を使用する

XHR の responseURL プロパティは、レスポンス URL を提供するものです。

多くの場合、リクエスト URL とレスポンス URL は同じですが、Service Worker は別の場所からのレスポンスを返すこともできます。また、リダイレクトが行われると、リクエスト URL とレスポンス URL は異なります。

Service Worker が XHR リクエストをインターセプトした場合、Chrome は誤って responseURL にリクエスト URL を設定していました。Chrome 73 ではこの問題が修正され、responseURL に正しいレスポンス URL が設定されるようになります。

WebRTC のアップデート

RTCConfiguration.offerExtmapAllowMixed

RTCConfiguration.offerExtmapAllowMixed() に Boolean 型プロパティが追加され、セッション記述プロトコル（SDP）のオファーにおいて extmap-allow-mixed 属性を有効にできるようになります。

SDP の extmap-allow-mixed 属性は RFC8285 で定義されており、このプロパティを true に設定すると、この属性が SDP オファーに含まれるようになります。SDP の extmap-allow-mixed 属性は Chrome 71 以降でサポートされますが、下位互換性の問題から、この属性はデフォルトで SDP オファーに含まれていませんでした。

このプロパティは、純粋に暫定的なものです。最初はデフォルトでオフになる予定ですが、クライアントによるコードの更新が十分に達成されたら、デフォルトでオンになるように変更したいと考えています。やがて下位互換性が必要なくなり、これを完全に削除できるようになることを期待しています。

RTCRtpReceiver.getParameters()

新しく追加された RTCRtpReceiver.getParameters() メソッドは、RTCRtpReceiver オブジェクトのトラック デコーディング パラメータを返します。これには、通話のネゴシエーションに使われるコーデックや RTP ヘッダーリスト、RTCP 情報、レイヤー数が含まれています。

このメソッドは、RTCRtpSender.getParameters() に似ており、同じような通話情報を提供しますが、対象は受信側になります。通話のパラメータを変えることはできません。

RTCRtpReceiver.getSynchronizationSources()

新しく追加された RTCRtpReceiver.getSynchronizationSources() メソッドは、音声および動画受信者の RTP パケットの直近の再生タイムスタンプを返します。これは、どのストリームがアクティブであるかをリアルタイムに判断する際に便利です。オーディオ メーターや、参加しているストリームのうちアクティブなものを優先して UI に表示したい場合などに利用できます。

RTCRtpContributingSource をインターフェースからディクショナリに変更

仕様では、RTCRtpContributingSource をディクショナリにすることが求められていますが、今まではインターフェースとなっていました。今回の変更で、RTCRtpContributingSource のプロトタイプはなくなり、getContributingSources() を呼び出すごとに新しいオブジェクトのセットが作られるようになります。

Atomics.wake() の名前が Atomics.notify() に変更

Atomics.wake() メソッドの名前が Atomics.notify() に変更されます。これは、Atomics.wait() で停止していた Worker を復帰させるための低レベル関数です。これは、wait と wake という名前が似ていることによる混乱を緩和するための仕様変更に準拠する措置です。

変換リスト補間

Chrome は、行列補間フォールバックが使われるケースを減らすために、CSS 変換処理の方法を改善してきました。補間とは、中間的な変換を行うことを指します。CSS ルールを解釈する際、補間を行うために行列へのフォールバックが必要になる場合があり、それによってウェブ デベロッパーの意図しない視覚効果が引き起こされる可能性があります。この問題を軽減するため、そのような発生状況を減らすように仕様が変更されました。

相互運用性の改善

シャドウのぼかしの半径が仕様に準拠

従来より、Blink では CSS 仕様と Canvas2D 仕様の両方でぼかしの半径の解釈が異なっており、Blink のシャドウは期待される範囲の約半分しか覆っていません。

今回の変更により、仕様で定められているとおり、ガウスのぼかしのシグマがぼかしの半径の 1/2 として計算されるようになります。現在の Blink のシャドウ実装は、FireFox および Safari と一致します。

URL フラグメント識別子のアイソモーフィック デコードの削除

Chrome でフラグメント ID のある URL を開くと、%xx がデコードされてアイソモーフィック デコードが適用され、その後、場合によってデコード結果の ID を持つ要素を探そうとします。たとえば、ユーザーが example.com/#%F8%C0 を開くと、Chrome は以下の処理を行います。
  1. ページで id="%F8%C0" の要素を検索する
  2. 見つからなかった場合、ページで id="&#xF8;&#xC0;" の要素を検索する
他のブラウザはこの処理を行っておらず、標準でも定義されていません。バージョン 73 以降では、Chrome もこの処理を実行しなくなります。

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

WebSQL での EXPLAIN および REINDEX のサポートの削除

EXPLAIN の出力は SQLite のバージョンをまたいで安定していることが保証されていないので、デベロッパーはこれを信頼することはできません。REINDEX が役立つのは照合順の定義が変わった場合のみですが、Chrome はビルトインの照合順しか使いません。これらの機能は、両方とも削除されています。

サンドボックス化された iframe での「ドライブバイ ダウンロード」のサポート終了

Chrome では、サンドボックス化された iframe でユーザーの操作なしに行われるダウンロード（「ドライブバイ ダウンロード」）が非推奨となっています。なお、この制限は、サンドボックス属性リストに allow-downloads-without-user-activation キーワードを含めることで解除することもできました。今回の変更により、コンテンツ プロバイダは悪意のあるダウンロードや不正なダウンロードを制限できます。

ダウンロードは、システムにセキュリティ脆弱性をもたらす場合があります。Chrome およびオペレーティング システムでは追加のセキュリティ チェックが行われますが、サンドボックス化された iframe でのダウンロードをブロックすることも、サンドボックスを支える一般的な考え方と一致するものと考えています。セキュリティの懸念は別としても、新しいページを開いたときに自動的にダウンロードが始まったり、クリック後に不自然にダウンロードが始まったりするよりは、同じページでクリックをトリガーとしてダウンロードする方が快適なユーザー エクスペリエンスとなるでしょう。

この機能の削除は、Chrome 74 で行われる予定です。

Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook