[go: nahoru, domu]

この記事 Justin Schuh - Chrome エンジニアリング ディレクターによる Chromium Blog の記事 "Building a more private web: A path towards making third party cookies obsolete" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 8 月に、一連のオープンな標準を作成してウェブのプライバシーを抜本的に強化する新しい取り組み(プライバシー サンドボックスと呼ばれています)についてお知らせしました。このオープンソースによる取り組みの目的は、パブリッシャーをサポートしつつ、ユーザーのためにウェブのプライバシーとセキュリティを強化することです。本日(元記事公開当時)は、この計画の最新情報をお知らせするとともに、ウェブ ブラウジングのプライバシー強化に向けてご協力をお願いします。

初めてウェブ コミュニティにお話しした後の継続的なフィードバックから、私たちはプライバシー サンドボックスのようなプライバシーを保護するオープン標準メカニズムは、広告によってサポートされる健全なウェブを維持できること、そして将来的にサードパーティ Cookie が使われなくなることを確信しています。このアプローチがユーザー、パブリッシャー、広告主のニーズに対処でき、回避策を防ぐことができるツールを開発できたら、Chrome でのサードパーティ Cookie のサポートを段階的に廃止する予定です。私たちは、この計画を 2 年以内に行うことを目指しています。しかし、これは私たちだけでは実現できません。そのため、この案を推進するエコシステムが必要です。最初のオリジン トライアルは、今年中に開始する予定です。まずは、コンバージョンの測定から始め、続いてパーソナライゼーションに対応したいと考えています。

ユーザーは、透明性や個人データの使用方法に関する選択と制御など、プライバシーの強化を求めています。ウェブのエコシステムが、この高まる要求を満たすように進化しなければならないのは明らかです。ブラウザの中には、サードパーティの Cookie をブロックすることでこの懸念に対応しているものもあります。しかし私たちは、それが意図しない形でユーザーとウェブのエコシステムの両方に悪影響を与える結果になると考えています。広告によってサポートされている多くのウェブサイトのビジネスモデルを過小評価し、Cookie に対して洗練されていない
アプローチをとることになれば、フィンガープリンティング(プライバシーの侵害につながる可能性がある Cookie に代わる方法)などの不透明な技術の使用が増加し、実際にはユーザーのプライバシーや制御が減少することになります。コミュニティとしての私たちは、それよりもよい方法を実現できるはずです。そして、それを実現しなければなりません。

幸運にも、W3C などのフォーラムには、プライバシー サンドボックスの土台となるメカニズムは重要なユースケースに相当するもので、それが正しい方向に向かっているという肯定的なフィードバックが寄せられています。このフィードバックや、標準化に参加している他の団体からの関連提案から、私たちはこの領域のソリューションは問題なく適用できると確信しています。また、標準コミュニティと連携し、代替手段を作って FlashNPAPI を段階的に廃止した経験は、私たちが協力して複雑な課題を解決できることを証明しています。

また、現在のウェブ技術の安全性とプライバシーをさらに強化するための作業も続ける予定です。以前にもお知らせしたように、Chrome は SameSite ラベルを含まない Cookie をファーストパーティ専用として扱い、サードパーティ用のラベルが付いた Cookie には HTTPS を必須とすることで、2 月から安全でないクロスサイト トラッキングを制限します。これにより、サードパーティ Cookie がさらに安全になり、ユーザーはブラウザ Cookie を厳密に制御できるようになります。同時に、隠されたトラッキングや回避策を検出して軽減する技術を開発しており、このような詐欺的でプライバシーの侵害につながる技術を阻止する新しいフィンガープリンティング対抗策をリリースします。この対策は、今年中に導入したいと考えています。

私たちは、ブラウザ、パブリッシャー、デベロッパー、広告主がこういった新技術を試してさまざまな状況で問題なく動作するかテストし、広告の選択や測定、サービス拒否攻撃(DoS)の防止、スパムや詐欺への対策、フェデレーション認証などのサポート実装を開発する機会を持てるように、エコシステム全体で積極的に連携しています。

皆さんとともに信頼性が高く持続可能なウェブを作ることを楽しみにしています。そのためには、皆さんの継続的な関与が必要です。ウェブ標準コミュニティの提案が皆さんのニーズに合致するように、ぜひ GitHub からフィードバックをお送りください。ニーズを満たしていない場合は、GitHub やメールで W3C グループに問題を送ってください。ウェブでビジネスをしている方は、技術ベンダーがこのプロセスに関与していることを確認し、皆さんの利益を代表するトレード グループとフィードバックを共有してください。

ウェブ ブラウジングのプライバシーを強化する取り組みの進展については、今後も投稿を通してお知らせいたします。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事はプロダクト マネージャー、PJ McLachlan による Chromium Blog の記事 "Introducing quieter permission UI for notifications" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


ウェブの通知機能を使うと、ユーザーがウェブサイトを開かなくても、重要なアップデートを受け取ることができます。メッセージング、カレンダー、メール クライアント、ライドシェア、ソーシャル メディア、配送サービスなど、通知はさまざまなアプリケーションにとって欠かせない機能です。

多くのウェブサイトは、ユーザーの状況を踏まえた適切なタイミングではなく、初めてアクセスした際に通知許可をリクエストしています。そのため、残念なことに、通知は不満の種にもなっています。一方的な許可のリクエストをすると、ユーザーのワークフローが中断され、結果的にユーザー エクスペリエンスが損なわれます。

ユーザーにとって便利なサービスとしての通知機能を保護するため、Chrome 80 から特定の条件において、ユーザーの操作を遮りにくく、邪魔にならない新しい通知許可 UI を表示してリクエストをするようになります。Chrome 80 がリリースされると、ユーザーは [設定] から手動で新しい UI をオプトインできるようになります。さらに、この邪魔にならない UI は、以下の 2 つの条件に当てはまるユーザーに対して自動的に有効化されます。1 つ目は、通知許可リクエストをブロックすることが多いユーザー、2 つ目はオプトインされる率が非常に低いサイトです。この自動有効化機能はリリース後に徐々に有効化され、ユーザーやデベロッパーからのフィードバックも集めます。

2020 年のうちに、ウェブ通知を広告、マルウェア、詐欺などに使っている悪意のあるウェブサイトに対し、追加の制限を課すことを計画しています。この点については、今後のブログ投稿で詳しく説明します。


邪魔にならない UI の概要

邪魔にならない UI(PC およびモバイル)


邪魔にならない UI は、PC とモバイルの両方で利用できます。この UI が初めてユーザーに表示されるときは、新機能について説明するプロダクト内ヘルプ ダイアログ(いつでも閉じることができます)も表示されます。

有効化とオプトアウト

ユーザーは、邪魔にならない UI を 3 つの方法で有効化できます。

手動での有効化(とオプトアウト)

PC またはモバイルで通知設定から手動で有効化


ユーザーは、邪魔にならないプロンプトを手動で有効化できます。また、完全に無効化することもできます。有効化するには、[設定] > [サイトの設定] > [通知] で [通知を送信するかどうかの確認をサイトに許可する] トグルをオンにしてから、[静かな方法で通知する(割り込み通知を行わない)] チェックボックスにチェックを入れる必要があります。

ほとんど通知を受け入れないユーザーに対する自動有効化

さまざまなウェブサイトで繰り返し通知を拒否したユーザーに対しては、邪魔にならない通知 UI が自動的に有効化されます。

許可の受け入れ率が低いサイトでの自動有効化

許可の受け入れ率が非常に低いサイトでは、邪魔にならないプロンプトが自動的に有効化されます。ユーザー エクスペリエンスが改善されると、自動的に有効化が解除されます。サイトごとの通知許可受け入れ率に関する情報は、2020 年第 1 四半期の Chrome ユーザーエクスペリエンス レポートから入手できるようになる予定です。

デベロッパーの推奨事項

まず、ウェブ デベロッパーの皆さんには、chrome://settings/content/notifications から邪魔にならない通知許可 UI を手動で有効化し、この UI によるサイトの許可リクエスト フローをテストすることをお勧めします。記事の執筆時点で、この機能は Canary、Dev、Beta の各チャンネルに徐々にロールアウトされており、Chrome 80 以降では chrome://flags/#quiet-notification-prompts から強制的に有効化できるようになります。

次に、ユーザーに通知許可をリクエストする際のベスト プラクティスに従うことをお勧めします。多くの場合、初回アクセス時にウェブ通知への登録をリクエストするウェブサイトでは、受け入れ率がとても低くなります。そうする代わりに、ユーザーが状況を理解して通知を受け取るメリットを認識するまで待ってから、許可プロンプトを表示することをお勧めします。ウェブサイトによっては、ネイティブの許可プロンプトを表示する前に、コンテンツ エリアに事前にプロンプトが表示されています。ユーザーの操作が妨げられる場合、このアプローチも推奨できません。状況に応じて適切なタイミングで許可をリクエストするサイトは、直帰率が低く、コンバージョン率が高くなります。

ユーザー許可の UX を改善したい方は、こちらの 5 分の動画をご覧ください。ユーザー許可受け入れ率の改善について説明しています。また、許可をリクエストする際のベスト プラクティスもお読みください。

Reviewed by Eiji Kitamura - Developer Relations Team



Google Play Indie Games Festival 2020 への応募受付を開始しました。応募締め切りは 3 月 2 日 23:00 (日本標準時)です。また、詳細なスケジュールと応募条件についてお知らせします。

Google Play が主催する Indie Games Festival 2020。日本では 2018 年から開催しており、本年が 3 回目となります。本イベントには、日本で活動する個人またはグループ、または社員数が 50 名以下のゲーム開発会社の皆さまがご応募いただけます。


Google Play Indie Games Festival 2020 応募 :

応募フォームはこちら

Web サイトで必ず応募条件をご確認ください。


スケジュール :

2020 年 3 月 2 日 23:00 (日本標準時)応募期間終了
2020 年 3 月 下旬 トップ 20 発表
2020 年 4 月 25 日 ファイナルイベント

※オンラインによる Top 20 へのユーザー投票は、本年は実施しません。



応募対象タイトル :

応募対象は、日本にて活動する、個人またはグループのゲーム開発者、または社員数が 50 名以下のゲーム開発会社で、Google Play に 2019 年 5 月 7 日以降に公開されたゲームです。オープンベータ版での応募も可能ですが、ゲームとして評価できる品質であり、遅くとも 2020 年末までのローンチを目指している必要があります。



ファイナルイベントについて :

4 月 25 日開催のファイナルイベントでは、トップ 20 タイトルを展示。審査員と一般参加者による投票によりトップ 10 を選出。その後トップ 10 タイトルを手がけたデベロッパーによるゲームの紹介があり、審査員と一般参加者によりトップ 3 が決定され、各賞品の授賞式が行われます。

ファイナルイベントの一般参加者としての観覧応募はこちらより受け付けています。


開催概要
日時 : 4 月 25 日(土)10:00〜18:00
場所 : 東京都内

最新情報は Web サイトでご確認いただけます。


Posted by Hidenori Fujii - Google Play Developer Marketing APAC

この記事は Jeffrey Jose による The AMP Blog の記事 "CCPA support in AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

投稿者: Google の AMP Project プロダクト マネージャー、Jeffrey Jose


カリフォルニア消費者プライバシー法(CCPA)は、データ プライバシーに関する新しい法律で、カリフォルニア州の住民のさまざまな権利を保障するものです。この法律は、カリフォルニアでビジネスをしており、収益やデータ処理などに関する複数の基準のいずれかに当てはまる企業に適用されます。

AMP 同意フレームワークのアップデート
サイト運営者からのフィードバックに基づき、AMP 同意フレームワークをアップデートし、サイト運営者が CCPA に準拠するために必要と思われる同意を得られるようにしました。今回の新しいアップデートによって、サイト運営者は複数の同意プロンプトを含めて、ユーザーの場所に基づいて適切なプロンプトを呼び出せるようになります。

複数のサーフェスをまたぐ同意
複数のサーフェスでユーザーの同意を同期したいサイト運営者は、ユーザーの同意情報をサーバー側に保存し、checkConsentHref 属性を通してその情報を <amp-consent> に公開できます。最初にエンドポイントを確認し、その応答によってユーザーの同意プロンプトを表示するかどうかを決めるように AMP を設定することも可能です。さらに、取得済みのユーザー同意情報を、サーバーから、ページに設定されている広告やアナリティクスのベンダーに渡すこともできます。

AMP ストーリーのサポート
AMP ストーリーでは、サイト運営者がストーリー内に CCPA オプトアウト ページへのリンクを作成し、ユーザーの同意を集めることができます。
リファレンス ドキュメントサンプルコードを含む amp.dev もアップデートし、シナリオの例を紹介しています。

今後の予定
さらに簡単に開発できるように、<amp-geo> を拡張し、米国の州レベルでユーザーを検知できるようにすることを計画しています。いつものように、新しいアイデアをお持ちの方は、ぜひ Issue に投稿してください。ユーザー制御に基づく AMP 拡張機能の動作をカスタマイズしたいベンダーの方は、貢献ガイドラインに従って開始してください。

Reviewed by Chiko Shimizu - Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 80, Content Indexing, ES Modules and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2019 年 12 月 19 日の時点で Chrome 80 はベータ版です。

Content Indexing


プログレッシブ ウェブアプリは、Cache Storage APIIndexedDB を使って、イメージ、動画、記事などのコンテンツをオフライン アクセス用に保存できます。しかし、ユーザーはどのようにしてこのコンテンツを見つけるのでしょうか。ネットワークが利用できなくてもコンテンツを参照したり使用したりできることを、どうやって知るのでしょうか。

Content Indexing API は、ウェブアプリがすでにキャッシュしているコンテンツのメタデータを提供します。具体的には、保存されたメディアを表示する HTML ドキュメントの URL を保存します。この新しい API を使えば、リソースの追加、一覧表示、削除ができます。ブラウザはインデックス内にあるこの情報を使い、オフライン対応コンテンツのリストを表示できます。Chrome 80 では、そのリストはこのように表示されます。

Content Indexing API は、Chrome 80 から Chrome 82 までのオリジン トライアルです。API の詳細については、Content Indexing API を使用した実験をご覧ください。登録に関する情報や、本リリースで開始された他のオリジン トライアルのリストについては、オリジン トライアルのセクションをご覧ください。

Web Worker の ECMAScript Module

Web Worker は、大半のブラウザで 10 年以上前から利用できます。その結果、モジュールをワーカーにインポートする方法である importScripts() は、もはや最新技術とは見なされなくなっています。この機能は、インポートするスクリプトを取得して評価する間、ワーカーの実行をブロックします。さらに、スクリプトをグローバル スコープで実行するので、名前の衝突やそれに関連する問題を引き起こす可能性があります。

そこで導入されるのが Module Worker です。Worker のコンストラクタは、type オプションで値 "module" をサポートするようになります。これにより、スクリプトの読み込みと実行が <script type="module"> と同じ動作になります。


const worker = new Worker('worker.js', {
  type: 'module'
});

Module Worker は、標準の JavaScript のインポートと遅延読み込み用のダイナミック インポートをサポートしており、ワーカーの実行をブロックしません。背景や詳細については、Web Worker の ES Module をご覧ください。

オリジン トライアル

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

Contact Picker の新しいプロパティ

このバージョンの Chrome には、Contact Picker API が搭載されています。Chrome 77 で開始されたオリジン トライアルは終了となります(詳細は後述)。同時に、この API に機能を追加した新しいオリジン トライアルが開始されます。ユーザーに連絡先の選択をリクエストする前に、アプリはどのデータを返してもらいたいかを指定しなければなりません。現時点で利用できるのは、連絡先の名前、メールアドレス、電話番号のみとなります。新しいオリジン トライアルでは、これにユーザーの郵送先住所('address')とイメージ('icon')が加わります。

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

Mixed Contents の自動アップグレード

現在の Chrome は、HTTPS サイト内の HTTP コンテンツを自動アップグレードしています。これは、安全なコンテンツを利用できない場合に、HTTP にフォールバックせずに URL を HTTPS に書き換えることによって実現しています。このバージョンの Chrome では、オーディオと動画のコンテンツのみがそのように扱われています。

Compression Streams

JavaScript で、ストリームを使って gzip や deflate 圧縮を実行できるようになります。対応しているのは、CompressionStream と DecompressionStream の 2 つのインターフェースです。

この機能を使わずにストリーム データを圧縮することも可能ですが、zlib などの一般的なライブラリは複雑で使いづらいものです。デベロッパーは Compression Streams を使って簡単にデータを圧縮できるので、アプリケーションに圧縮ツールをバンドルする必要はなくなります。

Contact Picker API

Contact Picker API は、Android Chrome 用の新しいオンデマンド ピッカーです。これを使うと、ユーザーは連絡先リストのエントリを選択し、その詳細情報の一部をウェブサイトと共有できます。ユーザーは、共有したいときに共有したい情報のみを共有し、友だちや家族と簡単につながることができるようになります。詳細については、ウェブ用の連絡先ピッカーをご覧ください。さらに、新しいオリジン トライアルでは、ContactsManager.getProperties() で返されるプロパティが追加されています。詳細については、上記のオリジン トライアルのセクションをご覧ください。

Cookie のアップデート

Chrome 51 と Firefox 60 に SameSite 属性が導入され、Cookie を同一サイト(ファースト パーティとも呼ばれます)のコンテキストに制限するかどうかをサイト側で宣言できるようになります。これにより、クロスサイトリクエスト フォージェリ(CSRF)のリスクを低減できます。

Chrome 80 では、以下に記述する下位互換動作が削除されます。この機能の詳細については、SameSite Cookie の説明をご覧ください。

SameSite 属性のデフォルト 'None' の禁止

SameSite 属性のデフォルトは Lax になります。これは、トップレベルのナビゲーションをする場合のみ、他のサイトで Cookie が利用できることを意味します。Chrome で当初実装されていたように、SameSite 属性のデフォルトは None であり、これが実質的にウェブの現状でした。Cookie には有効なクロスサイト ユースケースがありますが、サイト所有者がクロスサイト Cookie の使用を許可したくない場合に、その意図を宣言したり強制したりする方法はありませんでした。

安全でないコンテキストでの値 'None' の禁止

SameSite 属性が None に設定された場合、Chrome は Secure 属性の存在も要求するようになります。Secure 属性は、追加される Cookie を HTTPS などの安全なプロトコル経由でのみ送信することを求めます。

CSS の改善

line-break: anywhere

line-break: anywhere 宣言をすると、すべての印字文字単位にソフトラップが適用されるようになります。これには、句読点文字や保持されるスペース、単語の中なども含まれます。この宣言をすると、GL、WJ、ZWJ 文字クラス(UAX 14 を参照)による文字や word-break プロパティによる強制を含め、改行に関するすべての禁止事項は無視されます。

overflow-wrap: anywhere

overflow-wrap: anywhere 宣言を使うと、行内に他の受け入れ可能な改行ポイントがない場合に、そのままでは改行されない文字列を任意の場所で改行することができます。さらに、min-content 固有サイズを計算する際には、anywhere によって生じるソフトラップ適用の可能性も考慮されます。

暗号化されたメディアのデコード

暗号化されたメディアで MediaCapabilities.decodingInfo()  の機能を利用できるようになります。decodingInfo() メソッド(複数のブラウザで利用可能)を使うと、ウェブサイトがクライアントのデコード機能に関する追加情報を得られます。これにより、ユーザーが詳しい情報に基づいてメディア ストリームを選択できるようになり、利用可能な帯域幅や画面サイズに基づいてスムーズかつ電力効率よく動画をデコードするなどのシナリオを実現できます。

Web Payments での配送先住所と連絡先情報の委譲

Payment Handler API で、ブラウザが配送先住所と支払者の連絡先情報の扱いを支払いハンドラに委譲できるようになります。支払いアプリはブラウザよりも正確な情報を保持している可能性があるので、配送先住所と連絡先情報の収集を支払いハンドラに委譲すると、ユーザー エクスペリエンスの向上につながる場合があります。また、ブラウザは、最初に支払いシート UI を表示して配送先住所や支払者の連絡先情報を収集することなく、支払いハンドラのウィンドウを直接表示できるので、チェックアウト手順を 1 段階少なくすることができます。Chrome でのその他の Payment Request API / Payment Handler API の技術的なアップデートについて最新情報を得るには、paymentrequest@chromium.org に参加してください

Fetch Metadata の宛先ヘッダー

Chrome は Sec-Fetch-Dest HTTP リクエスト ヘッダーをサポートします。このヘッダーは、リクエストの宛先をサーバーに公開し、サーバーがセキュリティ上の判断をする際に参考となる情報を提供します。仕様には、設定可能な値のリストが記載されています。

HTMLVideoElement.getVideoPlaybackQuality()

このメソッドは、動画再生パフォーマンスに関する情報を取得します。このような情報を使用して、ビットレート、フレームレート、または解像度を変更し(上げるまたは下げる)、ユーザー エクスペリエンスを向上できます。

画面外描画キャンバスが getTransform() をサポート

OffscreenCanvasRenderingContext2D getTransform() をサポートするようになりますCanvasRenderingContext2D のメソッドと同じように、このメソッドから現在コンテキストに適用されている変換行列を取得できます。

SVG ファビコンのサポート

Chrome で、SVG イメージをファビコンに使用できるようになります。拡大可能な形式をファビコンに使用できるため、ウェブサイトやアプリのリソースを削減できます。たとえば、手動で調整した 1 つ(または複数)の小さいサイズのアイコンをウェブサイトに配置し、拡大可能なアイコンを使ってすべてに対応できます。

テキスト URL フラグメント

ユーザーや作成者は、URL で提供されるテキスト フラグメントを利用してページの特定の部分にリンクできるようになります。ページが読み込まれると、ブラウザは対象のテキストをハイライト表示し、フラグメントが表示されるようにスクロールします。たとえば次の URL は、「猫」の Wiki ページを読み込み、text パラメータに記載されているコンテンツにスクロールします。


https://en.example.org/wiki/Cat#:~:text=On islands, birds can contribute as much as 60% of a cat's diet

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

このバージョンの Chrome では、以下のサポートの終了や機能の削除が行われます。現在サポートが終了している機能以前に削除された機能のリストは、ChromeStatus.com をご覧ください。ここに記載されているのは、非推奨化や削除される機能の概要のみです。これらすべての項目の詳細、代替機能、修正点については、Chrome 80 でのサポートの終了と機能の削除を参照してください。

ページ アンロード中のポップアップの禁止

window.open() メソッドを使ってアンロード時に新しいページを開くことができなくなります。ポップアップ ブロッカーはすでにこれを禁止していますが、ポップアップ ブロッカーが有効になっているかどうかにかかわらず、禁止されるようになります。現在のところ、企業は AllowPopupsDuringPageUnload ポリシーフラグを使ってアンロード中のポップアップをブロック解除することができます。このフラグは、Chrome バージョン 82 で削除される予定です。

ページを閉じる際の同期 XMLHttpRequest() の禁止

ユーザーがページを移動するまたは閉じることによってページを離れる際に、同期 XMLHttpRequest() の呼び出しが許可されなくなります。これは、beforeunloadunloadpagehidevisibilitychange に適用されます。

Chrome でページがアンロードされるタイミングで確実にサーバーにデータを送信するには、sendBeacon() または Fetch keep-alive を使うことを推奨します。現在のところ、企業ユーザーは AllowSyncXHRInPageDismissal ポリシーフラグを使ってページ アンロード時の同期 XMLHttpRequest() リクエストを許可できます。デベロッパーは、オリジントライアル フラグ allow-sync-xhr-in-page-dismissal を使って同じことができます。これは、一時的なオプトアウトによる対策です。このフラグは、Chrome バージョン 82 で削除される予定です。

この点の詳細や代替機能については、ページを離れる際の同期 XMLHttpRequest() を改善するをご覧ください。

FTP サポートの非推奨化

Chrome バージョン 72 より、FTP サポート機能の削除が進められています。その理由は、ブラウザからの FTP の利用率はかなり低く、既存の FTP クライアント機能の改善に注力できないためです。また、影響するすべてのプラットフォームで、機能の豊富な FTP クライアントが利用できます。Chrome 80 では、暗号化されていない接続を使用するクライアント機能は、ディレクトリの一覧表示またはリソースのダウンロードに制限されます。詳しくは、Chrome 80 でのサポートの終了と機能の削除をご覧ください。

オリジンクリーンでない ImageBitmap のシリアル化や転送の削除

Chrome 80 以降では、スクリプトからオリジンクリーンでない ImageBitmap オブジェクトのシリアル化または転送を試みると、エラーが発生します。オリジンクリーンでない ImageBitmap とは、CORS ロジックで検証されないクロスオリジン イメージからのデータを含むものです。

プロトコル ハンドリングで安全なコンテキストが必須化

registerProtocolHandler() メソッドと unregisterProtocolHandler() メソッドで、安全なコンテキストが必須となります。これらのメソッドを使うと、クライアントの状態を再構成し、機密データのネットワーク転送を許可できます。

任意の要素に対する -webkit-appearance:button の削除

-webkit-appearance:button が変更され、<button> ボタンと <input> ボタンのみに影響するようになります。button がサポート対象外の要素に指定された場合、その要素はデフォルトの外見となります。その他すべての -webkit-appearance キーワードには、すでにこの制限が課せられています。

Web Components v0 の削除

Web Components v0 が Chrome から削除されます。Web Components v1 API は、Chrome、Safari、Firefox、(間もなく)Edge に搭載されているウェブ プラットフォーム標準です。アップグレードに関するガイダンスは、Web Components のアップデート : v1 API へのアップグレードの猶予期間をご覧ください。今回のサポートの終了は、以下の項目が対象です。
  • Custom Elements v0
  • HTML Imports v0
  • Shadow DOM v0

Reviewed by Eiji Kitamura - Developer Relations Team



AMP 用の Next.js

React サーバーサイド レンダリングによる AMP ページの構築が人気を博し、このユースケースをサポートする機能の追加は必然だったと実感しています。React で特によく使われているフレームワークである Next.js との統合も、そのためです。豆知識 : nextjs.org は完全に AMP で構築されています!

amp-script

今年、ゲームチェンジャーとなる <amp-script> がとうとう皆さんの画面にデビューしました。大きな期待を集めたこのコンポーネントによって、AMP ページにカスタム JavaScript を追加したり、AMP ページと非 AMP ページでコードを共有したり、以前はできなかったものを作成したりできるようになりました。


OpenJS Foundation が AMP を歓迎









OpenJS Foundation への参加決定を発表し、次のオープンガバナンス モデルを明らかにしました。OpenJS Foundation のミッションは私たちのミッションと一致します。この組織によってテクノロジー業界の多様な声が集まり、公正なウェブを作るという私たちの取り組みも推進されるでしょう。

AMP が皆さんの受信トレイに









Gmail で AMP for email がリリースされ、ユーザー ファーストな体験が皆さんの受信トレイでも実現しました。メールの送信者は、スムーズな体験やインタラクティブなコンテンツを作成し、エンゲージメントを向上できるようになりました。AMP for email の仕様には、Outlook や Yahoo Mail などの主要なメール プロバイダも関与しています。こういったパートナーとともにメールのエコシステムを変革できることを楽しみにしています。

新しいコンポーネントは Mail.ru でも利用でき、先行ユーザーはすでにすばらしい結果を残しています。インド最大のホスピタリティ企業である OYO は、AMP for email のテストでコンバージョンが 60% 上昇しました。

AMP Conf の成功に「アリガトウ」

毎年開催しており、今年で 3 回目となる #AMPConf が東京で開催され、500 名近くの方に会うことができました。プロダクトの発表に加え、デザインを刷新した amp.dev をお披露目しました。amp.dev は、コードサンプル、テンプレート、ドキュメントなどがすべて集約されたウェブサイトです。AMPConf2020 の準備はすでに始まっています。次のイベントはどこで開催されるか、注目です。

ニューヨークでの AMP Contributors Summit

10 月初旬には、毎年行われている #AMPCS2019 がニューヨークで開催され、AMP の新機能について約 100 名の貢献者と情報交換をしました。単なる会話にとどまらず、分科会も開催してプロジェクトの改善に取り組み、その過程で AMP にいくつかの驚きをもたらしました。

強力なコミュニティ

1,000 名近くの人が AMP にコードを寄贈し、あらゆる人のために高速でよりよいウェブをデザインすることに協力してくれています。すべての AMP プロジェクトのリポジトリを合わせると、今年だけで 341 名の貢献者が 18,300 回以上の寄贈をしています。








コードの向こうにいる人々

コミュニティは、AMP の進化に大きな役割を果たしています。知っていることを共有し、知らないことを学ぶ場所こそがコミュニティです。そこで、コミュニティのメンバーが AMP を利用してどのように実世界で違いを生んでいるかを理解するため、「コードの向こうにいる人々」シリーズを始めています。

19 回の新しい Roadshow を実施

今年、AMP は 19 回遠征し、世界中で Roadshow をしました。ヨハネスブルグからソウルまで、合わせて 1,600 名の皆さんが AMP を見に来てくださいました。

Roadshow は、デベロッパーが本格的な AMP ウェブサイトを自信を持って構築できるように企画されています。そのため、4 つの主要な柱であるデザイン、インタラクティブ性、DevOps、収益化について徹底的に取り上げ、一歩抜きんでるために必要なものすべてがそろうようになっています。

2020 年の開催場所については、AMP Roadshow ページをご覧ください。自分の住む場所が掲載されていない方は、ぜひお知らせください。私たちはいつも新しい場所を探しています。または、自分でイベントを開催することもできます。素材はすべて提供します。皆さんに必要なのは、来場することだけです!






2020 年のビジョン

今年はすばらしい 1 年でした。高速でユーザー ファーストなウェブをあらゆる人のために作成している皆さんの創造性と献身に感謝します。私たちは、AMP の今後に大きな期待を寄せています。新しい年も、皆さんとともにこの作業を続けてゆけることが楽しみです。AMP 関連のすべてのプロジェクトの最新情報を得て、2020 年の私たちのビジョンを見るには、ニュースレターに登録してください

投稿 : Alex Durán(Google の AMP プロジェクト マーケティング)

Reviewed by Chiko Shimizu - Developer Relations Team
この記事は Alex Durán による The AMP Blog の記事 "AMP 2019 Decoded: Thank You for an Incredible Year" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。






AMP にとって 2019 年は大きな当たり年でした。コミュニティは拡大を続け、ウェブサイト、 メール、ストーリー、広告の全体にわたってすばらしい体験を作り出しています。ここでは年初に戻って、ともに達成してきたすべてのマイルストーンを振り返ります。こちらの動画を見て、以下をお読みください。








AMP 用の Next.js

React サーバーサイド レンダリングによる AMP ページの構築が人気を博し、このユースケースをサポートする機能の追加は必然だったと実感しています。React で特によく使われているフレームワークである Next.js との統合も、そのためです。豆知識 : nextjs.org は完全に AMP で構築されています!

amp-script

今年、ゲームチェンジャーとなる <amp-script> がとうとう皆さんの画面にデビューしました。大きな期待を集めたこのコンポーネントによって、AMP ページにカスタム JavaScript を追加したり、AMP ページと非 AMP ページでコードを共有したり、以前はできなかったものを作成したりできるようになりました。


OpenJS Foundation が AMP を歓迎









OpenJS Foundation への参加決定を発表し、次のオープンガバナンス モデルを明らかにしました。OpenJS Foundation のミッションは私たちのミッションと一致します。この組織によってテクノロジー業界の多様な声が集まり、公正なウェブを作るという私たちの取り組みも推進されるでしょう。

AMP が皆さんの受信トレイに









Gmail で AMP for email がリリースされ、ユーザー ファーストな体験が皆さんの受信トレイでも実現しました。メールの送信者は、スムーズな体験やインタラクティブなコンテンツを作成し、エンゲージメントを向上できるようになりました。AMP for email の仕様には、Outlook や Yahoo Mail などの主要なメール プロバイダも関与しています。こういったパートナーとともにメールのエコシステムを変革できることを楽しみにしています。

新しいコンポーネントは Mail.ru でも利用でき、先行ユーザーはすでにすばらしい結果を残しています。インド最大のホスピタリティ企業である OYO は、AMP for email のテストでコンバージョンが 60% 上昇しました。

AMP Conf の成功に「アリガトウ」

毎年開催しており、今年で 3 回目となる #AMPConf が東京で開催され、500 名近くの方に会うことができました。プロダクトの発表に加え、デザインを刷新した amp.dev をお披露目しました。amp.dev は、コードサンプル、テンプレート、ドキュメントなどがすべて集約されたウェブサイトです。AMPConf2020 の準備はすでに始まっています。次のイベントはどこで開催されるか、注目です。

ニューヨークでの AMP Contributors Summit

10 月初旬には、毎年行われている #AMPCS2019 がニューヨークで開催され、AMP の新機能について約 100 名の貢献者と情報交換をしました。単なる会話にとどまらず、分科会も開催してプロジェクトの改善に取り組み、その過程で AMP にいくつかの驚きをもたらしました。

強力なコミュニティ

1,000 名近くの人が AMP にコードを寄贈し、あらゆる人のために高速でよりよいウェブをデザインすることに協力してくれています。すべての AMP プロジェクトのリポジトリを合わせると、今年だけで 341 名の貢献者が 18,300 回以上の寄贈をしています。








コードの向こうにいる人々

コミュニティは、AMP の進化に大きな役割を果たしています。知っていることを共有し、知らないことを学ぶ場所こそがコミュニティです。そこで、コミュニティのメンバーが AMP を利用してどのように実世界で違いを生んでいるかを理解するため、「コードの向こうにいる人々」シリーズを始めています。

19 回の新しい Roadshow を実施

今年、AMP は 19 回遠征し、世界中で Roadshow をしました。ヨハネスブルグからソウルまで、合わせて 1,600 名の皆さんが AMP を見に来てくださいました。

Roadshow は、デベロッパーが本格的な AMP ウェブサイトを自信を持って構築できるように企画されています。そのため、4 つの主要な柱であるデザイン、インタラクティブ性、DevOps、収益化について徹底的に取り上げ、一歩抜きんでるために必要なものすべてがそろうようになっています。

2020 年の開催場所については、AMP Roadshow ページをご覧ください。自分の住む場所が掲載されていない方は、ぜひお知らせください。私たちはいつも新しい場所を探しています。または、自分でイベントを開催することもできます。素材はすべて提供します。皆さんに必要なのは、来場することだけです!






2020 年のビジョン

今年はすばらしい 1 年でした。高速でユーザー ファーストなウェブをあらゆる人のために作成している皆さんの創造性と献身に感謝します。私たちは、AMP の今後に大きな期待を寄せています。新しい年も、皆さんとともにこの作業を続けてゆけることが楽しみです。AMP 関連のすべてのプロジェクトの最新情報を得て、2020 年の私たちのビジョンを見るには、ニュースレターに登録してください

投稿 : Alex Durán(Google の AMP プロジェクト マーケティング)

Reviewed by Chiko Shimizu - Developer Relations Team

世界は複雑かつ、広大で絶えず変化しています。そこには位置や場所に関連する膨大な情報が存在し、アイデアひとつでさまざまなことを実現できます。Google Maps Platform は場所に関する情報を理解し、アイデアを可視化するヒントを提供します。

2020 年の年頭にあたり、Google Maps Platform チームが作成した動画をご紹介します。この動画では、位置情報を活用したさまざまなユースケースをご覧いただけます。たとえば、

  • 山岳地帯で行われる壮絶なレースを世界中で視聴できる
  • 救命用医薬品を必要とする人々に確実に薬品が届けられるよう手助けをする
  • ライドシェア サービス事業者により正確な移動予測時間を提供する
  • 街中を恐竜がいた時代に変える
  • 自販機をグローバル ネットワークに接続し、商品の欠品を察知し機会ロスを減らす
  • クレジット カードがどの町のどの店舗で使われたのかを瞬時に把握できる




皆さんの革新的なアイデアとこのプラットフォームの組み合わせは、現実世界で起こっている問題の解決にきっと役立つことでしょう。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っております。

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

この記事は Google の Solutions Architect である Ken Nevarez による Google Maps Platform Blog の記事 "How to build your first Google Maps Platform integration with deck.gl" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。  



世の中はデータで満ち溢れています。こうしたデータの中で特に生データというものは非常に抽象的です。なぜなら、多くの場合、その隠れた意味をデータから引き出すには難しい作業を伴うからです。位置に関するデータもその一つです。位置を想起させる要素(「ジオらしさ」と言えばよいでしょうか)をデータの各行に感覚的にモデル化することが難しいのです。緯度と経度で正確な位置を記述することはできますが、それらを図的に表現して計算する手段がなければほとんど役に立ちません。この計算はコンピュータが得意とするところであって、人間にとっては得意なことではないでしょう。そこで、視覚化することが救いになります。データを視覚化することで、数値からだけでは見ることが難しい隠れた相互接続の世界を明らかにします。

この記事では、Google Maps Platform と deck.gl を連携する方法を説明します。まず、シンプルな「Hello, World!」スタイルの紹介から始めます。次に、実際のデータを使って、基本的な視覚化の手順を説明します。それができれば、視覚化に使用することができる完全な定型コードを得ることができます。

Hello, world!

deck.gl を使用した最も単純なマップの視覚化を見てみましょう。スターター プロジェクトをダウンロードしてください。

このチュートリアルで使用するファイルはすべて /src ディレクトリにあります。 主なファイルは hello-world.html です。このファイルには、Maps JavaScript API をインポートするコードと、それを使用して初期化し、基本的なスタイルをマップに適用するコードが含まれています。

このページを表示するために、シンプルなウェブサーバーを使います。このページは必須ではありませんが、この後の事例でデータとマップスタイルを読み込む際の CORS エラーを回避するため、なんらかの提供手段が必要になるでしょう。

ダウンロードしたスターター プロジェクトのディレクトリに移動します。

次のコマンドを実行して、ウェブサーバーを起動します。

 $ python -m SimpleHTTPServer 8000

次に、Maps JavaScript API をインポートする hello-world.html の上部にある script タグ内の YOUR_API_KEY を実際に作成された API キーに置き換えます。API キーの生成方法については、こちらの動画をご覧ください。

<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&libraries=visualization">
</script>

これで、次の URL によりページを表示できます。

  http://localhost:8000/hello-world.html

以下のようになるはずです。



deck.gl の基本的な視覚機能の追加

Google マップは、単独でも魅力的ですが、実世界のユースケースに即したデータ可視化の準備ができているとは言い切れません。そこで、基本となる deck.gl 視覚化を追加しましょう。Scatterplot Layer です。

まず、index.html の <head> セクションに次の script タグを追加して、deck.gl ライブラリのパッケージ化されていないバージョンをアプリに含めます。

  <head>
   <title>Google Maps and deck.gl - Hello, World!</title>
   <script src="https://unpkg.com/deck.gl@^7.0.0/dist.min.js"></script>
   ...
</head>

次のコードをご覧いただくと、index.html のメイン script で、マップがすでに初期化され、データポイントが定義されていることがわかります。

  <script type="text/javascript">
   const nyc = { lat: 40.75097, lng: -73.98765 };
   const map = new google.maps.Map(document.getElementById('map'), {
       center: nyc,
       zoom: 14,
       disableDefaultUI: true, // de-clutters the UI
       zoomControl: true, // brings back zoom controls
       styles: mapStyle // use map styles from /styles/map_styles.js
   });
</script>

deck.gl 視覚化レイヤーをこのマップに適用する最初のステップとして、この script タグの上部にある deck.gl から GoogleMapsOverlay と ScatterplotLayer オブジェクトをインポートします。

  <script type="text/javascript">
   const { GoogleMapsOverlay, ScatterplotLayer } = deck;
   ...
</script>

次に、GoogleMapsOverlay を初期化し、deck.gl の ScatterplotLayer レイヤーのインスタンスを同じスクリプトの下部に渡します。「レイヤー(Layer)」は deck.gl のコアコンセプトで、データを取得してレイヤーの外観と動作を定義する一連のプロパティに基づいて地図上にレンダリングする視覚化タイプを作成します。

ここでは、1 つのデータポイントと半径 10 メートルを指定して、マップにオーバーレイを追加します。

  ...   
   const deckOverlay = new GoogleMapsOverlay({
       layers: [
           new ScatterplotLayer({
               id: 'scatterplot',
               data: [{ position: [nyc.lng, nyc.lat, 0], }],
               getRadius: 20,
               getFillColor: [255, 133, 27]
           })
       ]
   });
   deckOverlay.setMap(map);

deck.gl レイヤーのデータ属性は堅牢です。Iterable(データの配列)、String(URL)、Promise または汎用オブジェクト(長さを実装する)を取ります。レイヤーにフィードできる内容の詳細については、deck.gl プロパティのドキュメントをご覧ください。

最終的に、大都市の雑踏に紛れこんだ、ある単一のマーカーになるはずです。

単一のデータポイントを持つ散布図レイヤー

データソースの追加

BigQuery の公開データセットの 1 つからさらにデータを追加して、より意味のある散布図を作成してみましょう。BigQuery を初めて使用する場合は、このガイドを参照して初期設定します。パブリック データセットをクエリする方法の一例を参照してください。

ニューヨーク市の Citi Bike データセットを使用します。Citi Bike はニューヨーク市の自転車シェアシステムで、マンハッタン、ブルックリン、クイーンズ、ジャージーシティに 1 万台の自転車と 600 のステーションを持ち、米国最大規模を誇ります。

データを取得するために、Google Cloud コンソールの BigQuery クエリ エディターで次のクエリを実行します。

  SELECT
               longitude,
               latitude,
               name,
               capacity
           FROM
               `bigquery-public-data.new_york_citibike.citibike_stations`

クエリが完了したら、クエリ エディターの下にある SAVE RESULTS をクリックし、JSON (local file) を選択してデータを作業ディレクトリに保存します。この例では、ファイルに stations.json という名前をつけました。



次に、この新しい JSON データソースと、そこに含まれるデータの解析方法についてレイヤーに伝えます。getPositiongetFillColorgetRadius はデータアクセサです。データに到達する方法をレイヤーに伝え、視覚化のさまざまな属性をレンダリングする方法を決定するために使用する値を抽出します。ScatterPlot Layer の場合、これらのアクセサを使用して各データポイントの場所、サイズ、色を決定できますが、必ずしもデータに基づいてレンダリングを決定する必要はありません。

たとえば、ここではすべての行で塗りつぶしの色を一定にしていますが、ポイントの位置と半径はデータに基づいて動的に設定します。

  const deckOverlay = new GoogleMapsOverlay({
       layers: [
           new ScatterplotLayer({
               id: 'scatterplot',
               data: './stations.json',
               getPosition: d => [parseFloat(d.longitude), parseFloat(d.latitude)],
               getFillColor: d => [255, 133, 27],
               getRadius: d => parseInt(d.capacity),
           })
       ]
   });

ここで作成中のアプリケーションをリロードすると、ニューヨーク市の約 800 の Citi Bike ステーションが視覚化されます。

完成した散布図レイヤー

簡単に大容量のデータを表示できましたね。Google Cloud の BigQuery パブリック データセットのデータを使用して、皆さんは deck.gl データの視覚化を初めて表現できたのです。問題が発生した場合は、scatterplot.html のコードを参照して、このチュートリアルの完成コードを確認してください。

次回は、これを先に進めて、さらに多くのデータと興味深いインタラクティブな情報をこの Scatterplot Layer に統合していきます。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っております。

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

この記事は Google Maps Platform の Product Manager である Amit Litsur による Google Maps Platform Blog の記事 "Expanded support for Google public programs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Google は、Google の製品、人材、リソースへのアクセスを提供する公開プログラムに取り組んでいます。Code.org, Charity:water, ホステリングインターナショナルなどの組織をサポートして、人々に必要なリソースを提供し、こうした組織が支援していることを可視化する手助けをしています。
Charity:water はお金がどこで使われたのかを出資者が正確に把握できる方法を開発しました。
これまでの非営利団体に加えて、スタートアップ、災害対応に関わる組織、ニュースなどのメディアに対しても、Google Maps Platform を割引料金または無料で提供できるようになりました。このプログラムの適用対象国も 7 か国から 50 か国に増え、さらに多くのグローバル コミュニティとプログラムをサポートできるようにしています。
Falling Fruit は、街中で入手可能な季節の食材を見つけるのに役立ちます。
本プログラムの対象となる組織は、組織の取り組みをサポートする Google Maps Platform クレジットを申請することができます。参加資格と応募方法の詳細については、本プログラムの解説ページ(英語)をご覧ください。非営利団体、スタートアップ、災害対応に関わる組織やニュースメディア組織の方は、これらのプログラムをぜひご活用ください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っております。

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

この記事は Google の Head of developer relations である Mike Pegg による Google Maps Platform Blog の記事 "The top 5 videos on the new Google Maps Platform YouTube channel" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Google Maps Platform YouTube チャンネルでは、Google Maps Platform の活用方法を学んだり、すでに構築されている素晴らしい作品に触れることができます。チュートリアルから、製品発表、ユーザー事例、Geocasts シリーズといった、多数のお役立ち動画を見ることができます。そこで、現在のチャンネルやプレイリストから視聴できるトップ 5 の動画をご紹介します。チャンネルを訪問してさらに多くの動画をご視聴いただき、チャンネル登録をして最新情報を手に入れてください。

Google Maps Platform の API と SDK を有効化する方法


現時点で、最多の視聴回数を持つ動画であり、エンジニアの Emily Keller が Google Maps Platform の API と SDK を有効化する方法を説明しています。これを習得すれば、ユーザーが世界中を探索したり、皆さんのビジネスや事業運営の最適化を手助けするようなエクスペリエンスを積み重ねていくことができます。



パフォーマンスとスケールを構築する方法を掘り下げる(Google I/O 2019)


2019 年の Google I/O に行く機会を逃した方は、Google I/O 再生リストを視聴することですぐに遅れを取り戻すことができます。この動画では、ベストプラクティスの模範となるような導入事例を深掘りし、Google Maps Platform を使って構築する方法を再度紹介しています。同時に、Maps API を使って大規模データを取扱う新たな方法や、スタイルをカスタマイズする上でのヒントを学ぶことができます。



Google Maps Platform を使ったゲームのデモ : Space Janitor


Google は、2019 年の Game Developers Conference(GDC) において、Google Maps Platform のゲーミング ソリューションを使って開発することができる、新しいタイプの魅力的なロケーションベースのゲームのアイデアとして、多様なゲームのデモを展示しました。GDC で最も創造的なモバイルゲームの 1 つと称された Space Janitor は、新たな YouTube チャンネルで、これまでで最も多く視聴されたゲームデモとなりました。



Google Maps Platform の業界向けソリューション(Cloud Next 2019)


Google Maps Platform チームからの説明を聞いて、素晴らしいユーザー体験を構築したいという意欲を持たれた方は、Cloud Next 2019 で Geo 部門の Jen Fitzpatrick 上級副社長(SVP)が行ったプレゼンテーションをぜひご覧ください。世界を地図化するという仕事の最近の進捗状況やゲーム、ライドシェア業界のために Google が開発した、特定業界向けのソリューションについて理解を深めることができます。



Global Risk Assessment Services が Google Maps Platform をいかに活用しているか


世界を変える可能性を持った地球規模の課題に取り組んでいるチームについて知ることは、たとえどんな仕事をしていたとしても、間違いなく素晴らしい刺激となり得ます。この動画では、Global Risk Assessment Services が Google Maps Platform を使って、自然生息地への農業拡大がもたらす生態学的や社会的なリスクについて、信頼性の高い情報を提供していることを紹介しています。



今後も、Google Maps Platform に関する情報を動画で投稿していきますので、ぜひチャンネル登録してください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やご意見はページ右上の「お問い合わせ」より承っております。

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

この記事は Android プラットフォーム セキュリティ担当シニア ソフトウェア エンジニア、Bram Bonné、Android プラットフォーム セキュリティ担当スタッフ ソフトウェア エンジニア、Chad Brubaker による Google Online Security Blog の記事 "An Update on Android TLS Adoption" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

いくつかの端末とゲーム コントローラが描かれたバナーの図
Android は、ユーザー、端末、データを安全な状態に保つことに力を注いでいます。データを安全な状態に保つ方法の 1 つとして、Android 端末が送受信するネットワーク トラフィックを Transport Layer Security(TLS)で保護することがあげられます。

2016 年の Android 7(API レベル 24)では、ネットワーク セキュリティ構成導入され、アプリのデベロッパーが宣言的な構成ファイルでアプリのネットワーク セキュリティ ポリシーを設定できるようになりました。アプリの安全性を保証するため、Android 9(API レベル 28)以降をターゲットとするアプリには、すべてのドメインに対し、暗号化されていないトラフィックを防止するポリシーセットがデフォルトで自動設定されます。

現在は、うれしいことに、80% の Android アプリがデフォルトでトラフィックを暗号化しています。Android 9 以降をターゲットとしたアプリではこの比率がさらに上がり、90% がデフォルトでトラフィックを暗号化しています。
デフォルトでクリアテキストをブロックするアプリの比率
デフォルトでクリアテキストをブロックするアプリの比率

2019 年 11 月 1 日以降、すべてのアプリ(Google Play のアップデートおよびすべての新規アプリ)で Android 9 以降をターゲットにすることが必須になります。そのため、この数はさらに増えるものと考えられます。これらのアプリによるネットワーク トラフィックはデフォルトで安全です。暗号化されていない接続が利用されるのは、デベロッパーが明示的に選択した結果です。

Android Studio の最新リリースと Google Play のリリース前レポートは、アプリに安全でない可能性があるネットワーク セキュリティ構成が含まれている場合(たとえば、すべてのドメインに対して暗号化されていないトラフィックを許可している場合や、デバッグモード以外でユーザーが提供した証明書を受け入れている場合)、デベロッパーに警告します。これにより、Android エコシステム全体で HTTPS の採用が推奨され、デベロッパーがセキュリティ構成を確実に意識できるようになります。
Android Studio でデベロッパーに表示される警告の例
Android Studio でデベロッパーに表示される警告の例
リリース前レポートの一部としてデベロッパーに表示される警告の例
リリース前レポートの一部としてデベロッパーに表示される警告の例

アプリを安全にするためにできること

Android 9 以降をターゲットにしているアプリの場合、何の設定も必要とせずにすぐに使えるデフォルトで、すべての通信中のネットワーク トラフィックを暗号化し、標準の Android CA セットに含まれる認証局が発行した証明書のみを信頼するようになっています。アプリに例外を設ける唯一の方法は、注意深く例外を選択し、別のネットワーク セキュリティ構成ファイルを含めることです。

アプリで特定のドメインに対するトラフィックを許可しなければならない場合は、デフォルトのセキュリティ ポリシーに対する例外のみを記述したネットワーク セキュリティ構成ファイルを含めます。安全でない接続を通して受信したデータは、転送中に改ざんされるおそれがあるので、十分注意する必要があります。
<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
        <domain includeSubdomains="true">insecure.cdn.example.com</domain>
    </domain-config>
</network-security-config>
アプリでテスト用にユーザーが指定した証明書の受け入れを可能にしなければならない場合(たとえば、テストの際にローカル サーバーに接続する場合)は、<debug-overrides> 要素の中に <trust-anchors> 要素を含めます。これにより、本番環境でのアプリの接続は確実に安全なものになります。 element inside a element. This ensures the connections in the production version of your app are secure.
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="user"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

ライブラリを安全にするためにできること

ライブラリで直接安全な接続や安全でない接続を確立している場合は、isCleartextTrafficPermitted を確認して、アプリのクリアテキスト設定に従うようにします。これは、クリアテキスト接続をオープンする に行う必要があります。
Android のビルトイン ネットワーク ライブラリや、OkHttpVolley などのよく利用されている HTTP ライブラリは、ビルトイン ネットワーク セキュリティ構成をサポートしています。
Android プラットフォーム セキュリティ、Android Studio およびリリース前レポートチーム、Giles Hogben、Nwokedi Idika

Reviewed by Yuichi Araki - Developer Relations Team



この記事は Patrick Nepper、Kiran C. Nair、Vasilii Sukhanov、Varun Khaneja による Google Online Security Blog の記事 "Better password protections in Chrome - How it works" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome のパスワード保護が強化され、M79 のリリースで徐々にロールアウトされたことをお知らせします。ここでは、その仕組みを詳しく解説します。

侵害されたパスワードの警告

昨年初め、Google は Password Checkup 拡張機能でパスワードの侵害に関する警告を初めて導入しました。Google は、侵害されている 40 億個の認証情報を認識しています。前述の拡張機能は、パスワードおよびユーザー名をその情報と比較します。詳細については、こちらをご覧ください。10 月には、Password Checkup 機能が Google Account に組み込まれpasswords.google.com で同じ機能が使えるようになりました。

この機能を Chrome に組み込むのは、ウェブを閲覧するさらに多くのユーザーを保護するための自然な次のステップです。これは次のように機能します。
  • Google は、別の企業からユーザー名とパスワードのデータが流出したことを知ると、ハッシュ化と暗号化を行ったデータを、Google しか知らない秘密鍵と合わせてサーバーに保管します。
  • ウェブサイトにログインすると、Chrome はハッシュ化したユーザー名とパスワードを Chrome しか知らない秘密鍵で暗号化して Google に送ります。この暗号化されたデータからは、Google を含め、誰もユーザー名とパスワードを解読することはできません。
  • ユーザー名とパスワードが流出データに含まれているかを判断するため、複数のレイヤーの暗号化を利用する private set intersection with blinding と呼ばれる手法を使います。これにより、自分のユーザー名とパスワードを暗号化したものと、すべての流出したユーザー名とパスワードを暗号化したものを比較できます。自分のユーザー名とパスワードや、他のユーザーのユーザ名とパスワードが明かされることはありません。この計算を効率的に行えるように、Chrome はユーザー名の 3 バイトの SHA256 ハッシュ プレフィックスを送ることで、データを結合する規模を 40 億レコードから 250 レコードに削減しています。この場合も、ユーザー名の匿名性は維持されています。
  • ユーザー名とパスワードが侵害されているかどうかは、そのユーザーにしかわかりません。侵害されていた場合、Chrome はその旨を通知します。そのときはパスワードを変更することを強くお勧めします。
この機能は、Chrome の設定の [Sync and Google Services] セクションで制御できます。企業の管理者は、Password Leak Detection Enabled ポリシー設定を使ってこの機能を制御できます。

リアルタイム フィッシング保護: セーフ ブラウジングのブロックリストをリアルタイムに確認

Chrome の新しいリアルタイム フィッシング保護は、既存のテクノロジーを展開するものでもあります。この場合は、実績豊富な Google セーフ ブラウジングが展開されます。

セーフ ブラウジングは、日々数千もの安全でないサイトを新たに発見し、それをウェブ業界で共有されているブロックリストに追加しています。Chrome は、訪問した各サイトやダウンロードしたファイルの URL をこのローカルのリストと照合してチェックします。ローカルのリストは、約 30 分ごとに更新されます。リスト上に存在する URL に移動すると、Chrome は URL フィンガープリントの一部(URL の SHA-256 ハッシュの最初の 32 ビット)を Google と照合し、URL が本当に危険かどうかを検証します。Google は、この情報から実際の URL を判断することはできません。

しかし、ドメインをすばやく切り替えるか、Google のクローラーから隠れることで、一部のフィッシング サイトは 30 分の更新間隔をすり抜けてしまう場合があります。

そこで登場するのが、リアルタイム フィッシング保護です。この新しい保護は、セーフ ブラウジングのサーバーがアクセスしたことがあるページの URL をリアルタイムに調査できます。ウェブサイトにアクセスすると、Chrome はそのサイトを、安全であることがわかっているたくさんの有名ウェブサイトのリストと照合します(このリストはコンピュータに格納されています)。ウェブサイトがこのセーフリストに記載されていない場合、Chrome は(URL に埋め込まれたユーザー名とパスワードを削除した後)Google で URL をチェックし、危険なサイトにアクセスしようとしているかを判断します。私たちの分析によれば、悪意のある新しいサイトについてユーザーに警告することにより、保護が 30% 強化されます。

最初、この機能は、Chrome で既に [Make searches and browsing better] 設定をオプトインしているユーザーにロールアウトされます。企業の管理者は、この設定を Url Keyed Anonymized Data Collection Enabled ポリシー設定から管理できます。

予測的フィッシング保護の拡張

オンラインでの本人確認とデータの鍵となるのがパスワードです。この鍵が攻撃者の手に落ちれば、攻撃者は簡単になりすましてそのユーザーのデータにアクセスできます。私たちは、予測的フィッシング保護をリリースしました。これは、Chrome で履歴を同期しているユーザーが、認証情報を盗もうとするフィッシング サイトの疑いがある場所に Google アカウントのパスワードを入力した場合、そのユーザーに警告する機能です。

今回の最新リリースでは、同期を有効にしていないユーザーも含め、Chrome にログインしているすべてのユーザーにこの保護を拡張します。さらに、この機能は、Chrome のパスワード マネージャーに格納されているすべてのパスワードで動作します。

保護されているパスワード(Chrome のパスワード マネージャーに保存したパスワードまたは Chrome へのサインインに使っている Google アカウントのパスワード)のいずれかを通常と異なるサイトに入力した場合、Chrome はこれを危険な可能性があるイベントと分類します。

このような場合、Chrome はこのサイトを、安全であることがわかっているたくさんの有名ウェブサイトのリストと照合します(このリストはコンピュータに格納されています)。ウェブサイトがこのセーフリストに記載されていない場合、Chrome は(URL に埋め込まれたユーザー名とパスワードを削除した後)Google で URL をチェックします。このチェックによってサイトが実際に疑わしい、または悪意のあるサイトであることがわかると、Chrome は即座に警告を表示し、侵害されたパスワードを変更することを促します。フィッシングされたのが Google アカウントのパスワードだった場合、Chrome は Google に知らせることも提案します。そうすることで、アカウントが侵害されないように保護を強化できます。

パスワードの再利用に注目することにより、Chrome は Google と共有するデータを最低限に抑えつつ、重要な瞬間にセキュリティを高めることができます。私たちは、予測的フィッシング保護により、さらにたくさんの人を保護できると考えています。

Reviewed by Eiji Kitamura - Developer Relations Team