[go: nahoru, domu]


この記事は Developer Programs Engineer の Christopher Arriola による Google Cloud Blog の記事 "Announcing version 6.0 of the Maps and Places SDKs for iOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

12 月 1 日(米国時間)、Maps SDK for iOS と Places SDK for iOS の新しいバージョンをリリースいたしました。バージョン 6.0 では、サポート対象の iOS のバージョンが iOS 12 からとなり、Apple M1 マシン上で iOS 14 以降のシミュレータを使用して開発する際に必要なバイナリを含む XCFramework のプレビュー サポートを提供し、デベロッパーの開発速度向上を実現します。また、このバージョンには、デベロッパーの皆様からのリクエストに基づいて、マーカーを地図に追加した際のアニメーション動作に関する新機能も追加しています。

マーカーのフェードイン アニメーション

バージョン 6.0 では、マーカーをマップに追加した際の表示をアニメーション化できるように、kGMSMarkerAnimationFadeIn という新しい GMSMarkerAnimation タイプが導入されました。


サンプルアプリで MarkersViewController をご覧ください

これを使用するには、マーカーをマップに追加する前に、マーカーの appearAnimation プロパティを設定します。
Swift

 let position = CLLocationCoordinate2D(latitude: -33.86, longitude: 151.2)

let marker = GMSMarker(position: position)

marker.appearAnimation = .fadeIn


Objective-C

 CLLocationCoordinate2D position = CLLocationCoordinate2DMake(-33.86, 151.2);

GMSMarker *marker = [GMSMarker markerwithPosition:position];

marker.appearAnimation = kGMSMarkerAnimationFadeIn;



XCFramework のサポート

従来、Maps SDK for iOS と Places SDK for iOS は、アプリの開発とリリースに必要なアーキテクチャを含む単一の .framework ファイルとして配布されていました。しかし、Apple M1 マシンを使用する場合、新しいバリアントである arm64 シミュレータに対応させるため、SDK を新しい XCFramework 形式に再パッケージ化する必要がありました。

Apple M1 マシンで以前のバージョンの SDK の使用を試みたことがある方は、以下のエラーに見覚えがあるはずです。

ld: building for iOS Simulator, but linking in object file built for iOS, file '[...]/GoogleMaps/Frameworks/GoogleMaps.framework/GoogleMaps for architecture arm64

Maps SDK for iOS と Places SDK for iOS のバージョン 6.0 のリリースでは、XCFramework のプレビュー サポートを提供し、Apple M1 マシンで発生していた上記のエラーを解消しています。プレビュー サポートの使用方法について詳しくは、Maps と Places のスタートガイドをご覧ください。

Maps SDK と Places SDK の XCFramework バージョンはベータ版のため、これらのバージョンは開発目的でのみ使用し、アプリをリリースする際には .framework バージョンを使用することをおすすめします。今後の SDK では、XCFramework のサポートを一般提供する予定です。

バージョン 6.0 をインストールしサンプルを確認する

CocoaPods や Carthage を使用して Maps SDK for iOSPlaces SDK for iOS のバージョン 6.0 をインストールできるようになりました。SDK の XCFramework プレビュー版をインストールする場合は、[Installing the XCFramework] タブをご覧ください。サポートする iOS バージョンは iOS 12 からとなるため、バージョン 6.0 を使用して開発するには Xcode 12 以降を使用する必要があります。iOS 11 のサポートは現在中止していますが、Maps SDK for iOS と Places SDK for iOS の古いバージョンを指定することで、引き続きご利用いただけます。

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



Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Team 

この記事は Chrome ソフトウェア エンジニア、Clark Duvall による Chromium Blog の記事 "Partitioning Chrome's Code for Faster Launch Times on Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


通常、モバイル デバイスは、ノートパソコンやデスクトップよりもリソースが限られています。モバイル ユーザーが Chrome を高速に使えるようにするには、Chrome のリソース使用の最適化が欠かせません。Android 版の Chrome に機能を追加するにつれて、アプリにパッケージ化される Java コードの量は増え続けています。今回の速さと好奇心の投稿では、Isolated Splits によって Android 版 Chrome のスピードとメモリ使用量をどのように改善したのかについて説明します。この改善により、Android 版 Chrome のメモリ使用量が 5-7% 減少し、起動とページ読み込みの速度もさらに向上しました。

問題Android アプリ(Android 版 Chrome も含む)では、コンパイルされた Java コードが .dex ファイルに格納されます。Android 版 Chrome にはマルチプロセス アーキテクチャが採用されているため、そのユーザー エクスペリエンスが .dex サイズの増加に特に影響されやすくなります。通常、Android の Chrome では、ブラウザ プロセス、GPU プロセス、1 つ以上のレンダラ プロセスという 3 つ以上のプロセスが常に実行されています。Chrome の Java コードの大半はブラウザ プロセスでのみ使われます。しかし、そのコードを読み込むためのパフォーマンスとメモリのコストは、すべてのプロセスが支払うことになります。
 
バンドルと機能モジュールプロセスを実行するために必要な最小チャンクの Java を読み込むことができれば理想的です。Android App Bundle を使ってコードを機能モジュールに分割することで、それに近づくことができます。機能モジュールを使うと、コードやリソース、アセットを個別の APK に分割し、オンデマンドでもアプリのインストール時でも、ベース APK とともにインストールできます。

ということは、まさに必要としているものが手に入りそうです。つまり、ブラウザ プロセスのコード用機能モジュールを作り、必要なときにそれを読み込むことができるかもしれません。しかし、Android はそのようにして機能モジュールを読み込むわけではありません。デフォルトで、すべてのインストールされている機能モジュールは起動時に読み込まれます。ベース モジュールと 3 つの機能モジュール "a"、"b"、"c" があるアプリなら、Android の Context と、次のような ClassLoader が得られます。





状況によっては、インストールするモジュールを最低限にとどめ、起動時にこれらのモジュールすべてを即座に読み込むという方法が役立つこともあります。たとえば、一部のユーザーしか必要としない大きな機能がある場合、必要のないユーザーはそれをまったくインストールしないようにします。しかし、一般的に使われる機能の場合、実行時に機能をダウンロードしなければならないと、ユーザーは不便を感じる可能性があります。たとえば、動作が遅くなったり、モバイルデータが利用できないときに問題になったりします。理想的な方法は、標準モジュールをすべて事前にインストールしておいて、実際に必要になったときのみ読み込むことです。

解決策は Isolated Splits数日間 Android ソースコードを探し続けた結果、android:isolatedSplits という属性が見つかりました。これを "true" に設定すると、インストールされた分割 APK が起動時に読み込まれなくなり、明示的な読み込みが必要になります。これこそ、プロセスのリソース使用量を減らすために必要としていたものです。これにより、先ほどの ClassLoader は次のようになります。





Chrome では、レンダラーや GPU プロセスに必要な少量のコードを引き続きベース モジュールに配置し、ブラウザなどの高価な機能のコードは機能モジュールに分割し、必要なときに読み込みます。この方法を使うことで、子プロセスに読み込まれる .dex サイズを 75% 減らし、最大 2.5 MB にすることができました。その結果、起動が速くなり、メモリ使用量も減りました。

このアーキテクチャによって、ブラウザ プロセスの最適化も可能になります。アプリケーションの初期化中にブラウザ プロセスのコードの大部分をバックグラウンド スレッドでプリロードした場合も起動時間を短縮でき、読み込み時間が 7.6% 高速になりました。ブラウザのコードが必要なアクティビティなどのコンポーネントが起動するときには、すでに読み込みが終わっています。機能モジュールへの機能の割り当てを最適化すると、オンデマンドで機能を読み込むことができます。これにより、機能が実際に使われるまで、メモリや読み込みのコストを節約できます。

結果M89 で Chrome に Isolated Splits が搭載されて以来、数か月にわたる実際のデータが蓄積されており、Android Oreo 以降を実行しているすべての Android ユーザーの Chrome で、メモリ使用量、起動時間、ページ読み込みのスピード、安定性が大きく改善されたことがわかりました。
  • 合計メモリ使用量の中央値が 5.2% 改善
  • レンダラー プロセスのメモリ使用量の中央値が 7.9% 改善
  • GPU プロセスのメモリ使用量の中央値が 7.6% 改善
  • ブラウザ プロセスのメモリ使用量の中央値が 1.2% 改善
  • 起動時間の 95 パーセンタイルが 7.6% 改善
  • ページ読み込みスピードの 95 パーセンタイルが 2.3% 改善
  • ブラウザのクラッシュ率とレンダラーのハング率の両方が大幅に改善
すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Theodore Olsauskas-Warren による Chromium Blog の記事 "Simplified Storage Controls" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome チームでは、ユーザーがウェブのプライバシーについての理解を深め、その管理を改善することができる方法を常に探しています。直近の変更によって、サイトのストレージ設定の管理がわかりやすくなります。

今回(元記事投稿当時より)、この変更を M97 ベータ版にロールアウトし、サイトが格納できるデータ(Cookie など)に関連するプライバシーやセキュリティの設定を再構成します。ユーザーは、個々のサイトが保存したすべてのデータを削除できます。この操作は、[ 設定 ] > [ プライバシーとセキュリティ ] > [ サイトの設定 ] > [ すべてのサイトに保存されている権限とデータを表示 ] を開いて行います。この操作では、chrome://settings/content/all が表示されます。[ 設定 ] > [ プライバシーとセキュリティ ] > [ Cookie と他のサイトのデータ ] > [ すべての Cookie とサイトデータを表示 ] に移動したときに表示される詳細コントロールは、削除する予定です。これは、[ 設定 ] の chrome://settings/siteData からも参照できます。このレベルで詳細を確認する機能はデベロッパーを対象にしたものです。デベロッパーは、今後も DevTools からこの機能にアクセスできます。

旧 : このページは削除予定。ウェブ関連のストレージの管理は、chrome://settings/content/all から行う。


新 : こちらの chrome://settings/content/all で、ユーザーがウェブ関連のストレージを削除できる。


変更点

私たちは、[ 設定 ] での細かい管理を簡素化することで、ユーザーにわかりやすい操作を実現できると考えています。ユーザーが個々の Cookie を削除できる場合、サイトの実装の詳細を意図せずに変更することになり、サイトの動作がおかしくなる可能性があります。これは予測が難しい問題です。さらに能力の高いユーザーが、Cookie の目的を不正に推測して、いくつかのプライバシー保護を侵害するリスクがあります。

この機能を使うのは主にデベロッパーなので、必要な DevTools のツール群と合わせてデベロッパー向けに提供を続けます。デベロッパーは DevTools にアクセスすることで、今後も必要に応じて Cookie ごとやストレージごとのレベルで詳細情報にアクセスできます。

詳細な Cookie の管理は引き続き DevTools で実行可能


Google は Chrome をさらに便利なものにしたいと考えているので、いつものように皆さんのフィードバックをお待ちしています。私たちの次のステップは、すべての詳細な Cookie の管理機能を DevTools で維持しつつ、この機能をページ情報から削除することです。ストレージ管理についてその他の質問やコメントがある方は、こちらからお知らせください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 97: WebTransport, New Array Static Methods and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。

3 桁のバージョン番号に対する準備

来年には、Chrome でバージョン 100 がリリースされます。つまり、Chrome のユーザー エージェント文字列で報告されるバージョン番号の桁が増えます。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されています。chrome://flags/#force-major-version-to-100 と呼ばれるこの新しいフラグは、Chrome 96 以降で利用できます。詳細については、Chrome の User-Agent 文字列のメジャー バージョンを強制的に 100 にするをご覧ください。 

今回のリリースに追加された機能 details 要素の自動展開

閉じられた details 要素に対する検索やリンクができるようになります。また、こういった非表示の要素は、find-in-pageScrollToTextFragment のタイミング、あるいは要素のフラグメント ナビゲーションが使われたときに、自動的に展開されます。

レスポンス ヘッダーによる専用ワーカーへの Content-Security-Policy の提供

専用ワーカーが Content Security Policy の影響を受けるようになります。これまで、Chrome は、オーナーのドキュメントの Content Security Policy を誤って適用していました。

CSSfont-synthesis プロパティ

font-synthesis CSS プロパティは、フォント ファミリーに斜体、太字、小型英大文字のフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。font-synthesis プロパティがない場合、必要なバリエーションのフォント ファミリーがないウェブページで、不自然な形状のフォントになる可能性があります。

transform: perspective(none)

perspective() 関数の引数として、値 'none' がサポートされます。その場合、関数は無限大の引数を渡された場合のように動作します。これにより、perspective() 関数が関係しているアニメーションのエンドポイントの片方が単位行列であるアニメーションが簡単になります(場合によっては、実現可能になります)。

Keyboard API の Feature Policy

Chrome は、Feature Policy の許可リストで新しく keyboard-mapをサポートします。Keyboard.getLayoutMap() を使うと、英語やフランス語など、異なるキーボード レイアウトで押されたキーを特定できます。このメソッドは、iframe 要素では利用できません。また、Keyboard API を利用できなかった一部のウェブアプリ(Excel、Word、PowerPoint)のアーキテクチャで、このメソッドが利用できるようになります。

HTMLScriptElement.supports() メソッド

HTMLScriptElement.supports() メソッドは、script 要素を利用する新機能を統一的な方法で検出します。現在のところ、HTMLScriptElement の type 属性で利用できる種類を簡単に判定する方法はありません。

フォーム送信時の遅い段階での改行正規化

フォーム エントリの改行が Gecko や WebKit と同じように正規化されるようになります。これにより、Gecko と WebKit は改行を遅い段階で正規化するにもかかわらず、Chrome は早い段階で正規化するという、長期にわたって存在していた相互運用性の問題が解決します。Chrome 97 以降では、早い段階での正規化が削除され、遅い段階での正規化がすべてのエンコーディング タイプに拡張されます。

既存の Client Hint 名の標準化

Chrome 97 は、Sec-CH- プレフィックスを付けて Client Hint 名を標準化します。影響を受ける Client Hint は、dprwidthviewport-widthdevice-memoryrttdownlinkect です。Chrome では、以上のヒントの既存バージョンのサポートも継続されます。しかし、ウェブ デベロッパーは、今後のサポートの終了や削除に向けた準備をする必要があります。

WebTransport

WebTransport は、ウェブのセキュリティ モデルの制約を受けるクライアントがリモート サーバーと通信する際に、安全な多重化転送を可能にするプロトコル フレームワークです。

現在、ウェブ アプリケーション デベロッパーがリモート サーバーと双方向通信をする場合、WebSocketsRTCDataChannel という 2 つの API を使うことができます。WebSockets は TCP ベースなので、すべての TCP の欠点(ヘッドオブライン ブロッキング、信頼できないデータ転送の未サポート)を引き継ぐことになり、レイテンシが重要なアプリケーションには適しません。RTCDataChannel は Stream Control Transmission Protocol(SCTP)ベースなので、そのような欠点はありません。しかし、ピアツーピアで使うことを念頭に置いて設計されているので、クライアントサーバー設定で使われることはほとんどありません。WebTransport は、信頼できないデータと信頼できるデータの両方の双方向通信をサポートするクライアントサーバー API で、UDP 的なデータグラムによるキャンセル可能なストリームを利用します。WebTransport の呼び出しは DevTools の [Network] パネルで確認できます。[Type] 列を見ると、このプロトコルが使われていることがわかります。

詳しくは、WebTransport の試験運用をご覧ください。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン x.x が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Array と TypedArray の findLast() と findLastIndex()

ArrayTypedArrayfindLast() と fileLastIndex() 静的メソッドをサポートします。この 2 つの関数は find() と findIndex() と同じですが、配列の最初からではなく最後から検索します。

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

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

WebRTC での SDES 鍵交換の削除

2013 年以降、WebRTC の SDES 鍵交換メカニズムは、関連する IETF 標準で使用禁止と宣言されています。IETF は、SDES 仕様を過去のものと宣言しています。近年では、Chrome での使用も大幅に減少しました。そのため、Chrome 97 で削除されます

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

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

SDP Plan B の削除

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


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Kristen Richards による The Firebase Blog の記事 " What’s new at Firebase Summit 2021 "を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



私たち Firebase チームは、人々が学び、生活を向上させ、行くべき場所に行き、ビジネスを成長させるうえで、デベロッパーの皆さんが重要な役割を果たしていると考えています。私たちが、使いやすく拡張可能な統合ツールを提供しようと懸命になっているのは、そのためです。そうすることによって、たくさんの人々が必要不可欠と感じ、かつ気に入ってもらえるエクスペリエンスを、継続的に皆さんが作成できるようにしたいと考えています。
 
スタートアップ企業からグローバル企業まで、あらゆる規模の企業が作った数百万個のアプリが、毎月 Firebase を積極的に活用しています。皆さんの信頼こそが、私たちが Firebase をさらによいものにしたいと考える動機です。 先日、Firebase Summit がバーチャル イベントとして復活しました。このプラットフォームのアップデートをお披露目できて光栄です。いずれのアップデートも、アプリ開発を加速させ、自信をもってアプリを運営し、簡単にスケールアップを実現するうえで役立ちます。ここでは、それぞれの新機能を詳しく紹介しますので、ぜひお読みください。イベントのウェブサイト (英語) には、Summit で紹介したたくさんのすばらしいコンテンツ(テクニカル セッション、デモ、Pathway など)がありますので、そちらも忘れずにチェックしておきましょう!
 
お時間がない方は、特定のセクションにジャンプできます。お時間のある方は、ぜひ記事全体をお読みください。
 
新しいビルディング ブロックでアプリ開発を加速


自信をもってアプリを運営するために実用的な知見を獲得


強力なエンゲージメント ツールによる容易なスケーリング


新しいビルディング ブロックでアプリ開発を加速
Firebase は効率的に操作できるフルマネージドなインフラストラクチャを提供するので、皆さんは一番重要なことに集中してアプリを開発、運営できます。
 
重要な e コマース機能を短時間で追加する新しい拡張機能
Firebase Extensions は、あらかじめパッケージ化されたコードバンドルにより一般的な開発タスクを自動化する仕組みです。これを使うと、わずかな手順でアプリに機能を追加できます。私たちは、皆さんが信頼するおなじみの企業と連携し、新しい API を学ぶことなくさまざまなサービスを組み込めるようにしています。先日、Stripe の仲間たちが、Run Payments with Stripe (英語) 拡張機能にワンタイム支払い機能と SDK (英語) を追加してくれました。ウォレット、銀行へのリダイレクト、後払い決済など、アプリで 15 種類以上の支払い方法に対応できる新機能もリリースしたばかりです。
 
さらに、アプリに短時間で重要な e コマース機能を追加できる新しい拡張機能も複数発表しました。これらの拡張機能を使うと、ShipEngine で商品の出荷や追跡を行ったり、SendGrid のメールや Twilio の SMS メッセージを使ってショッピング カートを放置しているユーザーに働きかけたり、Elastic による Cloud Firestore 検索を実装したりできます。Google Pay を通じて、1 つのインターフェースで複数のプロバイダからの支払いを受け付けることもできます。複数の国でアプリをリリースする場合、この仕組みは特に便利です。詳しくは、Firebase Extensions のページにアクセスし、早速インストールしてみてください。始めるにあたってアイデアがほしいという方は、17 種類以上の拡張機能を使っている GitHub のサンプルアプリのコードをご覧ください。デプロイされたバージョンは、https://karas-coffee.web.app/ (英語) でご覧いただけます。

私たちのパートナーが Firebase とコラボレーションして作り上げた、これらの新しい拡張機能を活用すると、短時間でアプリに e コマース機能を追加できます
 
Apple プラットフォーム、ゲームエンジン、Flutter のサポート強化
うれしいお知らせです。Firebase が tvOS と macOS に対してベータ版レベルのサポートを提供するようになりました!つまり、お気に入りの Firebase プロダクトを使って Apple TV や Macbook 互換のアプリを開発し、運営することができます。コードベースは 1 つなので、手間を減らしつつ、優れたクロスデバイス エクスペリエンスをユーザーに提供できます。たとえば Crashlytics SDK を追加すれば、致命的なクラッシュを特定したり、Firebase Crashlytics コンソールで Apple デバイスの種類やオペレーティング システムでクラッシュを絞り込んだりできます。


Apple プラットフォームのサポート強化により、スムーズなクロスデバイス エクスペリエンスの提供が可能になります
 
ゲーム デベロッパーの皆さんは、Google の C++ SDK の多くが Apple TV をサポートしたと聞けば喜ぶことでしょう。あの Apple Arcade ゲームを、Firebase を使って開発できるからです。また、その機能をベースに、Cloud Firestore を Unity と C++ に対応させることで、ゲーム フレームワークとゲームエンジンのサポートを強化します。これによって強力な Cloud Firestore をすぐにゲームで利用できるようになり、ゲームのデータをほぼリアルタイムに格納したり同期したりできます。さらに、オフラインをサポートすることも、数千人以上のプレーヤーをサポートするようにゲームをスケールアップすることもできます。


Cloud Firestore が Unity と C++ に対応し、リアルタイム データ同期機能やオフライン サポートを提供します
 
また、Crashlytics の Unity SDK と NDK SDK に多数の大幅な改善を加え、ゲームのコードベースを簡単にデバッグできるようにしました。現在、Crashlytics により、ネイティブ コードでのクラッシュをより広範囲に追跡できるようになっています。Unity ゲームの IL2CPP もサポートされ、C# コードにマッピングできるシンボル化した C++ フレームが増えています。
 
最後に、Flutter のオンライン エディタである Dartpad の最新リリースにより、Flutter (英語) と Firebase を併用することで、お使いのブラウザだけでプラットフォームを超えてユーザーを獲得するアプリを開発できるようになっています。Flutter は Google のオープンソース フレームワークであり、1 つのコードベースから、ネイティブ コンパイルが可能な美しいマルチプラットフォーム アプリを構築できます。これは、Firebase のクロスプラットフォーム バックエンド サービスを自然に補完するものです。また Dartpad が Cloud Firestore と Firebase Authentication をサポートしました。これ以外の Firebase プロダクトも、近日中にサポートする予定です。dartpad.dev を開き、Firebase パッケージをインポートすると、実際に試してみることができます。サンプルアプリもご覧ください。


Flutter のオンライン エディタである Dartpad が、細かい設定なしに Firebase をサポートするようになりました
 
App Check によるアプリのセキュリティ強化
App Check を皆さんに紹介したのは数か月前のことでした。App Check は、バックエンド インフラストラクチャに強力なセキュリティ レイヤーを提供します。これは、着信するトラフィックが正規のデバイスにインストールされたアプリから来ていることを証明し、有効な認証情報を持たないトラフィックをブロックすることで実現しています。今回の 3 つの大きなアップデートによって、App Check で行えることがさらに増えました。
 
1 つ目は、App Check を使って、以前お知らせした Cloud Storage for Firebase、Realtime Database、Cloud Functions for Firebase に加えて、Cloud Firestore へのアクセスを保護できるようになったことです(Firestore Web SDK も近日中にサポートします)。2 つ目は、App Check を任意のカスタム バックエンド リソースで使えるようにするために、カスタム サーバー保護を追加したことです。この機能には、Apigee などの API 管理プラットフォームや、CloudFlare などの CDN とも統合されています。3 つ目は、App Check がサポートする証明書プロバイダの数を追加し、Apple のアプリ証明書プロバイダである App Attest や reCAPTCHA Enterprise をサポートしたことです。早速 App Check にアプリを登録し、Firebase コンソールから保護を適用してみましょう。App Check の詳細については、ドキュメントをご覧ください。

App Check がアプリとユーザーデータを保護します
 
導入予定の Google Play のセーフティ ポリシーについての詳細ドキュメント
各 Firebase プロダクトが収集および共有するデータを明示した詳細ドキュメントを公開しました。これは、Google Play に導入予定のセーフティ ポリシー (英語) に準拠するうえで役立ちます。私たちの目標は、プライバシーと透過性に対する Google の取り組みを土台として、Google Play の新しいデータ セーフティ セクションの準備をいち早く行ってもらえるようにすることです。このセクションは、来年にはアプリのユーザーに公開される予定です。

これらの画像は方向性を示すものであり、変更される場合があります。
 
自信をもってアプリを運営するために実用的な知見を獲得
Firebase を使うと、アプリのパフォーマンスや安定性を監視したり、変更点をテストしたり、問題を解決する方法についての知見を得たりできるので、可能な限り最高のエクスペリエンスを提供できます。
 
Performance Monitoring の新しいリアルタイム アラート
Firebase Performance Monitoring はアプリのパフォーマンスについてのデータを収集して提示してくれるので、アプリで厳密に何が起きているのかや、アプリが遅いとユーザーが感じたタイミングをユーザー視点で把握することができます。しかし、ローカルマシンでどれほど徹底的にアプリをテストしたとしても、ユーザーは異なるデバイス、異なる国、異なるネットワーク スピードでアクセスしているため、アプリに遅延の問題が発生する可能性が残ります。そこで、皆さんに情報を提供し続けることができるように、パフォーマンス アラートという新機能をベータ版としてリリースします。この新しいパフォーマンス アラートは、遅延の問題が発生したときに即座に調査や修正ができるように、アプリの起動時間が一定のしきい値を超えるとメールを送信してくれます。パフォーマンス アラートはコンソールから設定できます。その他のパフォーマンス指標のアラートも、近日中に追加する予定です。

Performance Monitoring の新しいリアルタイム アラートを使うと、アプリの起動時間が遅くなったときに通知を受け取ることができます
 
Crashlytics に ANR(応答しないアプリ)レポートとシグナルを追加
Firebase Crashlytics を使うと、アプリの安定性を完全に把握することができるので、バグによりたくさんのユーザーに影響がでる前に、バグの追跡や優先順位付け、解消を行うことができます。また、Crashlytics で Apple のプラットフォームやゲームのレポートのサポートが強化された結果、Crashlytics が ANR(応答しないアプリ)エラーを報告できるようになりました。私たちの調査によると、ANR は Android のすべての意図しないアプリ終了のほぼ 50% を占めています。つまり、アプリの品質にとって、クラッシュよりも ANR の方が有害である可能性があります。そこで、アプリの安定性の問題を完全に把握できるように、Crashlytics は ANR と影響を受けたスレッドのコンテキスト情報を報告するようになります。そのため、ANR が起きる理由をピンポイントで特定できます。

Crashlytics が応答しないアプリによるエラーを報告するようになったため、アプリの安定性を包括的に把握できます
 
また、Crashlytics の新しいコンセプトであるシグナルも導入しました。このシグナルは、クラッシュを分析してトラブルシューティングに役立ちそうな共通点や特徴を見つけます。今回、早期クラッシュ、新しい問題、繰り返しの問題を表す 3 つのシグナルをリリースしました。早期クラッシュは、ユーザーがアプリを起動してすぐに発生したクラッシュを指します。新しい問題は直近 7 日以内の新しい問題を、繰り返しの問題はユーザーが何度も繰り返し遭遇している問題を指します。シグナルは、Apple と Android の両方のアプリ デベロッパーが利用できます。次にアプリをリリースするときに、ぜひ確認してみてください!

Crashlytics のシグナルは、トラブルシューティングに役立つ可能性があるクラッシュの共通点や特徴を明らかにします
 
強力なエンゲージメント ツールによる容易なスケーリング
Firebase は、エンゲージメントや収益の増加など、皆さんが望むビジネスの成果を実現するために必要な制御や自動化、柔軟性を、アプリの拡大に合わせて提供します。
 
Cloud Messaging と In-App Messaging のキャンペーン管理機能の統合
Firebase Cloud Messaging を使うと、異なるプラットフォームのユーザーを対象に、ターゲットを絞ってカスタマイズしたプッシュ通知を自動で簡単に送信できます。そのため、 積極的にアプリを使っていないユーザーにアプローチできます。Firebase In-App Messaging を使うと、コンテキストに合わせたメッセージを 積極的にアプリを使っているユーザーに送れます。そのため、重要なアプリ内アクションを行ってもらうように促すことができます。この 2 つのプロダクトは、連動してユーザーのエンゲージメントを維持します。今回、コンソールによる操作を再設計し、この 2 つの機能を統合しました。この統合ダッシュボードを使うと、メッセージング キャンペーン全体を包括的に確認できるので、異なるユーザーを対象に洗練されたマルチタッチ キャンペーンを行い、その反応を 1 か所で確認できます。たとえば、Cloud Messaging と In-App Messaging の両方が Google アナリティクスの新しい予測オーディエンスとシームレスに連携するので、離脱しそうなユーザーにクーポンコードを送信してつなぎ止めることができます。新しい統合ダッシュボードを使ってみるには、コンソールを開いて [Preview now] ボタンをクリックしてください。



Cloud Messaging と In-App Messaging の統合ダッシュボードでは、1 か所でキャンペーンの確認と管理が行えます
 
Remote Config コアの改善とパーソナライゼーション機能のベータ版リリース
ユーザーを維持して喜ばせるためのもう 1 つの方法は、ユーザーのニーズや嗜好に合わせてアプリをパーソナライズすることです。Firebase Remote Config を使うと、新しいバージョンをリリースすることなく、アプリの外観や動作を動的に制御して変更できます。今回、パーソナライゼーションと呼ばれる新しい Remote Config の機能がベータ版としてリリースされたことをお知らせします。パーソナライゼーション機能は、皆さんが重視する目標を最大化できるように、機械学習の力を利用して個々のユーザー エクスペリエンスを 自動的に 最適化してくれます。最初にシンプルな設定さえしておけば、それぞれのユーザーの成果が最高になるようなアプリの設定を継続的に見つけて適用してくれるので、皆さんの負担を軽減できます。
 
ジェットパック・ジョイライド、ダン・ザ・マン、そして人気作 Fruit Ninja などのタイトルを手がけているゲームスタジオ Halfbrick は、既にパーソナライゼーションを使って収益を 16% (英語)、アプリストアでの肯定的な評価を 15% アップさせています。別の早期ユーザーである Ahoy Games は、たくさんのゲームでパーソナライゼーションを試し、チームの作業をほとんど、あるいはまったく行うことなく、アプリ内購入を 12~13% 増加 (英語) させています。

Remote Config のパーソナライゼーションは、目標を達成するために機械学習を使ってユーザー エクスペリエンスを最適化します
 
Remote Config のコア機能にも、いくつかの改善を加えました。たとえば、パラメータの編集フローをアップデートしてターゲッティング条件やデフォルト値の変更を簡単にしたことや、データタイプのサポートの追加によってデータの検証を強化し、不適切な値をユーザーに配信してしまうリスクを軽減したことなどです。さらに、変更履歴を刷新し、最後のパラメータの変更がいつどのように行われたのかがはっきりわかるようにしました。これにより、主な指標の変化と相関性があるのはどの設定の変更なのかが理解しやすくなります。Remote Config のコンソールを開くと、これらのアップデートを確認できます。早速パーソナライゼーションをお試しください。

Remote Config のターゲッティングとデータ検証の改善
 
皆さんのアプリ体験をサポートするパートナー
私たちは、アプリの開発から最適化まで、すべての行程をサポートするパートナーです。私たちが目指すのは、アプリ開発を簡単かつ高速にし、皆さんが効率的に成功を収められるようにすることです。ユーザーやビジネスにとって最適なアプリにするため、ぜひ Firebase をご活用ください。今回お知らせした内容についてさらに詳しく知りたい方は、Firebase Summit のテクニカル セッションや Codelab、デモをご覧ください (英語)。2022 年にリリースされる予定の機能を一足先に見てみたい方は、アルファ版プログラムにご参加ください (英語)。


Reviewed by Tamao Imura - Developer Marketing Manager, Google Play

この記事は Pratyush Sinha による Chromium Blog の記事 "Run on OS Login" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ユーザーは、デバイスにログインするときに、メールやチャット、その他のよく使う生産性向上アプリケーションを自動起動したいと考えています。ログイン時にそのようなアプリを自動起動すれば、デバイスにログインしてから手動でアプリを起動する必要がなくなるので、ユーザー エクスペリエンスを効率化できます。

Windows、Mac、Linux のデバイスでは、スタートアップ時に自動起動するようにネイティブ アプリを設定できます。Run on OS Login(OS ログイン時に実行)機能は、Chrome 91 で導入されました。この機能がリリースされたことで、ユーザーが Windows、Mac、Linux のデバイスにログインしたときに、デスクトップ ウェブアプリを自動起動する設定が可能になっています。 インストール済みのアプリは、自身の自動実行を自動的に有効化することはできません。常にユーザーによる手動操作が必要です。
OS ログイン時にアプリを実行するよう設定するには、Chrome ブラウザを開き、chrome://apps に移動するか、ブックマーク バーの [ アプリ ] アイコン(下の例)をクリックします。


ログイン時にアプリを起動するように設定したい場合は、まずそのアプリを右クリックし、コンテキスト メニューから [ ログイン時にアプリを開く ] を選択します。以上で設定は完了で、次にデバイスにログインするとアプリが自動的に起動します。アプリでこの機能を無効にするには、chrome://apps に移動します。アプリを右クリックしてコンテキスト メニューを表示し、[ ログイン時にアプリを開く ] 項目の選択を解除します。

Run on OS Login で起動するアプリは、デバイスが実行されてから起動します。Run on OS Login はブラウザのみの機能であり、アプリ デベロッパーに起動元に関する情報が開示されることはありません。

Google はウェブ プラットフォームを継続的に改善し、日々のタスクを手間をかけずに安全に行える方法をユーザーに提供します。インストール済みのウェブアプリを OS ログイン時に実行できるようにすることは、コンピュータをオンにしたときにチャット、メール、カレンダーなどのクライアント アプリをすぐに使いたいユーザーにとって、スタートアップ ルーチンを簡素化するための小さいながらも重要な一歩です。いつものように、皆さんのフィードバックをお待ちしています。皆さんからのフィードバックは、私たちが今後のステップに優先順位を付けることに役立ちます。

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome ブラウザ、プロダクト マネージャー、Yana Yushkina による Chromium Blog の記事 "Searching, browsing, and shutdown Chrome performance improvements" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome では、さまざまなプロジェクトを通じて、パフォーマンスを改善するための長期的な取り組みが行われています。今回の速さと好奇心シリーズの投稿では、スピード、メモリ、意図しないハングに関する改善について紹介します。現在、検索の 6 回に 1 回は一瞬で終わり、PartitionAlloc に関する作業によって Chrome OS でのブラウジングで最大 20% のメモリが削減され、Chrome OS と Windows のシャットダウン操作に関する厄介な問題も解消されています。
アドレスバー Chrome のアドレスバーを使ってウェブを検索すると、文字を入力するのに合わせて検索語句の候補が表示されることに気づくはずです(Chrome の設定で [ 検索語句や URL をオートコンプリートする ] 機能をオンにしている場合)。これにより、検索語句すべてを入力する必要がなくなるので、情報の検索が迅速かつ簡単になります。求めている検索語句が提案されるまでテキストを入力すれば、すぐにそれを選択できます。




Chrome で検索すれば、さらに高速になります。提案された検索語句が選ばれる可能性が高い場合、検索結果がプリフェッチされるようになったからです。つまり、皆さんが検索語句を選択する前にウェブサーバーから結果を取得するので、検索結果が表示されるまでの時間がさらに短縮されます。実際に実験を行ったところ、検索結果が 500 ミリ秒以内に表示される可能性が 4 倍になったことがわかりました。

現在、この処理が行われるのは、Google 検索がデフォルトの検索エンジンになっている場合だけです。しかし、こちらの記事で説明しているように、提案する検索語句をサーバーから Chrome に送信する際に情報を追加することで、他の検索プロバイダもこの機能をトリガーできます。

Chrome OS の PartitionAlloc Chrome の新しいメモリ アロケータである PartitionAlloc は、M89 で Android と Windows にロールアウトされました。その結果、メモリ使用量を「最大 22% 節約」でき、パフォーマンスについては「応答性が最大 9% 向上」しました。それ以降も、Linux には M92 で、Chrome OS には M93 で PartitionAlloc を導入しました。うれしいことに、Chrome OS の M93 のフィールド データから、合計メモリ フットプリントが 15%、ブラウザ プロセスのメモリが 20% 減少し、単一タブ、複数タブの両方で Chromebook のブラウジング体験が向上したことがわかりました。

シャットダウン時に最も頻繁に発生するハングを解消 パフォーマンスを改善するため、ソフトウェア エンジニアがシステムにキャッシュを追加するのはよくあることです。しかし、キャッシュの副作用として他の問題(コードの複雑化、安定性、メモリ消費、データの整合性)が発生することも多く、逆にパフォーマンスが悪化する可能性すらあります。今回の事例では、起動時間を短縮するため、数年前に Chrome の履歴システムにローカル キャッシュを追加していました。当時の前提は、Chrome の内部メモリに履歴インデックスをキャッシュする方が、起動のたびに履歴のインデックスを再作成するよりも速いというもので、ラボ環境でのテストでもそれが実証されていたようです。

しかし、クラッシュ データと匿名のパフォーマンス指標から実世界でのパフォーマンスを体系的に調査し続けた結果、このキャッシュによってコードが複雑になり、メモリ使用量が不必要に増加しているだけでなく、シャットダウン時にブラウザがハングする問題の一番の要因にもなっていることがわかりました。その原因は、システムの別の場所で他の I/O が起こり続けている間、バックグラウンド優先スレッドの I/O 枯渇状態が延々と続く OS があることです。さらに、フィールド データの解析結果によれば、パフォーマンス面でユーザーが受けるメリットはほとんどありませんでした。現在は、このキャッシュを削除することで、シャットダウン時に最も頻繁に発生していたハングを解消しています。これは、キャッシュは必ずしも正解ではないという原則を示す好例となりました。

今後もさまざまなパフォーマンスの改善についてお知らせしますので、ご期待ください。

すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ 


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Android、Pixel、および Tensor セキュリティ チーム、 Dave Kleidermacher、Jesse Seed、Brandon Barbello、Stephan Somogyi による Google Online Security Blog の記事 "Pixel 6: Setting a new standard for mobile security" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

リリースされたばかりの Pixel 6 と Pixel 6 Pro は最も安全な Pixel スマートフォンであり、5 年間にわたるセキュリティ アップデートが適用されるほか、最もレイヤー数の多いハードウェア セキュリティを備えています。これらの新しい Pixel スマートフォンでは、レイヤー化されたセキュリティ アプローチを採用しており、Google Tensor SoC(System on a Chip)ハードウェアから Pixel で先行利用できる Android オペレーティング システムの新機能に至るまでのイノベーションを活用して、チップからデータセンターまでを網羅する Google セキュリティが適用された最初の Pixel スマートフォンを実現しました。また、複数の専属のセキュリティ チームが開発を担当して、透明性と外部検証を通じて Pixel のセキュリティを証明しています。

コアにセキュリティを提供

Google は、Google Tensor を使用して、ハードウェア セキュリティの最重要部にユーザーデータの保護と透明性を提供しています。Google Tensor のメイン プロセッサは Arm ベースであり、TrustZone™ テクノロジーを活用しています。TrustZone は、一般的な処理を安全に行うセキュリティ アーキテクチャの重要な要素ですが、Google Tensor に含まれているセキュリティ強化は、TrustZone の一歩先を進んでいます。

図 1. Pixel の安全な環境

Google Tensor セキュリティ コアは、ユーザー プライバシーの保護に特化したカスタム設計のセキュリティ サブシステムです。このサブシステムは、アプリケーション プロセッサとは論理的かつ物理的に異なり、専用 CPU、ROM、OTP(1 回しか書き込めない)メモリ、暗号化エンジン、内部 SRAM、保護された DRAM で構成されます。Pixel 6 と Pixel 6 Pro の場合、セキュリティ コアの主要なユースケースには、実行時にユーザーデータ キーを保護したり、セキュアブートを強化したり、Titan M2TM と連携したりすることが含まれます。

ハードウェアの安全性は、OS が安全であるときにのみ確保されます。Google では、オープンソースの信頼できる実行環境である Trusty を使用しています。Trusty OS は、TrustZone と Google Tensor セキュリティ コアの両方で使用される安全な OS です。

Pixel 6 と Pixel 6 Pro では、Google がすべてを設計して開発した別個のセキュリティ チップである新しい Titan M2TM によってセキュリティが強化されています。この次世代チップを採用したことにより、Google は社内設計した RISC-V プロセッサに移行し、速度とメモリ容量を向上し、高度な攻撃に対する耐性をさらに強化しています。Titan M2TM は、独立した認定済みの評価ラボによって、脆弱性評価の最も厳格な標準である AVA_VAN.5 に照らしてテストされています。Titan M2™ は Android StrongBox をサポートします。Android StrongBox は、PIN とパスワードの保護に使用されるキーを安全に生成して格納し、Google Tensor セキュリティ コアと連携して、SoC で使用中のユーザーデータ キーを保護します。

システムが改善された Pixel 6 と Pixel 6 Pro は、Android 12 と、Pixel で先行利用や限定利用ができるたくさんの機能が搭載された状態で出荷されます。

強化されたコントロール

Google は、Android のリリースのたびに、データをコントロールしてデバイスを管理するより適切な方法をユーザーに提供することを目指しています。Pixel で使用される Android 12 以降では、新しいセキュリティ ハブを使用して、すべてのセキュリティ設定を 1 か所で管理することができます。つまり、デバイスの現在の構成を一元的に表示することにより、スマートフォン、アプリ、Google アカウント、パスワードを保護できるようにしています。また、セキュリティ ハブは、セキュリティを改善するための推奨事項を提供するため、ニーズに最適な設定を判定できるようになります。

Google はプライバシーのためにプライバシー ダッシュボードをリリースし、過去 24 時間以内に位置情報、マイク、カメラにアクセスしたアプリをシンプルで明確なタイムライン形式で表示できるようにしています。予想よりも多くのデータにアクセスしているアプリに気付いた場合、ダッシュボードには、それらのアプリのパーミッションをすぐに変更できるコントロールへのパスが表示されます。

さらに透明性を向上するため、アプリがカメラやマイクにアクセスしていることが、Pixel のステータスバーにある新しいインジケーターでわかるようになっています。アクセスを無効にしたい場合、プライバシーの新しい切り替え機能により、1 回タップするだけで、スマートフォンのアプリによるカメラやマイクへのアクセスをいつでもオフにすることができます。

Pixel 6 と Pixel 6 Pro には、セキュリティが低い 2G ネットワークにアクセスするデバイスの機能を削除する切り替え機能も含まれています。一部の状況では 2G ネットワークへのアクセスが必要になりますが、さらなる攻撃ベクトルが発生する可能性があります。この切り替え機能は、2G 接続が不要なときに、そのリスクを軽減することに役立ちます。

組み込みのセキュリティ

Google はすべてのプロダクトをデフォルトで安全にするために、オンラインの安全を維持することに他の誰よりも取り組んでいます。また、Pixel 6 と Pixel 6 Pro では、デフォルトで組み込まれている保護機能を強化しています。

画面に埋め込まれた光学指紋認証センサーは、バイオメトリック情報の安全を確保し、デバイスの外に流出することを防ぎます。Google の継続的なセキュリティ開発ライフサイクルの一環として、Pixel 6 と Pixel 6 Pro の指紋認証によるロック解除は、外部のセキュリティ エキスパートによって、Android 12 互換性定義ドキュメント(Compatibility Definition Document、CDD)で定義されているクラス 3 強度要件を満たす安全な生体認証ロック解除メカニズムとして検証されています。

フィッシングは強大な攻撃ベクトルであり続け、さまざまなデバイスを使用しているすべての人に影響を及ぼしています。

Pixel 6 と Pixel 6 Pro では、新しいフィッシング対策保護機能が導入されています。組み込みの保護機能は、通話、テキスト メッセージ、メール、アプリを通じて送信されるリンクからの潜在的な脅威を自動的にスキャンし、潜在的な問題がある場合は、ユーザーに通知します。

また、ユーザーは、Google Play プロテクト内のオンデバイス検出機能に加えられた機能強化により、悪意のあるアプリからより強固に保護されています。Google Play プロテクトは 2017 年にリリースされて以来、デバイスがオフラインのときでも、悪意のあるアプリを検出できるようにしてきました。Pixel 6 と Pixel 6 では、Google Play プロテクトでのマルウェア検出を強化する新しい機械学習モデルを使用しています。この検出機能は Pixel で実行され、フェデレーション アナリティクスと呼ばれるプライバシー保護テクノロジーを使用して、一般的に実行される悪意のあるアプリを検出します。これにより、すでに 1,000 億個のアプリを毎日分析して脅威を検出している Google Play プロテクトが改善され、30 億人を超えるユーザーにさらに強固な保護を提供します。

Pixel の多くのプライバシー保護機能は、残りのオペレーティング システムやアプリから分離されたオープンソースのサンドボックスである Private Compute Core 内で実行されます。Google のオープンソースの Private Compute Services は、これらの機能のネットワーク通信を管理し、プライバシーを保護すると同時に、フェデレーション ラーニング、フェデレーション アナリティクス、個人情報の取得を通じて機能を改善します。Private Compute Core ですでに実行されているいくつかの機能には、自動字幕起こし、この曲なに?、スマート リプライの提案などが含まれます。

Google Binary Transparency(GBT)は、Google のオープンで検証可能なセキュリティ インフラストラクチャに追加された最新機能であり、デバイスのソフトウェア整合性に新しいレイヤーを追加します。証明書の透過性によって導かれる原則を基に構築された GBT は、Pixel で実行できるソフトウェアを、認定された OS ソフトウェアのみに限定します。GBT は、システム イメージのハッシュを署名し、追加専用のログに格納することで機能します。このログは公開され、公開されたハッシュとデバイスにあるハッシュが同じであることを検証するために使用できます。これにより、ユーザーと研究者は初めて、OS の整合性を独立して検証できるようになりました。

スマートフォン以外への拡張

多層防御は、ハードウェアとソフトウェアのレイヤーだけの問題ではありません。セキュリティは厳密なプロセスです。Pixel 6 と Pixel 6 Pro では、設計やアーキテクチャの詳細なレビュー、セキュリティ上重要なコードのメモリ安全な書き換え、静的分析、ソースコードの公式検証、重要なコンポーネントのファジング、デバイスに侵入テストする外部のセキュリティ ラボなどが含まれたレッドチームを活用しています。また、Pixel は Android 脆弱性報奨金プログラムに含まれています。昨年、このプログラムでは 175 万ドルが支払われ、Google とセキュリティ リサーチ コミュニティの間に有益なフィードバック ループを構築したほか、最も重要であるユーザーの安全を引き続き確保できるようにしています。

ハードウェアとソフトウェアが組み合わされた、このセキュリティ システムを締めくくるのは Titan Backup Architecture です。このアーキテクチャにより、クラウドでの Pixel の安全な土台が確保されます。Android のバックアップ サービスと Google Cloud の Titan テクノロジーの組み合わせは 2018 年に発表され、クライアント以外は Google を含め誰もが知らないランダムに生成されたキーのみによって、バックアップされたアプリケーション データを復号化できるようにします。このエンドツーエンドのサービスはサードパーティのセキュリティ ラボによって別個に監査され、パスコードを明確に知らない限り、ユーザーのバックアップされたアプリケーション データに誰もアクセスできないことが検証されました。

ハードウェアやソフトウェアからデータセンターに至るまでのこのエンドツーエンドのセキュリティに加え、Pixel 6 と Pixel 6 Pro デバイスでは、米国で発表されてから 5 年以上の Android セキュリティ アップデートが保証されています。これは、業界にとって重要な取り組みであり、他のスマートフォン メーカーもこの取り組みを推進することを望んでいます。

Google は安全なチップセット、ソフトウェア、プロセスを連携させることにより、Pixel 6 と Pixel 6 Pro を最も安全な Pixel スマートフォンにすることができました。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google オープンソース プログラム オフィス、Anne Bertucio による Google Open Source Blog の記事 "Protect your open source project from supply chain attacks" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

米国の大統領令から鍵署名パーティまで、2021 年はサプライ チェーンのセキュリティが取りざたされる一年になっています。オープンソースのメンテナンス担当者がプロジェクトのサプライ チェーン全体の攻撃面や脅威ベクトルについて知れば、克服できないと感じて打ちひしがれるかもしれません。朗報なのは、2021 年がサプライ チェーン セキュリティ ソリューションの一年でもあったということです。行うべき作業はまだ多く残されており、既存のソリューションも多くの改善の余地を抱えています。しかし、サプライ チェーンを強化してセキュリティ侵害を防ぐために、今すぐプロジェクトに適用できる予防措置があります。

All Things Open 2021 の参加者は、クイズゲームを通してサプライ チェーンのセキュリティに関するベスト プラクティスを学びました。このブログ投稿では、クイズの問題と解答、そして予防措置の選択肢を紹介します。また、この投稿はサプライ チェーン攻撃からオープンソース プロジェクトを守りたい方向けの初心者向けガイドにもなります。以降で紹介する推奨事項は、SLSA フレームワークOpenSSF Scorecards の重要事項に従っており、その多くは Allstar プロジェクトを使って自動的に実装できます。
典型的なソフトウェア サプライ チェーンと、その接続点で発生する可能性がある攻撃の例
典型的なソフトウェア サプライ チェーンと、その接続点で発生する可能性がある攻撃の例

Q1 : デベロッパー アカウントの乗っ取りを防ぐためにするべきことは何ですか?
  1. 正解 : 多要素認証を利用する(可能ならセキュリティ キー)
  2. コア メンテナンス担当者向けの共有アカウントを利用する
  3. パスワードはすべて rot13 で記述する
  4. IP 許可リストを利用する
理由と解説 : 悪意のある人物がデベロッパー アカウントにアクセスできる場合、既知の貢献者になりすまして悪意のあるコードを送信する可能性があります。貢献者には、commit を送るプラットフォームだけでなく、メールなどの貢献に関連するアカウントに対して、多要素認証(MFA)を使うことを推奨しましょう。可能であれば、MFA の方式でお勧めなのはセキュリティ キーです。

Q2 : 悪意のある commit をマージしないために、するべきことは何ですか?
  1. 正解 : すべての commit で、commit の作成者以外の誰かによるレビューを必須とする
  2. すべての commit に対して自動実行テストをする
  3. すべての commit に対して 'bitcoin' という単語をスキャンする
  4. 1 年以上前からアカウントを使っている貢献者からの commit のみを受け付ける
理由と解説 : セルフマージ(一方的な変更とも呼ばれます)には、1)貢献者のアカウントを乗っ取った攻撃者がプロジェクトに悪意のあるコードを注入する可能性がある、2)善意の貢献者が意図しないセキュリティ リスクを含む commit をマージする可能性がある、という 2 つのリスクがあります。悪意のあるコードの送信や意図しない脆弱性を回避するために役立つのが、身元が明らかで信頼できる別の人の目です。可能であれば、GitHub のブランチ保護設定などを使い、自動要件として設定しましょう。Allstar などのツールも、この要件の適用に役立ちます。これは、SLSA レベル 4 に対応します

Q3 : CI/CD パイプラインで使うシークレットはどのように保護しますか?
  1. 正解 : シークレット マネージャー ツールを利用する
  2. シークレットへのアクセスを管理するメンテナンス担当者を任命する
  3. シークレットを環境変数に保存する
  4. シークレットを別のリポジトリに保存する
理由と解説 : 「多層防御」というセキュリティの考え方は、複数の異なる防御レイヤーを設けてシステムやシークレット * などの機密データを守ることを指します。シークレット マネージャー ツール(GCP ユーザーの Secret Manager や、HashiCorp Vault、CyberArk Conjur、Keywhiz など)を使うと、ソースコードにシークレットをハードコードする必要はなくなり、集中管理や機能の監査を実現できます。また、シークレットの漏洩を防ぐ認可レイヤーを導入することにもなります。

* 機密データを CI システムに保存する場合は、それが CI/CD のためだけに使われることや、パスワードや ID マネージャーに格納するほうが適したデータではないことを確認してください。

Q4 : CI/CD システムを不正利用から守るためにするべきことは何ですか?
  1. 正解 : 最小権限の原則に従ったアクセス制御を行う
  2. すべての pull リクエストと commit に対して結合テストを行う
  3. すべての貢献者に GitHub のロール "Collaborators" を設定する
  4. ローカルで CI/CD システムを実行する
理由と解説 : デフォルトでプロジェクト リポジトリに対して「必要最低限のアクセス」を付与することで、意図しないアクセスと不正利用の両方から CI/CD システムを守ることができます。テストを行うことは重要ですが、デフォルトですべての commit と pull リクエストに対してレビュー前にテストを実行すると、CI/CD システムのコンピューティング リソースの意図しない不正利用につながる可能性があります。

Q5 : ビルド中のセキュリティ侵害を避けるためにするべきことは何ですか?
  1. 正解 : ビルドの定義や構成を build.yaml などのコードで定義する
  2. コードを侵害する時間を攻撃者に与えないように、可能な限りビルド時間を短縮する
  3. ビルドシステムには LEGO ブランドの部品だけを使い、代替品は認めない
  4. 攻撃者の手がかりとなるものを残さないように、ビルドログを削除する
理由と解説 : 手動でビルド手順を実行すると、意図しない構成ミスが紛れ込む可能性があります。しかし、ビルド スクリプト(ビルドやビルドの手順を定義した build.yaml などのファイル)を使えば、手動でビルドする必要はなくなります。加えて、悪意のある人物がビルドを改ざんしたり、レビューされていない変更を紛れ込ませたりする機会を減らすことにもなります。これは、SLSA レベル 1~4 に対応します

Q6 : 依存関係の利用前評価はどのように行うべきですか?
  1. 正解 : Scorecardsdeps.dev などのツールを使ってリスクと推移的な変更を評価する
  2. パッケージ URL の隣に表示される小さな「鍵」アイコンをチェックする
  3. GitHub で最低 1,000 個のスターが付いている依存関係のみを利用する
  4. メンテナンス担当者が一度も変更されていない依存関係のみを利用する
理由と解説 : 1 つの決定的な手法でパッケージが「良い」か「悪い」かを判断することはできません。セキュリティ プロファイルや許容できるリスクは、プロジェクトごとに異なります。プロジェクトにとって依存関係が「安全」であるかどうかを判断するうえで役立つのは、依存関係やどのような変更が推移的に取り込まれるかの情報を集めることです。Open Source Insights(deps.dev)などのツールは、最初のレイヤーと推移的依存関係をマッピングしてくれます。一方の Scorecards は、セキュリティ ポリシー、MFA、ブランチ保護の使用有無など、複数のリスク評価指標に基づいてパッケージのスコアを算出します。

使っている依存関係を把握できたら、定期的に Open Source Vulnerabilities などの脆弱性スキャンツールを実行します。そうすることで、常に最新のリリースやパッチについての情報を得ることができます。多くの脆弱性スキャンツールは、アップグレードの自動適用にも対応しています。

Q7 : ビルドが自分の意図したビルドであることを保証する(すなわち、検証する)ために、何をするべきですか?
  1. 正解 : 来歴の認証を生成できるビルドサービスを利用する
  2. 最新の commit をチェックし、信頼できるコミッターのものであることを確認する
  3. ステガノグラフィーを使ってプロジェクトのロゴをビルドに埋め込む
  4. リリースのたびに適合テストを行う
理由と解説 : ビルドの出所(ビルドの来歴)とアーティファクトを表示すると、ビルドが改ざんされていないことや、正しいものであることをユーザーに示すことができます。来歴にはさまざまな要素があります。こういった要素を実現する 1 つの方法は、来歴を表示するために必要なデータを生成と認証するビルドサービスを利用することです。これは、SLSA レベル 2~4 に対応します

Q8 : レジストリからアーティファクトを選ぶ際に、求めるべきことは何ですか?
  1. 正解 : アーティファクトが暗号学的に検証可能な形で署名されていること
  2. アーティファクトが(墓から盗み出されて)呪われたものでないこと
  3. タイムスタンプ : 最新のアーティファクトのみを使う
  4. 公式認定 : 信頼できるブランドや標準化団体のロゴを探す
理由と解説 : 来歴の生成やビルドの署名は、自分のプロジェクトで行うべきことであるだけでなく(SLSA レベル 2~4)、他者のアーティファクトを使うときも、同じ証明を求めるべきです。ロゴなどのブランドに基づく認定形態は偽造可能で、タイポスクワッティングによって正当性を偽装できます。署名などの偽造できない証明を求めるようにしてください。たとえば Sigstore は、OSS プロジェクトでビルドに署名したり、他者のビルドを検証したりする際に役立ちます。

プロジェクトのセキュリティ改善は継続的な取り組みです。ここで紹介した推奨事項の中には、プロジェクトですぐに採用するのが現実的ではないものもあるかもしれません。しかし、プロジェクトのセキュリティ向上のために行える手順はすべて、正しい方向に向かう一歩です。
オープンソース プロジェクトのセキュリティに関連するリソース :
  • SLSA : サプライ チェーンのセキュリティ レベルに関するフレームワーク
  • Scorecards : セキュリティのベスト プラクティスの使用状況を測定
  • Allstar : セキュリティのベスト プラクティスを強制する GitHub アプリ
  • Open Source Insights : オープンソース プロジェクトの依存関係の視覚化と検索
  • OSV : オープンソース用の脆弱性データベースと自動化インフラストラクチャ

Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chromium Blog の記事 "Chrome 96 Beta: Conditional Focus, Priority Hints, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


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

3 桁のバージョン番号に対する準備

来年には、Chrome でバージョン 100 がリリースされます。つまり、Chrome のユーザー エージェント文字列で報告されるバージョン番号の桁が増えます。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されています。chrome://flags/#force-major-version-to-100 と呼ばれるこの新しいフラグは、Chrome 96 以降で利用できます。

オリジン トライアル

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

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

Conditional Focus

現在、他のウィンドウやタブをキャプチャするアプリケーションには、呼び出し元のアイテムやキャプチャするアイテムにフォーカスするかどうかをコントロールする方法がありません(ビデオ会議アプリのプレゼンテーション機能を思い浮かべてください)。Chrome 96 では、新しい focus() メソッドをサポートする FocusableMediaStreamTrack と呼ばれる MediaStreamTrack のサブクラスを使用して、このコントロールを可能にしました。次のコードをご覧ください。

stream = await navigator.mediaDevices.getDisplayMedia();
let [track] = stream.getVideoTracks();

このコードでは、以前は getVideoTracks()MediaStreamTrack オブジェクトの配列を返していましたが、FocusableMediaStreamTrack オブジェクトを返すようになります(Chrome 97 では、返されるオブジェクトが BrowserCaptureMediaStreamTrack に変更される予定です。本記事の執筆時点で、Canary 版ではすでに新しいオブジェクトが返されるようになっています)。

フォーカスするディスプレイ メディアを決定するには、このコードの次の行で "focus-captured-surface" を指定して track.focus() を呼び出し、新しくキャプチャするウィンドウやタブにフォーカスするか、"no-focus-change" を指定してこのメソッドを呼び出し、呼び出し元のウィンドウにフォーカスし続けます。Chrome 96 以降では、デモコードを試して、この機能の動作を確認できます。

Priority Hints

Priority Hints では、デベロッパーが設定する "importance" 属性が導入され、計算されるリソースの優先度を変更することができます。サポートされる importance 属性の値は、"auto""low"、と "high" です。Priority Hints は、リソースの相対的な重要度をブラウザに示し、リソースが読み込まれる順序をより細かくコントロールできるようにします。ブラウザでは、リソースのタイプ、可視性、プリロードのステータスなど、多くの要素がリソースの優先度に影響を及ぼします。

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

プリフライトなしに単純な Range ヘッダー値を許可

プリフライト リクエストなしに、単純な Range ヘッダーを指定してリクエストを送信できるようになりました。CORS リクエストでは、プリフライト リクエストをトリガーせずに、Range ヘッダーを限定的な方法(1 つの有効な範囲のみ)で使用できます。

デスクトップのバックフォワード キャッシュ

バックフォワード キャッシュにページが格納され、クロスサイト ナビゲーションをした後でも、以前にアクセスしたページへの即時ナビゲーションが可能になります。

Cross-Origin-Embedder-Policy: credentialless

Cross-Origin-Embedder-Policy には、クロスオリジン no-cors リクエストで認証情報(Cookie やクライアント証明書など)を省略できるようにする新しい credentialless オプションが追加されます。COEP:require-corp と同じように、クロスオリジン分離も有効化できます。

SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。COEP: require-corp を使用して、クロスオリジン分離のオプトインを大規模に導入することは難しく、すべてのサブリソースで明示的にオプトインしなければならなくなります。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト(Google Earth、ソーシャル メディア全般、フォーラムなど)では、依存関係の問題が発生します。

CSS

:autofill 疑似クラス

新しい autofill 疑似クラスを使用すると、自動入力されるフォーム要素のスタイルを設定できます。これは、:-webkit-autofill 疑似クラスの標準化として導入されており、WebKit ではすでにサポートされています。Firefox は、この標準バージョンをサポートします。

封じ込めが適用される場合に body スタイルからビューポートへの伝播を無効化

writing-mode、direction、background など、一部のプロパティは、body からビューポートに伝播されます。CSS コンテナクエリの無限ループを防ぐために、仕様と実装が変更され、HTML または BODY にレイアウトの封じ込めが適用される際にこれらのプロパティが伝播されなくなりました。

font-synthesis プロパティ

font-synthesis CSS プロパティは、フォント ファミリーにフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。

EME MediaKeySession が閉じられた理由

MediaKeySession.closed プロパティは、enum を使用して、MediaKeySession オブジェクトが閉じられた理由を示すようになります。この closed プロパティは、セッションが閉じたときに解決される Promise を返します。以前は Promise が解決されるだけでしたが、文字列として解決されるようになり、閉じられた理由を示します。返される文字列は、"internal-error""closed-by-application""release-acknowledged""hardware-context-reset""resource-evicted" のいずれかです。

HTTPS DNS レコードでの HTTP から HTTPS へのリダイレクト

Chrome では、DNS(ドメイン名サービス)から HTTPS レコードが利用できる場合は、常に HTTPS 経由でウェブサイトに接続します。

EventTiming の interactionID

PerformanceEventTiming インターフェースに interactiveID と呼ばれる属性が含まれるようになりました。これは、ブラウザが生成する ID であり、複数の PerformanceEventTiming エントリが同じユーザー操作に対応する場合、これらのエントリをリンクできるようにします。現在、デベロッパーは Event Timing API を使用して、関心のあるイベントのパフォーマンス データを収集できます。ただし、同じユーザー操作に対応するイベントをリンクすることは困難です。たとえば、ユーザーがタップしたときなら、pointerdownmousedownpointerupmouseupclick など、多くのイベントが生成されます。

新しいメディアクエリ : prefers-contrast

Chrome は、 'prefers-contrast' と呼ばれる新しいメディアクエリをサポートします。そのため、ウェブ制作者は、オペレーティング システムで設定されたユーザーのコントラスト設定(具体的には、macOS のコントラストを強調したモードと Windows のハイ コントラスト モード)にウェブ コンテンツを合わせることができます。有効な選択肢は、'more''less''custom'、または 'no-preference' です。

デスクトップ PWA の一意の ID

ウェブアプリ マニフェストで任意の id フィールドがサポートされ、ウェブアプリをグローバルに特定できるようになりました。id フィールドがない場合、PWA は start_url にフォールバックします。現時点で、このフィールドはデスクトップのみでサポートされます。

PWA の URL プロトコル ハンドラ登録

ウェブ アプリケーションがインストール マニフェストを使用して、カスタム URL プロトコル / スキームのハンドラとして自身を登録できるようにします。多くの場合、オペレーティング システム アプリケーションは自身をプロトコル ハンドラとして登録して、見つけやすさと使用率を向上します。ウェブサイトは、すでに registerProtocolHandler() を介してスキームを処理するように登録できます。この新機能はもう一歩踏み込んで、カスタム スキーム リンクが呼び出されたときに、ウェブアプリを直接起動できるようにします。

WebAssembly

コンテンツ セキュリティ ポリシー

Chrome のコンテンツ セキュリティ ポリシーが強化され、WebAssembly との相互運用性が向上しています。wasm-unsafe-eval は、WebAssembly の実行をコントロールします(JavaScript の実行には影響しません)。また、script-src ポリシーに WebAssembly が含まれるようになりました。

参照型

WebAssembly モジュールで JavaScript オブジェクトや DOM オブジェクトへの参照を保持できるようになりました。具体的には、これらの参照は、引数として渡したり、ローカル変数やグローバル変数に格納したり、WebAssembly.Table オブジェクトに格納したりできます。

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

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

PaymentRequest API の "basic-card" 支払い方法

PaymentRequest API では、"basic-card" 支払い方法が非推奨となっています。その使用率は低いうえ、低下し続けています。この支払い方法の購入手続きまでの時間や購入完了率は、他の支払い方法を下回っています。デベロッパーは、代わりとして他の支払い方法に切り替えることができます。たとえば、Google Pay、Apple Pay、Samsung Pay などの支払い方法です。

削除までのタイムライン :

  • Chrome 96: "basic-card" 支払い方法は、レポーティング API で非推奨となります。
  • Chrome 100: "basic-card" 支払い方法は削除される予定です。

Reviewed by Eiji Kitamura - Developer Relations Team

Google for Startups Accelerator のメンターを募集します。

Google はテクノロジーが社会をより良くしていくと考えています。私たちは社会の大きな課題を解決するためのアイデアを持つスタートアップをテクノロジーの力で支援したいと考えています。そのため、Google では、Google for Startups Accelerator というスタートアップを支援するアクセラレータプログラムを日本でも継続的に行っております。

この度、Google for Startups Accelerator のプログラムにおいて、参加するスタートアップに対して技術的メンタリングを提供してくださるメンターを募集いたします。メンターの方にはスタートアップへのメンタリングを通じて、 テクノロジーを活用した社会、経済、環境といったさまざまな分野の問題解決への取り組みをともに解決し、ひいては、スタートアップの成長が日本経済のさらなる活性化につながることへの貢献を一緒に行っていければと考えています。

メンターとして参画してくださる方、ぜひこちらのフォームよりご応募ください。

Google for Startups Accelerator が求めるメンター

  • 次の技術のいずれかの知識・経験がある方 : Android, Google Cloud, Tensorflow, Machine Learning, Flutter, Firebase, Kotlin, Go, Web Technologies, Google Workspace
  • 知識を共有し、Google のスタートアップ コミュニティおよび、より幅広いスタートアップ エコシステムの成長に貢献する意欲がある。
  • アクセラレータ期間中、月に 4~8 時間程度メンタリングを行える事

メンターとして参加するメリット

  • Google プロダクト チームからの最新技術動向の共有
  • メンターとして Google のさまざまなイベントやプログラムでの紹介
  • Google のグローバル メンター ネットワークへの参加を通じて他国のメンターとの意見交換
  • ノベルティの贈呈

募集概要

  • 対象 : Google のテクノロジー (Android, Flutter, ML, Google Cloud, Firebase) などについて一定の知見をお持ちの方
  • 形態 : オンライン
  • 募集開始 : 2021 年 11 月 22 日(月)
  • 募集締め切り : 2021 年 12 月 27 日(月)18 時
  • プログラム実施期間 : 2022 年 2 月 下旬~2022 年 5 月末(予定)
  • プログラム詳細はウェブサイトをご参照ください。




Posted by Reisa Matsuda and Takuo Suzuki - Developer Relations Team

この記事は Chrome チーム、デベロッパー アドボケート、Eiji Kitamura による Chromium Blog の記事 "Sunsetting the 'basic-card' payment method in the Payment Request API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Payment Request API推奨が近いウェブ標準であり、ウェブ デベロッパーが手間のかからない安全な支払いフローを簡単に構築できるようにすることを目的としています。ブラウザは、販売者のウェブサイトと「支払いハンドラ」との間のフローを容易にします。支払いハンドラは、ブラウザ、ユーザーのモバイル デバイスにインストールされたネイティブ アプリ、またはプログレッシブ ウェブアプリに組み込むことができます。現在、デベロッパーは Payment Request API を使用して、ほとんどのプラットフォームの Chrome で利用できる "basic-card" や Google Pay、Safari の Apple Pay、Google Play での Digital Goods API、Chrome の Secure Payment Confirmation など、いくつかの支払い方法にアクセスできます。

Google は昨年の初めに、iOS 版 Chrome に加えて、他のプラットフォームでも "basic-card" 支払いハンドラのサポートを終了する予定であることを発表しました。通常、ブラウザに組み込まれている支払い方法である "basic-card" は、クレジット カード番号を覚えたり、手動で入力したりすることなく、その番号を簡単に入力できるようにします。この支払い方法は、フォームベースのクレジット カード支払いからアプリベースのトークン化されたカード支払いへの移行をスムーズにするために設計されました。Web Payments WG は、アプリベースの支払いを促進する(また、その他のいくつかの理由で)という目標を達成するために、"basic-card" を仕様から削除することを決定しました。

Chrome バージョン 96 以降で "basic-card" 支払い方法が使われると、DevTools コンソールに警告メッセージが表示されます(レポーティング API のレポートも作成されます)。バージョン 100 では、"basic-card" 支払い方法が利用できなくなり、他の使用可能な支払い方法が指定されていない限り、canMakePayment()false を返します。これは、Android、macOS、Windows、Linux、Chrome OS など、すべてのプラットフォームに適用されます。

Payment Request API で "basic-card" 支払いハンドラを使用している場合は、この支払いハンドラをできるだけ早く削除して、Google Pay や Samsung Pay などの代替支払い方法を使用することをおすすめします。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Google Developers Blog の記事 "What is Google's Dev Library––a new open-source platform for developers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Dev Library ロゴのバナー 世界中のデベロッパーが、オープンソースのツールやチュートリアルを作成しています。しかし、それを見つけてもらうのは簡単なことではありません。多くの場合、公開されるコンテンツは、GitHub から Medium まで、たくさんのサイトにまたがっています。そこで Google は、Google のテクノロジーに関連する優れたプロジェクトを 1 か所にまとめて紹介する場所を作ることを決定し、Dev Library を公開しました。Dev Library は、Google のテクノロジーを使って構築されたプロジェクトや、それに関する記事を厳選して集めたアーカイブです。

このプラットフォームには、ブログ投稿やオープンソース ツールが掲載され、わかりやすい操作で閲覧できるようになっています。プロダクトの領域として、機械学習、Flutter、Firebase、Angular、クラウド、Android を扱っています。
Dev Library がほかと異なる点は何ですか? 皆さんが申請したすべての記事やプロジェクトがサイトに掲載されるとは限りません。Google のエキスパートからなるチームが、それぞれのトピックの正確性や関連性を吟味します。そのため、サイトに掲載されたコンテンツは、Google が承認したことを意味しています。

どのように役立ちますか? 目につきやすくなります。広い専門性を持っているデベロッパーでも、その知識をアピールするのは大変なことです。Dev Library は、皆さんが世界に向かって「ねえ!すばらしいプロジェクトを作ったんだけど、ぜひ見てみない?」と声をあげる方法の 1 つです。

さらに、同じように Dev Library でプロジェクトを公開している貢献者仲間のネットワークを得ることもできます。

貢献者の皆さんによる作業を応援するため、1 人ずつ専用の作者ページを作成して、1 か所でプロジェクトを一覧できるようにしています。

Dev Library ではどんなコンテンツが見つかりますか? このサイトに幅広いコンテンツが掲載されている証として、公開されているコンテンツや作成したデベロッパーの動画インタビューの一部を紹介しましょう。 最終的な目的は何ですか? 優れた文章を書けるデベロッパーを増やすことです。あらゆる種類のプロジェクトを経験し、知識を備えているにもかかわらず、それを表現するのに苦労するデベロッパーを見かけることは少なくありません。しかし、自分の作業について文章化できるデベロッパーがもっと必要です。経験してきた苦労や実際に書いたコードブロック、プロジェクトを形にする方法といった内容です。

Dev Library を通じて、変化を生み出したいと思っています。

優れた文章を書けるデベロッパーを増やし、マーケティングの質を向上させ、詳しい説明を待っている世界中のユーザーにアプローチしてもらえることを期待しています。

どうすれば Dev Library をサポートできますか? Dev Library をさらに成長させるために、皆さんにご協力いただける方法が 2 つあります。
  1. Dev Library で公開したい優れたコンテンツをお持ちの方は、こちらからレビューの申請をしてください。
  2. フィードバックも歓迎しています。Dev Library サイトに追加や変更の希望がある方は、こちらの簡単なフィードバック フォームに入力するか、GitHub で Issue を送信してください。
皆さんからの申請やフィードバックを楽しみにしております。

Dev Library が皆さんのオープンソース作品を公開するすばらしい場所になるように、ご協力をお願いいたします。

この記事はプライバシーおよびデータ保護オフィス、プロダクト マネージャー、Sam Heft-Luthy による Google Online Security Blog の記事 "Google Protects Your Accounts – Even When You No Longer Use Them" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

デジタル アカウントが使われなくなったら、何が起きるのでしょうか。これは、私たち全員が自問するべき質問です。使われなくなり、放置された古いアカウントは、サイバー犯罪のターゲットになる可能性があるからです。

実際、最近発生したよく知られている不正アクセスの相当数で、使われなくなったアカウントが狙われています。石油パイプライン会社 Colonial Pipeline が受けたランサムウェア攻撃を調査したコンサルタントによると、この攻撃は、使われなくなり、多段階認証が適用されていないアカウントを通して発生しました。今年の夏に起きた T-Mobile への不正アクセスも、古い請求ファイルを通して、使われなくなったプリペイド アカウントの情報がアクセスされました。使われなくなったアカウントは、深刻なセキュリティ リスクをもたらす可能性があります。

Google ユーザーがこの問題を解決するために利用できるのが、アカウント無効化管理ツール です。Google がアカウントを無効と見なすべきタイミングや、Google がデータを消したり信頼できる連絡先と共有したりするべきかどうかを、皆さんご自身で決めることができます。

動作の仕組み アカウント無効化管理ツールは、アカウント設定からアクセスできます。登録すると、3 つのことを尋ねられます。
  1. アカウントを無効と見なすべきタイミング : どのくらい未使用の期間が続いたら Google がアカウントの処理を行うかを、3 か月、6 か月、12 か月、18 か月から選択できます。Google は、指定された期間の 1 か月前に、スマートフォンへのメッセージと指定されたアドレスへのメールで通知します。
  2. 通知する対象者と共有する内容 : 皆さんの Google アカウントが無効になったときに、Google が通知する人を 10 人まで選択できます(セットアップ中には通知されません)。ここで指定した人が、データの一部にアクセスできるようにすることも可能です。信頼できる連絡先とデータを共有する場合、通知されるメールには、共有対象として選択したデータのリストと、そのデータをダウンロードできるリンクが含まれます。信頼できる連絡先と共有するデータには、写真、連絡先、メール、ドキュメントなどを含めることができます。さらに、Gmail の自動返信も設定可能です。件名とメッセージには、アカウントを使わなくなったことを説明する内容を自由に指定できます。
  3. 無効になった Google アカウントを削除するかどうか : アカウントが無効になると、Google はそのコンテンツをすべて削除するか、指定した連絡先に送信します。指定した人がコンテンツをダウンロードできるように設定している場合は、削除前の 3 か月間でダウンロードすることができます。Google アカウントを削除する場合、公開しているデータ(YouTube 動画や Blogger のブログなど)も削除されます。自分のアカウントに関連付けられているデータは、Google ダッシュボードで確認できます。アカウントで Gmail を使っている場合は、アカウントが無効になると、そのメールにアクセスできなくなります。Gmail のユーザー名を再利用することもできません。
アカウント無効化プランは簡単な手順で設定できます。これにより、データを保護し、アカウントが無効になっても安全な状態を保ち、皆さんがアカウントにアクセスできなくなったとしても、デジタル遺産は確実に信頼できる連絡先に渡ります。プライバシー診断でも、アカウントのプランの作成を促すようになりました。また、プランについてのリマインダーも、随時メールでお送りします。

Google は、皆さんのオンラインの安全を維持するため、たゆまぬ努力を続けています。セキュリティを強化するその他の方法については、安全性を保つためのヒント トップ 5 を確認するか、セーフティ センターにアクセスしてください。日々 Google がどのようにして皆さんのオンラインの安全を維持しているかについて知ることができます。