Microsoftは14日、Microsoft EdgeでChrome拡張機能プラットフォームのManifest V3がテスト可能になったことを発表した(Microsoft Edge Blogの記事、 Microsoft Docs、 Ghacksの記事)。

拡張機能のセキュリティやプライバシー、パフォーマンスの向上を目指すManifest V3だが、コンテンツブロッキング用途でのwebRequest API使用が非推奨となり、新たに追加されるdeclarativeNetRequest(DNR) APIへの置き換えが必要となることや、ブロッキングルールの数の制限などが批判の対象となった。ただし、ブロッキングルールの上限については当初の3万件から15万件に引き上げられ、現在広く使われているEasyListのルール(7万件+)全体が使用できないという問題は解消されている。

MicrosoftではManifest V3で拡張機能の機能が大幅に損なわれることはないと考えており、Webの断片化を減らすためにDNR APIを含むManifest V3における変更をサポートすることにしたという。コンテンツブロック拡張機能に関して懸念されていた問題もすでに解決しているか、webRequest APIが非推奨化される前に解決できると考えているそうだ。現時点では一部の変更をテスト可能にしただけのようで、ChromiumでManifest V3がファイナライズされてから今後のタイムラインを発表するとのこと。

Microsoft Docsによれば、現在テスト可能な新機能は安定版のMicrosoft Edge 84でDNR API、ベータ版のMicrosoft Edge 85でヘッダー変更のサポートとなっている(最新のMicrosoft Edgeは安定版もベータ版もバージョン86)。また、リストには含まれていないが、Canary版でサービスワーカーのサポートがテスト可能になっているとのことだ。

headless 曰く、

Chrome Canaryでタブストリップのスクロール機能が利用可能になっている(Ghacksの記事)。

タブストリップのスクロール機能はタブの数が増えてもタブ幅を一定幅よりも小さくならないようにし、はみ出した部分をマウスホイールでスクロール表示できるようにする機能だ。この機能を利用するにはChrome Canary 88.0.4284.0以降(88.0.4285.0で確認)でchrme://flagsの「Scrollable Tabstrip (chrome://flags/#scrollable-tabstrip)」を「Enabled」にしてChromeを再起動すればいい。

この機能は2018年から開発が進められており、フラグ自体は安定版のChromeにも実装されているが、タブが一定幅よりも小さくならないようになるだけでスクロールはできなかった(Macでは少し前からスクロールできるようになっていたようだが未確認)。また、タブストリップの隣に左右のスクロールボタンを配置してスクロールできるようにする機能の実装も進められているようだ。

Googleは2日、Android OEM特有のセキュリティ問題に対応する「Android Partner Vulnerability Initiative (APVI)」の開始を発表した(Android Developers Blogの記事、 9to5Googleの記事、 Monorail - apvi)。

GoogleはAndroid OSやAndroidアプリに関する脆弱性報告報奨金プログラムを行っており、報告されたAndroid Open Source Project (AOSP)ベースのコードに関する問題はAndroidのセキュリティに関する公開情報(ASB)を通じて開示している。一方、個別のAndroid OEMによるAOSP外のコードで見つかった問題に対処する明確な手段は最近まで用意されていなかった。

APVIはそのギャップを埋めるものであり、Googleが発見した問題の修正をOEMパートナーに促し、ユーザーに透明性を提供するものだという。APVIの取り組みは1年以上前から進められていたようで、既に8件の問題が修正されている。

headless 曰く、

iOS版Chrome 85では、デスクトップ版サイトをリクエストした場合のUser Agent文字列がChrome 84までとは異なるものになっているそうだ(Chromium Blogの記事、 開発者向け情報)。

iOS版Chromeでユーザーがデスクトップ版サイトをリクエストした場合、Chrome 84まではデスクトップ版Safariと同じUser Agent文字列が送信されていた。Chrome 85以降でもデスクトップ版SafariのUser Agent文字列がベースとなっているが、「Version/<バージョン>」の手前に「CriOS/<メジャーバージョン>」が追加されているという。

iOS版Chromeのデフォルト(モバイル版サイト表示)ではモバイル版SafariのUser Agent文字列の「Version/<バージョン>」を「CriOS/<Chromeリビジョン>」に置き換えたものが送信されている。今回の変更により、モバイル版とデスクトップ版でUser Agent文字列がこれまでよりも揃った形式になる。

User Agent文字列変更の目的としては、iOS上のChromeとSafariの違いを考慮したユーザーエクスペリエンスを開発者が提供できるようにすることだという。しかし、Googleはフィンガープリンティングで使われないよう、ChromeのUser Agent文字列に含まれる情報量を減らす計画を進めている。今回の変更は情報量を増やすことになるが、計画から大きく外れるものではないとのこと。なお、この計画はCOVID-19の影響で2021年以降に先送りされている。

Googleは2日、Chrome 85でSecure DNSをAndroid版Chromeでも利用可能にする計画を示した(Chromium Blogの記事、 Ghacksの記事、 Android Policeの記事)。

Secure DNSはDNS-over-HTTPS(DoH)プロトコルを利用するもので、デスクトップ版ではChrome 83から順次導入されている。Android版でも同様に順次導入されていき、デフォルトでは現在使用しているDNSプロバイダーがDoHをサポートしていれば自動で切り替えられる。自動モードの場合は状況に応じて通常のDNSにフォールバックし、定期的にDoHでの接続を試みるという。フォールバックなしでSecure DNSを使用するには、DNSプロバイダーをマニュアル設定するオプションを選択すればいい。Secure DNS自体をオフにすることも可能だ。

VerisignのCSO Applied Research部門の主任エンジニアであるMatthew Thomas氏は、APNICのブログで、DNSルートサーバーのトラフィックの半数は、Chromium系ブラウザから出ている大量のクエリが原因であると指摘する（APNIC、ZDNet）。

Chromiumには初期の頃から、ユーザーがウェブサイト名、URL、または検索語を入力できるアドレスバーの機能が存在していた。しかしアドレスバーには、入力された単語を検索語として扱うのか、URLとして扱うのかといったインターフェースとして問題があるという。通常は「marketing」と打ち込めば検索語として扱われる。しかし「もしかして http:// marketing」というようにURLではないかとして判断する挙動を見せるときも多い。

この原因はChromiumがネットワークを信頼しているかどうかにあるという。DNSサーバーが傍受されないDNS応答を返さない場合、すべての検索語で「もしかして」という情報バーが表示されてしまうこともある。Chromiumベースのブラウザは、7〜15文字からなる3つのドメイン名をランダムに呼び出してテストし、2つのドメインの応答が同じIPを返した場合のみブラウザは、ネットワークが存在しないドメイン要求をキャプチャして、リダイレクトを行っていると考えられるという。

同氏の調査では、2020年5月13日の総トラフィックの45.80％は、Chromiumプローブからのトラフィックであるように見えるとしている。ルートサーバーのDNSトラフィックの半分が単一のブラウザをサポートするためだけに使用されているのではないかと指摘している。

国内のほとんどの銀行のネットパンキングでは、IBM製のセキュリティソフトである「IBM Security Trusteer Rapport（以下Rapport）」のインストールが推奨されている。PCでネットバンキングを使っている人なら、何度かインストールを求められたことがあるだろう（IBMリリース、豊川信用金庫[PDF]、多摩信用金庫）。

しかし、このRapportは旧来のMicrosoft Edgeまでしか対応しておらず、現行のChromium版 Microsoft Edgeはサポート対象外。このため各銀行や信用金庫などでは現在、対応しているGoogle ChromeやFirefox、もしくはInternet Explorerの使用を推奨するよう各サイトで通知している。この通知によれば、Chromium版 Microsoft EdgeにRapportが対応するのは、2021年1月〜3月頃になるという。

headless 曰く、

Microsoftは17日、レガシーMicrosoft Edgeのサポートを来年3月で終了する計画を明らかにした(Micosoft Tech Communityの記事、 Neowinの記事、 On MSFTの記事)。

Microsoftでは、1月にChromiumベースの新Microsoft Edgeをリリースし、大半のWindows 10ユーザーを新Microsoft Edgeに移行させたため、レガシーEdgeのサポートを終了すると説明している。Microsoftによれば、既に数百万人(!)のユーザーが自宅と職場のブラウザーを新Microsoft Edgeにアップグレードしており、新しいデバイスと今後の機能アップデート(Windows 10 20H2以降)では新Microsoft Edgeが含まれるようになるという。レガシーEdgeは開発終了がアナウンスされているが、2021年3月9日の月例更新を最後にセキュリティアップデートも提供されなくなる。

また、Microsoft 365におけるInternet Explorer 11(IE11)サポート終了計画も同時に発表されている。まず、2020年11月30日以降はMicrosoft TeamsのWebアプリがIE11をサポートしなくなり、2021年8月17日以降はMicrosoft 365アプリとサービスがIE11をサポートしなくなる。サポートが終了しても完全に使用できなくなるわけではないようだが、IE11では一部の機能が使用できなくなる。なお、レガシーEdgeとは異なり、現在もIE11専用のWebアプリを使用している企業などがあることから、(当面は)IE11がなくなることはないという。新Microsoft EdgeではIEモードが使用できるため、アプリごとにブラウザーを切り替える必要もないとのことだ。

Googleは12日、デスクトップ版Chrome 86(Dev/Canary)で一部のユーザーを対象に、Omnibox(アドレス・検索ボックス)のURL表示をドメイン部分のみにするテストを実施していることを発表した(Chromium Blogの記事、 Ghacksの記事、 Neowinの記事、 SlashGearの記事)。

URLに細工してユーザーを混乱させる攻撃手法は無数にあり、Googleとイリノイ大学アーバナシャンペーン校の共同研究によると、ブランド名を含むURLパスを見たユーザーの60%以上がだまされるという結果が出ている。ドメイン部分のみの表示はこういった攻撃への対策の一つで、現実の使用でユーザーを悪意あるWebサイトへのアクセスに気付かせ、保護できるかどうかを確認するのが目的だという。

テスト対象になったユーザーの環境ではデフォルトでURL表示がドメイン部分のみになり、OmniboxをポイントしたときにのみフルURLが表示されるようになる。常にフルURLを表示するには、Omniboxのコンテキストメニューで「URL全体を常に表示」を選べばいい。

テスト対象になっていないユーザーは「chrome://flags」で「#omnibox-ui-sometimes-elide-to-registrable-domain」および「#omnibox-ui-reveal-steady-state-url-path-query-and-ref-on-hover」の両方をEnabledにすれば試すことができる。また、「#omnibox-ui-hide-steady-state-url-path-query-and-ref-on-interaction」をEnabledにすると、ページ内で何らかの操作をするまではフルURLが表示されるようになる。これらのフラグはChromium 86ベースのMicrosoft Edge Dev/Canaryにも用意されている。

ドメイン名のみの表示にするフラグは6月にChrome 85 Dev/Canaryで見つかり、話題となっていた。ただし、当時は上述の最初のフラグがなく、代わりに「chrome://flags/#omnibox-ui-hide-steady-state-url-path-query-and-ref」というフラグが用意されていた。なお、現在BetaチャンネルではChrome 85が提供されているが、対応するフラグは後の2つのみとなっている。

Android版Chromeをしばらく使用していないユーザーに対し、通知を表示してChromeの使用を推奨する計画が進められているようだ(9to5Googleの記事、 Neowinの記事、 The Next Webの記事)。

9to5Googleが発見したコミットによると、他のアプリ内にChromeのタブを表示するCCT(Chrome Custom Tabs)が実行されたタイミングで使用状況をチェックし、Chromeをしばらく使用していないと判定した場合に3種の通知の一つを表示するという。通知の内容は主にChromeの使用でデータ使用量を削減できるといったものだ(android_chrome_strings.grd)。既にAndroid版Chrome Canaryには「Enable re-engagement notifications (chrome://flags#reengagement-notification)」というフラグが追加されている。

Google Chromeのバージョン85で実装予定だったメモリ使用量の削減が延期になったそうだ。この機能は6月17日に発表されていたもので、Windows 10 May 2020 Updateで実装された「セグメントヒープ」を活用して、Chromeのメモリ使用量を減らす計画だった（PCWatch、マイナビ）。

セグメントヒープは効率よくメモリを管理する機能。すでにChromiumをベースのMicrosoft Edgeでは、このセグメントヒープを利用して最大27％ほどメモリ使用量を減らすことに成功している。このためGoogle Chromeにも簡単に応用できるとみられていた。

しかし、Google Chromeでは、CPUの負荷の増加による消費電力のアップやベンチマーク性能が低下することが判明したため、バージョン85でのセグメントヒープ活用によるメモリ使用量削減についてはとりあえず延期されることになった模様。

あるAnonymous Coward 曰く、

Chromeへのセグメントヒープの導入が延期された模様。タレコミ子的には、逆にChromium Edgeはどうやって導入しているのか気になります…。(単純に、Edge側はCPU負荷よりメモリ使用量削減を優先しているとかだったり…？)

headless 曰く、

先日リリースされたFirefox 78のデスクトップ版では、タブのコンテキストメニューの「右側のタブをすべて閉じる」「他のタブをすべて閉じる」がサブメニュー「複数のタブを閉じる」にまとめられた(Firefox Helpの記事)。

Mozillaによれば、誤って複数のタブを閉じてしまうことを避けるためにサブメニューへ移動したのだという。また、ユーザーから要望の出ている「左側のタブをすべて閉じる」を追加する場所ができるとも述べている。しかし、サブメニューに移動したことで項目を選択する前に「複数のタブを閉じる」をポイントする必要があり、操作が1アクション増えることになる。個人的には「右側のタブをすべて閉じる」をよく使うため、少しイライラしている。

Google Chromeでは2017年に「他のタブをすべて閉じる」「右側のタブを閉じる」の削除が検討され、2019年11月リリースのChrome 78では実際に「他のタブをすべて閉じる」が削除されたものの、その後のアップデートで復活している。

2017年のスラド記事では「右側のタブを閉じる」をよく使うという意見が多くみられたが、今回再び質問したい。スラドの皆さんはWebブラウザーで複数のタブを閉じる機能を使っているだろうか。右側のタブと他のタブ、どちらをまとめて閉じることが多いか、左側のタブを閉じる機能が必要かどうかなどについてもコメントしてほしい。

Appleがプライバシー保護に問題があるとして、Safariへ一部のWeb APIを実装することを拒否しているという。拒否しているのは次のとおり（GIGAZINE、ZDNet）。

・Web Bluetooth
・Web MIDI API
・Magnetometer API
・Web NFC
・Navigator API: deviceMemory
・NetworkInformation API
・Battery Status API
・Web Bluetooth Scanning
・AmbientLightSensor API
・EME Extension: HDCP Policy Check
・Proximity API
・WebHID API
・Serial API
・WebUSB
・Idle Detection

AppleはこれらのAPIによって、オンライン広告主とデータ分析会社がユーザーや端末を識別して行動をトレースできるようになると主張している。すでにSafariに実装されているAPIに関しても、独自に対策を取ってあるとしている。

なおこれらのAPIのほとんどは、Chromiumベースのブラウザーでのみ実装され、Mozillaのプラットフォームではほとんど実装されていないとのこと。

headless 曰く、

Twitterは22日、twitter.comでInternet Explorer 11 (IE11)をサポートしなくなったと発表した。(リリースノート、 Neowinの記事)。

以前からIE11はtwitter.comがサポートするブラウザーのリストに含まれていないが、これまでは利用可能だった。現在、IE11でtwitter.comにアクセスすると、「このブラウザは現在サポートされていません」とメッセージが表示される。Chromium系のブラウザーでユーザーエージェントをIE11にした場合はメッセージを閉じることも可能だが、本物のIE11ではメッセージを閉じることができず、Twitterを利用できない。mobile.twitter.comは現在のところIE11でも利用可能だ。

なお窓の杜によれば、6月2日の朝には「このブラウザは現在サポートされていません」という表示が出ていた模様（窓の杜）。

あるAnonymous Coward曰く、

MicrosoftがEdgeブラウザをChromeベースに変更したことで、Googleの「Chromebook」のようなハードウェアをMicrosoftもリリースできるようになるのではないか、という話がある。Microsoft EdgeはChromiumレンダリングエンジンを採用、これによりChromeとほぼ完全に互換性を得ることになり、Chromeアプリストアから拡張機能をインストール可能になった。さらにLinuxもサポート可能になっている（ZDNet、Slashdot）。

さらに、Edgeの「コアWebエクスペリエンス」はChromeに非常によく似ているが、Chromeとは異なるいくつかの差別化機能を備えている。その1つとして、Chromeよりもプライバシーに重点を置くことができる点がある。

とはいえ、同社がその気になってChromebookを後追いしたとしても、WindowsノートPCとの差別化には苦しむことになるとは思われる。たとえばWindowsアプリをサポートすれば、Chromebookとの差別化は容易に出来るだろう。しかし、Windowsアプリのサポートが優れているほど、Edgebookと既存のWindowsノートブックとの差別化は困難になるとしている。