MicrosoftがEdgeブラウザをChromiumベースにすることを発表したが、これに対しFirefoxの開発を行なっているMozillaが公式ブログで「Goodbye、EdgeHTML」と題した記事を公開、Webブラウザの「Chromium独占」に対する危惧を示している（Qiitaに投稿された有志による訳）。

記事ではMicrosoftの決定について、「ビジネスの観点」では十分理解できるものだとしつつ、社会的な面では「基礎的なオンラインインフラストラクチャ」のコントロールをGoogleという1社に握られることは恐ろしいことだとしている。

また、Chromeと競合するFirefoxを開発するというMozillaの活動についてはビジネスのためではなく、「競争と選択」によってインターネットやオンラインの健全性を実現するためだと主張。そして、Chromiumのような単一の製品が大きなシェアを握ってしまった場合、2000年代前半の開発者がブラウザ互換性を考慮せず、特定のブラウザ以外では正しく動作しないサイトやサービスがリリースされるという問題が再び生み出されてしまう可能性があるとしている。

先日Microsoft、Chromiumベースのブラウザ「Anaheim」を開発中？という話題があったが、Microsoftが正式にEdgeブラウザをChromiumベースにすることを明らかにした（Windows Blogs、ITmedia）。

Microsoftによると、EdgeをChromiumベースにすることでより互換性が向上し、またWeb開発者はテストの手間を削減できるとしている。また、Windows 10以外のWindows向けにもリリースし、さらにリリースをより頻繁に行うことも計画しているという。macOSなどのWindows以外のプラットフォーム向けバージョンがリリースされる可能性もあるようだ。

この「ChromiumベースのEdge」はオープンソースで開発され、すでにGitHub上にリポジトリも作成されている。

Windows Centralが匿名の提供者からの情報として、MicrosoftがChromiumベースのWebブラウザを開発していることを伝えている。

将来的な名称やユーザーインターフェイスがどうなるかはまだ不明だが、このブラウザは「Anaheim」というコードネームで開発されており、Windows 10のEdgeを将来的に置き換えるものになるという。

また、最近MicrosoftのエンジニアがARM向けChromiumにコードをコミットしており、これはARM版WindowsでChromiumベースのブラウザを動かすための布石になっているのではないかとも推測されている。実際にいつこのブラウザが発表されるかは分からないが、2019年前半にリリースが予定されているWindows 10 version 1903（19H1）で何らかの発表があるのではないか、と記事の著者は推測している。

Google Chromeで「Tab Groups」(タブグループ)機能の開発が進められているらしい(9to5Googleの記事、 Chrome Storyの記事、 Android Policeの記事、 Chromium Gerrit 1343363 )。

Chromeのタブグループは、外見ではっきりと違いの分かるグループにタブを仕分けられるようにする、つまり異なるタスクに関連するタブを分離する、と説明されている。Internet Explorerにはタブグループ機能が搭載されており、Microsoft Edgeには開いているタブを保存しておき、後で復元できる機能が搭載されている。Chromeのタブグループ機能はどのようなものになるだろうか。

また、タブストリップをスクロール可能にする機能も開発が進められているそうだ。Chromeでは開いているタブの数が増加すると、最終的にタブストリップからはみ出してしまう。Ctrl+Tabなどではみ出したタブへの切り替えは可能だが、マウス/タッチスクリーンでの操作は困難だ。タブストリップをスクロール可能にすることで問題なく操作できるようになるほか、タブの幅が極端に狭くなる問題も解消するようだ。

Chrome 70ではプログラム終了のショートカットキー「Ctrl+Shift+Q」が廃止になっている(Softpediaの記事、 gHacksの記事)。

Chrome 69ではこのショートカットキーが使用できていたが、Chrome 70では「終了するには[Alt]+[F]+[x]キーを押してください」とToastが表示されるようになった。提示されるキーの組み合わせはChromeのメインメニューを開いて「終了(X)」を選択するのと同じ動作で、以前のバージョンから使用できていた。ただし、3つのキーを同時に押してもChromeは終了せず、「Alt+F」を押してキーを離してから「x」キーを押す必要がある。また、キオスクモードなどメインメニューの表示されない画面モードでは使用できない。

Ctrl+Shift+Qの動作は2013年にバグとして報告されていたものだ。長押しでChromeを終了させるという方法も提案されていたが、「Ctrl+Shift+Tab(タブの逆順切り替え)と押し間違えて入力中のデータを失い涙を流す」派の意見に押し切られ、このショートカットキーは廃止されてしまう。しかし、上述のように完全な置き換えにはならないこともあり、今度は「押し間違えることなどありえないし不便になった」派が反発。少なくとも「chrome:flags」で選択できるようにすべきだなどという意見が出ている。なお、Ctrl+Shift+W(すべてのタブを閉じる)は引き続き利用可能だ。

個人的には今回動作を確認するまでこのショートカットキーの存在を知らなかったが、タブを切り替えようとしてブラウザーが終了してしまったことはない。Firefoxでは最新版のFirefox 63でも利用可能だが、スラドの皆さんは利用しているだろうか。

headless曰く、

Android版Google ChromeでAndroid 4.1～4.3 Jelly Beanのサポート終了計画が進められているようだ（Android Police、XDA Developers）。

最近のコミットによると、サポートされていないバージョンのAndroid上ではChromeの設定画面やメニューに警告が表示されるように変更され、Jelly Beanはデフォルトでサポート外となっている。ただし、このコミットは「Work in Progress」となっており、具体的なJelly Beanのサポート終了時期については特に示されていない。

Android Developersサイトで公開されている9月分のデータ（9月28日までの7日間）によると、Jelly Beanのシェアは3.2%。昨年10月分（10月2日までの7日間）の6.6%から半減している。

追記 by headless: 10月13日のChrome Canary 72.0.3579.0で警告表示機能が追加された。その前のバージョンは71.0.3578.5なので、警告表示の開始はChrome 72以降になるようだ。

Googleは1日、Chrome拡張を信頼にあたるものにするためのパーミッション規定変更やChromeウェブストアのレビュープロセス変更などの計画を発表した(Chromium Blogの記事、 SlashGearの記事、 VentureBeatの記事、 Android Policeの記事)。

拡張機能がサイトデータの読み取りや変更を可能にするホストパーミッションはさまざまな機能を実現できる一方、開発者による悪用や誤用の原因となることもある。そのため、Chrome 70以降ではユーザーがサイト別のホストアクセス許可や、拡張機能をクリックしたときにのみホストアクセスを許可するといった設定が可能になる。

Chromeウェブストアのレビューでは強力なパーミッションを要求する拡張機能に対し、コンプライアンスに関するレビューを追加する。リモートでホストされるコードを利用する拡張機能に対しても厳格なチェックを行うという。

また、難読化コードを使用する拡張機能は1日から禁止されている。今後90日間は難読化コードを使用する拡張機能の更新を認めるが、来年1月初めまでに修正されない場合はChromeウェブストアから削除するとのこと。ただし、コードサイズ縮小を目的としたスペース削除などの処理は認められる。

このほか、来年には開発者アカウントでの二要素認証が義務化され、セキュリティやプライバシー、パフォーマンスの強化を目指したManifest v3も導入されるとのことだ。

Chrome Canaryで既定の検索エンジンを使用して検索を実行した際、OmniboxにURLを表示せず検索語句のみを表示する機能のテストが行われている(Android Policeの記事、 François Beaufort氏のGoogle+投稿、 Chromium Gerrit 1229493)。

つまり、Web検索を実行した場合にOmnibox(アドレス/検索ボックス)が検索専用ボックスのような動作になるというものだ。ただし、Omniboxに直接検索語句を入力した場合だけでなく、Webページ内の検索ボックスから検索した場合や、選択したテキストのコンテキストメニューから検索した場合にも検索語句のみがOmniboxに表示される。

前に検索した語句を編集して新しいタブで検索するといった場面では便利だが、それ以外の場面ではあまり意味がないようにもみえる。検索結果のURLをコピーすることもできない。なお、URLまたはURLのように見える語句(「cat.dog」「cat.dog/rat」など)を検索した場合、Omniboxには検索結果のURLが表示された。

この機能はデフォルトで無効になっており、利用するには「chrome://flags/#enable-query-in-omnibox」を「Enabled」に設定する必要がある。

GoogleのChromiumチームが「Google Credential Provider for Windows」という機能を開発しているようだ(BleepingComputerの記事、 Android Policeの記事、 BetaNewsの記事、 Chrome Storyの記事)。

Windows Vistaで導入されたCredential Providerは、Windows XPまでのGINAに代わってログオンなどのユーザー認証を実行する仕組み。Windows 10ではローカルアカウントやMicrosoftアカウントのほか、Windows Helloなどによる認証を可能にするCredential Providerが追加されている。OEMや企業が独自のCredential Providerを追加することも可能だ。

Google Credential ProviderについてGoogle側からの情報はほとんどないようだが、BleepingComputerではChromium Gerritにコミットされたコードから、G Suite管理者が作成したGoogle Accounts and ID Administration(GAIA) IDでWindows 10へのログインを可能にするものだと推測する。

Android版のGoogle Chromeで、低速接続時にJavaScript を無効化する「NoScript」フラグがデフォルトで有効になるそうだ(Chromium - Issue 876778、 XDA-Developersの記事、 Android Policeの記事)。

この機能はNetwork Information APIを使い、ネットワーク通信速度が2G並み、またはそれ以下の場合にJavaScriptを無効にするというものだ。昨年10月からプレビュー版として搭載されており、「chrome://flags/#enable-noscript-previews」を設定することで有効化できる。日本では2G回線を利用できないが、判定は実際の通信速度によって行われるため、より高速な回線でも速度が著しく低下した場合は動作するとみられる。

Googleが9月4日に安定版をリリース予定のChrome 69では、Flashサポートの廃止が一歩進められるようだ(Google Chrome Enterpriseヘルプ、 Ars Technicaの記事)。

Googleでは2016年から「HTML5 by Default」として、Flashサポートを段階的に廃止してきた。現在はWebサイトごとにユーザーが許可することでFlashを利用できるようになり、設定はChromeの再起動後も保持される。しかし、Chrome 69では再起動するたびに許可が必要になるという。ただし、DefaultPluginsSettingやPluginsAllowedForUrls、PluginsBlockedForUrlsといったエンタープライズ向けポリシー設定は引き続き利用可能とのこと。

Adobeは昨年、Flashの更新と配布を2020年末で終了する計画を発表している。ChromeのFlash Roadmapによれば、2019年7月のChrome 76以降でFlashがデフォルト無効になり、2020年12月のChrome 87以降でFlashサポートが削除されるとのことだ。

Chrome Canaryで画像の遅延読み込み機能が利用可能になっている(Bleeping Computerの記事、 Android Policeの記事、 Neowinの記事)。

Google Chromeの遅延読み込み(LazyLoad)機能実装計画は1月に発表されたもので、画面に表示されない部分の画像や特定のサードパーティiframeについて、ページをスクロールして表示範囲に近づくまで読み込みを延期する。長いページの一番下に配置された画像など、ユーザーがほとんど見ることのない要素の読み込みを行わないことで、データ使用量やメモリー使用量を削減し、読み込み速度を向上させることが目的だ。

iframeの遅延読み込み(LazyFrames)はChrome 68で既に実装されており、「chrome://flags/#enable-lazy-frame-loading」を設定することで有効化できる。Bleeping Computerによれば、Chrome Canaryでは70.0.3521.0から画像の遅延読み込み(LazyImages)が実装されたという。こちらは「chrome://flags/#enable-lazy-image-loading」を設定することで有効化できる。手元の環境で試してみたところ、デフォルトの「Default」では有効になっておらず、「Enabled」を選択すると有効になることが確認できた。なお、読み込みの延期された要素がある場合、印刷時などにプレースホルダーのまま出力されるといった問題もあるようだ。

また、HTML属性「lazyload」を指定することで、Webページ側が個別に遅延読み込みの有効・無効を設定することもできるとのことだ。

デスクトップ版のChrome 67ではSpectre/Meltdownなどの脆弱性を狙う投機的実行のサイドチャネル攻撃を緩和するため、すべてのサイトを別プロセスで読み込む「Site Isolation」が有効になっているそうだ(Google Security Blogの記事、 Ars Technicaの記事、 The Registerの記事、 BetaNewsの記事)。

Chromeでは以前からタブごとに別のプロセスを使用しているが、タブ内のiframeやポップアップで別のサイトが読み込まれる場合はメインタブと同一プロセスが使われていたという。通常は同一オリジンポリシーによりクロスサイトiframeやポップアップの内容にメインドキュメントからアクセスすることはできないが、何らかの脆弱性を狙われた場合にはSpectreに限らず、Site Isolationが有効な緩和策となる。また、Webページがサブリソースとして読み込もうとするクロスサイトのHTML/XML/JSONレスポンスをブロックするCross-Origin Read Blocking(CORB)も含まれる。なお、同一ドメインのサブドメインについては同一サイト扱いになるとのこと。

Site IsolationはChrome 63 で実験的な企業向けのポリシーとして実装されており、多くの問題が解決されたことから、デスクトップ版Chromeの全ユーザーで有効にできるレベルに達したという。ただし、現時点で有効になっているのは99%のユーザーで、1%はパフォーマンス改善などのため無効のままにしているそうだ。プロセス増加により、メモリー使用量は10～13%程度の増加が見込まれる。

Site Isolationの動作はhttp://csreis.github.io/tests/cross-site-iframe.htmlを開いて「Go cross-site (complex page)」をクリックし、Chromeのメニューから「その他のツール→タスクマネージャ」を選んでタスクマネージャを起動すれば確かめられる。有効になっていればiframeに読み込まれたサイトが「サブフレーム」として表示されるはずだ。

セキュリティソフトを導入しているとFirefoxからGoogleのサービスへのアクセスができなくなる、といった問題が報告されている（ghacks.net）。

問題となっているのはAvastおよびAVGのセキュリティソフト。これらのセキュリティソフトを導入した環境でFirefoxでTLS 1.3を利用しようとすると問題が発生するようだ（MozillaのBugzilla、Avastのフォーラム）。

また、ChromeでもAvastを利用している環境でTLS 1.3接続関連のトラブルが発生することがあるようだ（The Chromium Projectsでの報告）。

Googleは12日、Chrome拡張のインラインインストール機能を廃止する計画を発表した(Chromium Blogの記事、 Neowinの記事、 The Vergeの記事、 Softpediaの記事)。

インラインインストールを利用すると、Chromeウェブストアでホストされている拡張機能を作者のWebサイトなどから直接インストール可能になる。以前は任意のWebサイトでホストする拡張機能をインストールできていたが、不正な拡張機能が問題になったことから Googleはインラインインストールへの移行を推奨。2014年5月にはChromeウェブストア以外でホストされる拡張機能のブロックを開始していた。

さらに2015年にはユーザーをだますような説明で誘導する拡張機能のインラインインストールを無効化しているが、その後も同様の手法が後を絶たなかったようだ。Googleでは望まない拡張機能に関する大量の苦情を受けており、大半を不正なインラインインストールが占めているという。一方、Chromeウェブストアからインストールされた拡張機能は苦情が大幅に少ないとのこと。

インラインインストール廃止は3段階で進められる。まず、6月12日以降に新規公開された拡張機能では既にインラインインストールが無効化されており、chrome.webstore.install()メソッドを呼び出そうとすると自動でChromeウェブストアにリダイレクトされるようになっている。9月12日以降は既存の拡張機能でもインラインインストールが無効となり、Chromeウェブストアへのリダイレクトが行われる。12月初めに安定版リリース予定のChrome 71では、インラインインストール用のAPIメソッドが削除されるとのことだ。

インラインインストールを利用している拡張機能開発者に対しては、Chrome 71安定版リリースより前にWebサイトのインストールボタンをChromeウェブストアへのリンクに変更するよう求めている。