iOS版Chrome 85、デスクトップ版サイトをリクエストした場合のUser Agent文字列が変更される

2020年9月16日 17:00

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年以降に先送りされている。

Chrome 85、AndroidでもSecure DNSが順次利用可能に

スラド

著者: headless

2020年9月5日 17:18

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自体をオフにすることも可能だ。

DNSルートサーバへのアクセスのうち、45.80%はChromiumの検索仕様による無駄な通信だった

スラド

著者: nagazou

2020年8月27日 06:00

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トラフィックの半分が単一のブラウザをサポートするためだけに使用されているのではないかと指摘している。

Chrome 86 Dev/Canary、アドレスボックスにドメイン名のみを表示するテストを実施

スラド

著者: headless

2020年8月15日 11:39

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つのみとなっている。

すべて読む | ITセクション | Chrome | セキュリティ |

Android版Chrome、しばらく使用していないユーザーへの通知表示を計画

スラド

著者: headless

2020年8月8日 11:39

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)」というフラグが追加されている。

“Chrome ウェブストア”の不明瞭な審査に不満の声

スラド

著者: nagazou

2020年8月4日 18:00

Chromeウェブストアといったアプリストアの審査ポリシー体制に違反したと通告された場合、再承認を受けるには非常に多くの時間と手探りでの修正が必要だ。Notaは7月29日、スクリーンショット共有ツール「Gyazo」を再公開したが、再公開が可能になるまでには約2か月を要したという（窓の杜）。

同ツールは5月7日にポリシー違反があると通知を受けた。14日間以内に問題を解決しない場合、ストアから拡張機能が削除される。同様のトラブルとしてPushBulletの事例があったことから、同社はそれを参考にコード変更や権限を削除する修正を行ったものの、Googleからは再承認を受けられず、時間切れになって拡張ツールは削除された。

Chromeウェブストアチームにも問い合わせたが、具体的な違反箇所や内容は教えてもらえなかったという。手探りで修正を行った結果、結局問題となっていた部分は「Gyazo」のURLをMarkdown形式に変換する処理が、Single Purposeポリシーに違反していたと判断されていたようだ。同社は当初、この機能をデフォルトで無効化したが承認は得られなかった。しかし、削除した場合は審査を通過したとのこと。

すべて読む | ITセクション | Chrome | IT |

GIGAスクール構想における教育向けPC市場、Chromebook採用が増える見込み

スラド

著者: nagazou

2020年8月4日 16:00

小中学校のすべての生徒にPCを与えるという政府の「GIGAスクール構想」が、新型コロナウイルスの影響により、予定より前倒しになったそうだ。日経によれば、これによりPCのOSシェアが大きく変動する可能性が出てきているという。GIGAスクールではWindows以外にもChromebookとiPadも選択可能とのこと（日経クロスネット）。

日経の取材やMM総研の調査などでは、ChromebookがWindowsに迫る支持があるという。MM総研によれば、Chromebookはおよそ3分の1、iPadも2割前後のシェアを取る可能性があるとしている。横浜市は小学校向けの約19万台はiPadを、中学校向けの約8万台はChromebookを採用する採用する方針だという。

横浜市のリリースによれば、iPadは直感的に使いやすい、カメラ機能が充実していること、市内での実績が豊富などが採用理由に挙げられている。Chromebookに関しては、起動が速いことやクラウドサービスとの親和性が高い点、複数のWeb情報を表示させることができる、教育現場では「Google Classroom」が採用しているところが多い点が理由であるようだ（横浜市[PDf]）。

すべて読む | ITセクション | Chrome | IT |

Android版Chrome Canary、ダウンロードのスケジュール機能をテスト中

スラド

著者: headless

2020年7月23日 13:32

Android版のChrome Canaryで、ダウンロードをいつ実行するか設定する機能のテストが行われている(Techdowsの記事、 Neowinの記事、 Ghacksの記事、 9to5Googleの記事)。

この機能を使用するには、chrome://flagsで「Enable download later」(chrome://flags/#download-later)をEnabledに設定すればいい。アプリの再起動後、ファイルをダウンロードしようとすると「ダウンロード日時の選択」ダイアログボックスが表示されるようになる。また、ダウンロードのオプションに「ファイルをいつ保存するか確認する」が追加され、「ダウンロード日時の選択」を使用するかどうかの設定が可能になる。

ダウンロード時に選択可能なオプションとしては、開始日時を指定する「日付と時間を選択」のほか、Wi-Fi接続に切り替わったタイミングでダウンロードを開始する「Wi-Fi接続時」や通常通りダウンロードを実行する「たった今」が選択可能だ。ただし、スケジュールの指定を完了すると保存先に.crdownloadファイルが作成され、ダウンロードするファイルサイズが小さい場合はこの時点でダウンロードが完了してしまうようだ。また、現時点では指定通りにダウンロードが始まらないことも多いようで、何度か試してみた限り「日付と時間を選択」で指定した通りにダウンロードが開始されることはなかった。

なお、このダイアログはモバイルデータ接続時にのみ表示されるが、chrome://flagsの「Show download later dialog on WIFI」(chrome://flags/#download-later-debug-on-wifi)をEnableにすることで、Wi-Fi接続時にも表示されるようになる。

Webブラウザーで複数のタブを閉じる機能、使ってる？

スラド

著者: nagazou

2020年7月7日 19:03

headless 曰く、

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

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

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

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

「Microsoft版のChromebook」は実現するのか

スラド

著者: hylom

2020年6月26日 08:00

ある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ノートブックとの差別化は困難になるとしている。

Chrome 85ではURLバーのドメイン名以外がすべてデフォルトで非表示になる可能性がある

スラド

著者: hylom

2020年6月17日 12:55

Google ChromeではURLの表示方法についてさまざまな試みを行なっているが、9月にリリース予定のChrome 85ではURLバー内でドメイン名以外の表示が行われなくなる可能性があるという（INTERNET Warch、Android Police、Anroid Policeの続報）。

Android Policeの記事にはドメイン以外が表示されなくなった状態のChromeの挙動を紹介するサンプル動画も用意されている。また、この挙動はオプションで変更できるようになるようだ。

すべて読む | ITセクション | Chrome | インターネット |

64ビットWindows版のChromium系ブラウザー、ついに64ビットプログラム標準の場所へインストールされるようになる見込み

スラド

著者: hylom

2020年6月16日 15:32

headless曰く、

64ビットWindows版のGoogle Chromeは長年にわたって32ビットプログラム標準の場所にインストールされていたが、ついに変わるようだ（Ghacks、Softpedia）。

64ビットWindows版のGoogle Chromeはリリースされた2014年以来、64ビットプログラム用の「C:\Program Files」ではなく、（ユーザー別フォルダーにインストールされる場合を除き）32ビットプログラム用の「C:\Program Files（x86）」以下にインストールされていた。Microsoft Edgeを含むChromium系ブラウザーも同様に「C:\Program Files（x86）」以下にインストールされる。

この問題についてChromiumチームでは2014年当時上げられたバグ報告に対し、「現時点では意図的なものであり、将来的には移動する」と説明していた。その後も同じ問題に関するバグ報告がたびたび上げられるものの放置されていたが、5月になって修正に着手。6月6日のコミットはWindows 7の「mini_installer_tests」が失敗するとして取り消されたが、6月10日には修正版がコミットされている。

この変更が提供される時期やバージョンは不明だが、いずれは64ビット版のChromium系ブラウザーすべてが「C:\Program Files」以下にインストールされるようになるとみられる。ただし、既存のインストールフォルダーが変更されることはなく、「C:\Program Files」以下に移動したい場合はいったんアンインストールしてからインストールしなおす必要があるとのことだ。

延期されていたTLS 1.0/1.1のデフォルト無効化、6月から順次実施

スラド

著者: hylom

2020年6月15日 14:10

新型コロナウイルス感染拡大の影響で延期されていたTLSバージョン1.0および1.1（TLS 1.0/1.1）の無効化がついに行われるようだ。Firefoxでは、6月30日公開のFirefox 78でデフォルトでTLS 1.0/1.1の無効化が行われる（MozillaのBugzila、 Firefoxサイト互換性情報）。

HTTPSなどの暗号化通信で使われるTLSのバージョン1.0および1.1では脆弱性が発見されており安全ではないとして、2020年中に主要WebブラウザではTLS 1.0/1.1のサポートが廃止される方針だった

Firefoxだけでなく、Google Chromeの次期バージョンであるChrome 84でもTLS 1.0/1.1のサポートが削除される予定（窓の杜）。

Google ChromeのSameSite cookie強制、7月に再開へ

スラド

著者: headless

2020年5月31日 18:16

Googleは5月28日、Google ChromeにおけるSameSite cookie強制を7月に再開する計画を明らかにした(Chromium Blogの記事、 The Vergeの記事、 SlashGearの記事)。

SameSite cookieは「SameSite」属性で他サイトに対するcookie送信を制御することでセキュリティを強化する仕組み。Google Chromeでは2月リリースのChrome 80でSameSite cookie強制を段階的にロールアウトしていたが、サービス側が対応することによる問題発生も報告されていた。その後、COVID-19パンデミックが世界的に困難な状況を生む中、Googleは必要なサービス提供が中断されないようにするためとして、4月に一時的なロールバックを実施している。

4月以降、GoogleはWebサイトやサービスの対応状況を見守っており、SameSite cookie強制を再開しても問題ないと判断したようだ。再開日はChrome 84がリリースされる7月14日に設定されており、Chrome 80以降で前回と同様に段階的なロールアウトを行う。具体的なタイミング等については引き続きSameSite Updatesページで告知するとのことだ。

Chromiumプロジェクト、重大度の高いセキュリティバグの約70％がメモリに由来すると発表

スラド

著者: hylom

2020年5月28日 14:28

Anonymous Coward曰く、

Chromiumプロジェクトは今週、重大度の高いセキュリティバグの約70％は、メモリの安全性に関する問題（ポインタの誤り）に由来すると発表した。これはGoogleのエンジニアが2015年以降の912の重大度の高い、もしくは重大なセキュリティバグを分析した結果から導き出させたものだという。これはユーザーのセキュリティを危険にさらすだけでなく、Chromeの修正と出荷においてコストを増大させているとしている。

同様の問題はMicrosoftも指摘している。2019年2月のセキュリティ会議で講演したMicrosoftのエンジニアは過去12年間、Microsoft製品のすべてのセキュリティアップデートの約70％がメモリの安全性が原因だったと指摘している。端的に言えば、コードベースで2つの主要なプログラミング言語であるCとC++は「安全でない」言語であるということになる。

Googleによると2019年3月以降、重大度の高いChrome脆弱性130個のうち、125はメモリ破損に関連する問題だった。他のバグクラスの修正が進んだにもかかわらず、メモリ管理が依然として問題であるとしている。Mozillaは、CおよびC++の修正をするのをあきらめ、FirefoxでRustプログラミング言語を後援、促進、大幅に採用することで大きな進歩を遂げた。MicrosoftもCおよびC++の代替に多大な投資をしている。

今週、Googleも同様の計画を発表した。今後、Googleは、メモリ関連のバグに対する保護を強化したライブラリであるカスタムC++ライブラリの開発を検討する予定であると述べている。またGoogleは可能な限り「安全な」言語の使用を検討する計画があるとも述べている。候補には、Rust、Swift、JavaScript、Kotlin、およびJavaが含まれているようだ（The Chromium Projects、Slashdot）。

国税庁のe-Taxサイト、Google ChromeとChromium版Microsoft Edgeの対応を開始

スラド

著者: hylom

2020年5月27日 13:08

国税庁の電子申告・納税システムe-Taxでは32ビット版Windows 8.1もしくは10とInternet Explorer 11もしくは旧Edgeが推奨環境となっていたが、5月25日より「受付システム」と「e-Taxの開始（変更等）届出書作成・提出コーナー」がGoogle Chromeに対応した（同サイト上での発表）。それ以外のソフト・コーナーについても来年1月よりChromeに対応する予定だという。

利用には専用のChrome拡張機能のインストールが必要。これに合わせて、Chromeと拡張の互換性があるChromeベースの新Edgeでも同様にこれらのソフト・コーナーが利用できるという。

Google、Chromeウェブストアでのスパム対策を強化

スラド

著者: headless

2020年5月4日 11:35

Googleは4月29日、Chromeウェブストアでのスパム対策を強化するための開発者プログラムポリシー改訂を発表した(Chromium Blogの記事、 9to5Googleの記事、 The Vergeの記事、 SlashGearの記事)。

Chromeウェブストアは最大のブラウザー拡張機能カタログとなる一方、低品質な拡張機能やユーザーを誤解させるような内容の拡張機能を公開して利益を得ようとする開発者も増加しているという。

以前からChromeウェブストアの開発者プログラムポリシーでは同じ内容のコンテンツを複数公開することや、キーワードスパム、レーティング操作などを禁じている。ただし、改訂前(Internet Archive)は「～しないように (Do not ～)」のような表現だったが、改定後は「～を認めない (We don't allow ～)」「開発者は～してはいけない(Developers must not ～)」のように変更されている。

また、ユーザーに対するスパム送信や、ユーザーに代わってスパム送信することも禁止事項に追加された。このほか、他のアプリやテーマ、拡張機能のインストールまたは起動を主な機能とするアプリを禁止する項目は、このような拡張機能を禁止する項目に差し替えられている。

開発者は8月27日までに改訂版ポリシーに準拠する必要があり、以降も違反状態が続く場合は削除または無効化される可能性があるとのことだ。

リーディングビュー