Android 14 (Credential Manager) におけるパスキー対応が面倒すぎる

DroidKaigiにココらへんの話をしようと思って、CfP書いたけど落ちたので、自分用の覚書。

Firefox (GeckoView) AndroidでCredentail Managerの対応を入れたのが、GeckoViewとしてはバイナリサイズを大きくしたくないため、JetPackを一切使わずにCredential Manager経由でWebAuthn対応を行うコードをJavaでスクラッチで書いた。おそらくJavaでスクラッチで書いたのはChromeとGeckoViewだけだし、おそらくこの2つの製品以外でスクラッチ実装がされることは今後もないと思う。

しかもGeckoViewはWebブラウザエンジンなわけだから、いろんなWebサイトで実行可能な必要がある (= オリジンを正確に設定する必要がある)。この値を設定するのもおそらくBlinkとGeckoの2つの製品以外でほぼ存在しないであろう。なので、実装にあたって、実装者、すなわち自分しか被害者がいない事例がいろいろあることになるわけだ。自分はGoogleの人じゃないので、社内情報アクセスできないからね。

従来の実装方法

Google Mobile Service (GMS) にFIDO API (https://developers.google.com/android/reference/com/google/android/gms/fido/fido2/package-summary)が提供されていた。これを使うことでWebAuthnの実装が簡単にできるようになっている。またとあるバージョン以降であればパスキーをGoogle Password Managerに登録することが可能。これは古いAndroidでも動作する。

Credential Managerとは

Andorid 14から Credential Managerという仕組みが追加された。このCredential Managerはサービスとして実装されるもので、サードパーティに対して認証要求を移譲できる。ただこのサービスには3つのメソッドしか存在しなくて、登録・認証・削除があるだけだ。幅広い認証情報を扱えるようにAndroidチームの人は考えためであろうけど、この3つのメソッドには引数がBundleしか実質存在しない。すなわちアプリケーションはBundleに各々好き勝手に情報を入れると、OSにインストールされたCredential Managerサービスたちが、登録成功とか返すようになっている。なおBundleに何入れるべきか？なんてものも存在しない

Credential Managerを使ったパスキー実装

パスキーを実装するには、このBundleになにかを入れる必要があるのだが、そんな情報はdeveloper.android.comには一切存在しない。GeckoViewでは一通りのBundle定義をしているが、これらはJetPackのコードとChromeのコードから持ってきている。オープンソースだったからいいようなものだが、これらの謎定義はGoogle社内でしか共有されていないような感じなので、まぁなんというかEU頑張れって感じ。ここには入れていないが、Google Password Managerだけ無視するっぽく見える定義もあったりする

実際問題、JetPackを使った場合はここらのBundle問題はJetPack側で吸収されるので、そこらは問題になりえないのだが、問題はリクエスト用のJSONは自分たちで組み立てないといけないってことだ。 なので、WebAuthnの仕様をちゃんと理解しないといけない。それをアプリケーション開発者に求めるのはどうかと思う。なおレスポンスもJSONむき出しで渡される。検証とかしたい場合は、むき出しで渡されたJSONデータを展開して検証しないといけない。

以前のGMSのFIDO APIではJSONむき出しな仕組みにはなっていない。引数はBuilderが用意されているので、必要なパラメータを設定するだけで行える。ちなみにGeckoViewでいうと、これがCredential Manager版でここがFIDO API版なのだが、Credential Manager版は自分でJSONを組み立てるのに対して、FIDO API版はBuilderで引数を組み立てる。

あと、検証時 (Assertion) には落とし穴が実は存在してて、クライアントサイドで検証する際には、レスポンスのJSONの ClientDataJsonハッシュを使って検証を行うわけだけど、レスポンス内のこの値は正しくない可能性があって、リクエスト時にBundleに入れたClientDataJsonのハッシュが正しい値だったりする (これは2日悩んだ)

現在のCredential Managerがどの認証方法を対応しているか?

そんな方法はない。

とりあえず試してみて、サービスがTYPE_NO_CREATE_OPTIONSを返してくれれば、たぶん対応していないということがわかる。なお、1Passwordは最初のリクエストでサービス自体がクラッシュしたりするので正しく動かなかったりする。GeckoViewだと登録時はResident KeyがRequiredのときだけCrednetial Managerを使うようにしているが、Preferredの場合にどうするかは決めかねている。

また、認証を行おうとしてるクレデンシャルがGoogle Password Managerで認証可能かどうか？みたいなのはFIDO API経由で確認は可能なので、認証可能であればGMSのFIDO2 APIを使って、認証できない場合は Credential Managerを使ういうこともできる。GeckoViewもChromeもそのようなコードを入れている。

結論

GMSのFIDO APIがCredential Manager対応すれば、みんなハッピーだったのでは?やっとサードパーティ製品で対応が増えてきたところだしさ

Web Speech APIのSpeechSynthesisEvent.elapsedTimeは秒を返すのだけど

バグレポートを受け取って気づいたのだけど、SpeechSynthesisEvent.elapsedTimeは秒を返すのが正しい。ただほとんどのブラウザがこの値を秒で返していなかった (例外はFirefox for Linuxくらいかも)。なので、Safariも最近直っていたので、Firefox側も直した。

ここまでは普通の話なのだが、バグ報告をした人がChromeでも同じ問題が起きるとしてバグを報告したのだが、このバグが滑稽。Chromeはバグを受け付けるとQAが出てくるのだけど、そのQAがまずWeb APIの仕様を理解してないし、理解しようともしない。その人を乗り越えないと、Bug Triageさえちゃんとやってくれないようで、バグを認識させるためにはそのQAが投げ出すまで付き合ってあげないといけなくて、非常に無駄なコストがかかる。google.comじゃなくてchromium.orgのメアドを使っているからどこかのベンダーなんだと予想してるのだけど、そうだったらもっとまともな会社使おうよと、Google。

そもそもWeb Platform test (wpt) でTest failure発生させられる話だったら、そういうテストケースを書いておいて、さくっとwptに入れちゃうのだけど、このissueに関してはwptを書きようがないので、まぁChromeチームはずっと放置すると読んでる。

なお、Bug Triageに関してはMozillaは詳しい人かチームマネージャがやるので、大概ちゃんとした人が見ることになることが多い。こんな感じでBug Triageをちゃんとやらない製品はバグ修正とかにコストかけない (または評価システム上、評価されない) だろうなぁと勝手に思ってる。

OSのIME関連APIとWebブラウザは相性が悪い

今どきのWebブラウザは複数のプロセスで動くことが前提になっている。Chromeで言えば、メイン(UI)プロセスとレンダラープロセス。Firefox用語であればChromeプロセスとコンテンツプロセスという感じで別れて動作している。Webコンテンツはコンテンツ用のプロセスで表示され、文字入力はUI用プロセスで動作している。だから入力された文字はコンテンツ用のプロセスへプロセス間通信で送られ、コンテンツ用プロセスで内部的に描画されるいることになる (実際に画面上に描画されるのがGPUプロセスだったりUIプロセスだったりするけど)。

今どきのOSで使われるIMEのためのAPIは入力された文字をただアプリケーションに渡すだけではなく、様々なことを要求してくる。例えば文字変換の精度を上げるために現在入力している場所周辺の文字情報をアプリケーションへ要求したり、文字変換用パネルウィンドウの表示位置を決定するために、アプリケーションが文字入力している表示座標の問い合わせをアプリケーションへ行ったりする。

Webブラウザは反応速度を上げるため、基本的にはブロッキングするようなプロセス間通信を許可しない (もちろん例外がないわけではないが)。プロセス間通信は基本的に非同期で行われてる。たとえば、コンテンツ用プロセスがビジーな状況というのは結構ありがちな状況で、その状況下で同期モデルなプロセス間通信を使うと、当然のことながら、そのプロセス間通信が正常終了するまでに長い時間がかかり、反応速度が非常に悪くなる。なので基本的には非同期なプロセス間通信を利用している。

この非同期なプロセス間通信のみを許可するというところが、非常にIME関連APIとの相性を悪くしている。なぜなら多くのケースでこれらのAPIが非同期API (例えば引数で渡されたコールバック関数経由で値を渡す) ではなくて、同期APIになってたりする。または、非同期的なレスポンス (エラーコードとして、今はPendingだからまた問い合わせてねというものを返す) を返すことが可能であっても、そのエラーコードを見てくれなかったりなど、まぁWebブラウザがこういうモデルを要求しているというニーズにIME関連APIがマッチしてない。APIデザインが最後発であるAndroidでさえ、残念ながらここらがすべて非同期になってない。

そんなこと言っていても、OS側がこちらの欲しいAPIを実装してくれるわけでもないので、ChromeもFirefoxもいろんな手を使ってこの状況下でもIMEを動かすようにしている。ただうまく行かないケースになった場合、例えばIMEの候補ウィンドウが間違った場所に表示されてしまったりするのは、これらのブラウザ側のハックがうまく動かなかったケースになる。Android版になると、メインプロセス内でもブラウザのメインスレッドとAndroidのUIスレッドが別になるので、より複雑さを増したりする。

なお、Apple (macOS) はWebKit2のときにこの問題を解決するめに非公開の非同期API群を作って対処した。Appleズルい

Chat Channels of Web Engine

メジャーブラウザを作っている三者 (Apple、Google、Mozilla) は知ってる限り、各ブラウザプロジェクト用チャットチャンネルを持っている。FreenodeにChromiumとWebKitのチャンネルはあるのだけど、実際そんなに使われているわけではなくて、別のものを使っている。AppleとGoogleはSlackに、MozillaはMatrix上に存在する。Mozillaも社内向けには別のチャンネルがあるし、ずっとIRCサーバーを運用してたのだけど、最近Matrixに移行した

Chromium

https://chromium.slack.com/。chromium.orgアカウントを持っているとか、彼らにとってのパートナー会社であれば、Slackのチャットサーバーに入ることはできる [*]

Gecko

https://chat.mozilla.org/。githubアカウントでもFirefoxアカウントでも入ることが可能

WebKit

https://webkit.slack.com/。https://webkit.org/getting-started/に招待リンクがあるから、そこから入ることはできる

メモとして残しておく

Edge/ARM64の出来をみると、Windows on ARMのx86エミュレーターは結構速い

WebCrypto APIのベンチマークというのは結構難しくて、そもそも現在のWebCrypto APIはPromiseベースの実装のため、下手をするとWebブラウザに実装されたマイクロタスクをテストするだけのものになることもある (≒なのでベンチマークを取るとったとしても正確なデータかというと、、、な時がある。WebCryptoを使ったベンチマークを説明する時にPromiseの話を触れない人は正しいマイクロベンチマークを書くことが出来ない人なのかもしれない)。Promiseで結果を返すようなAPIはベンチマークが正しい結果を出すとは限らないのだが、それを抜きにしても面白いデータが取れたのでここに書いておく。

jsperf.comに簡単なWeb Cryptoのベンチが置いてあったのだけど、まずx86版ChromeをWindows 10 on ARMで動かしたデータが以下になる。

これをARM64版Edgeで実行すると以下になる。

なんとx86版のほうがAESのベンチマークが圧倒的に速いという結果になる。これはx86版はAES-NIをちゃんと使っていて、x86エミュレーターがちゃんとAES-NIをARM専用命令に置き換えているからと思われる。

ARM64にもAESは専用命令があるのだが、OpenSSL/BoringSSLでは、アセンブラで書かれているコードでARMの専用命令を使っていて、これはGNU AS用のアセンブラコードなので、MicrosoftのARM RealView形式のアセンブラと互換性がないから、おそらく無効にされているのだろう。

なお、ARM64版Firefoxだとこういう結果になる

これはちゃんとしたネイティブ実装 (by 自分) をしており、AESとSHA2はARM Crypto Extensionを使った実装になっているので、ちゃんとネイティブの方が速い。

ネイティブ版でも必ずしもエミュレーターよりも常に速いわけではない。というよりも、もっとARMに対してやる気出せよ、Microsoftと。

How to add API status to Firefox Platform Status

ChromeやEdge、WebKit (決してSafariではない) に続き、Firefoxもステータスページを作った。

MDNにも対応情報はあるがこれの情報はMDNと同期してるわけではない。また、例えばChrome Statusとかcaniuseには載っているけど、FirefoxのStatusにおなじ情報がないってのもある。

ただ当然のことならが、githubにこのコンテンツ用のレポジトリが存在してて、issueを立てたりPull Requestを送ることで、ここに項目を追加したり情報を修正することは可能になってる。実際features配下へマークダウンファイルを追加することで項目を追加できる (実際、実装やってたAPIのIssue投げたらPull Request投げろって言われて投げた)。詳細はCONTRIBUTING.mdに書いてある。

なお、Chrome Statusは、https://omahaproxy.appspot.com/からJSONとかでも取得できる。

何か情報が間違ってれば、WebKit以外は以下のgithubでissueとかを投げられるし、WebKitもhttps://bugs.webkit.org/に投げれば拾ってくれるはず。

• Chrome ... https://github.com/GoogleChrome/chromium-dashboard/
• Edge ... https://github.com/MicrosoftEdge/Status
• Firefox ... https://github.com/mozilla/platatus/

WebView Hell

現在の（ちゃんと開発されている）OSってのは、だいたいが組み込みのHTMLレンダリングエンジンを持っていたりする。こういう流れは、Internet Explorer 3以降やAppleのCyberDog (誰も知らないと思うけど) が最初だと記憶してるけどね。iOSのおかげでWebViewという表現がよく使われるのでWebViewって言葉を使って書いてる。

Trident

独禁法の裁判でもOSなのかアプリなのかという点で争ったこともあるけど、現在の判断だとOSという判断で差し控えないと思う。Internet Explorer 4にShell Update (Active Desktopと呼んでたけど) が含まれていた関係上シェルの動作に支障がきたすことがあったが、このShell Updateをインストールしなかったとしてもいろんな問題が生じてた。

例えばOS初回起動時に表示される"ようこそ画面"はHTMLで書かれてて、HTML Component (HTC)を使って動いていたのだけど、これがInternet Explorerのバージョンアップでスクリプトエラーになるとか、OS側でWebViewを使ってるコードは結構問題を引き起こしてた。(Windows 2000以降のExplorerのビューもHTML使っててみたいな話があってだな、動作が変わってしまう機能が存在してた)

OSとWeb Browserは切り離してバージョンアップ可能な仕組みを持ってたのにも関わらず、OSモジュールとしてメンテナンスされている古いバージョンのモジュールを残す仕組みを持っていないためにいろんな問題を引き起こしてた。Windows XP移行は Side-by-Side (SxS) が導入されているので古いバージョンのモジュールを残すことはできるようにはなったけど、Internet Explorerはいまだにこれを利用してない (はず)。

その変わりといってはなんだけど、Shellに関するモジュールだけはInternet Explorer 7以降ではアップデートしないような構造にはなった (IEFRAME.DLLというバカでかいモジュールがその役目)。

レンダリングエンジンが変わってしまうってところに関しては解消されなかったけどね。

そんな感じでOS内蔵のレンダリングエンジンをOSとは別にアップデート可能にするといろんな問題を引き起こすのをMicrosoftは証明したわけだ。

Chrome + blink

Android上で利用できるWebViewはシステム組み込みのものを利用することになっている。これがAndroid 4.4からは独自WebKitベースのものからChromeのBlinkベースに変わりはするけども同じような問題を持つ。標準ブラウザがChromeになるっぽいってことからこれで非互換からおさらばできるって考えてる人が結構いるみたいなんだけど、それは無理だと思う。それはChromeのバージョンアップがシステムのWebViewのバージョンアップを含めることができるかどうかなんだ。

そもそもアプリケーションパッケージのインストール機構でOSのファイルを置換できる仕組みをGoogleは取らないだろうし、一つのアプリケーション (この例でいえばChrome) のバージョンアップでシステムのフラッシュに入ってるモジュールを置換できるような方式をとることができることを許すとなれば、それはある種の脱獄の穴を作ることになる。Playストアからアップデートさせるんじゃなくて、6週間ごとに新バージョンのChromeを含む新しいシステムアップデートが全端末にOTAされるとかって方式になるんだったら、その限りではないけどね！。

また一番重要なのはシステムのWebViewはChromeベースになったとしてもその使ってるコードはおそらくベンダがカスタマイズしたコードでしかなくなる。そのカスタマイズさがフラグメントの理由になるんだ。しかもApache 2とかBSDライセンスだと変更点は公開する必要がないから変更点はベンダしか知らないからブラックボックスでしかない。しかも独自のバグがあってもそれはGoogleがやったことではないからGoogleが直せないんだ。

だからハッピーになるかと言えば、まぁならないんじゃないかな？。回避策はえっと、Android認証のテストツールにBlinkのテストツールをすべてパスするようなことを要求するしかないんじゃない？そうすればマシになると思うよ。

Firefox OS

OSとブラウザが完全統合されている場合で一番いい例がFirefox OSになると思うからそこも最後に書く。

個人的にはFirefox OSはフラグメントはAndroidほどひどいものは起きないと予測してる。なぜかというとGecko部分のソースコードはMPL2ライセンスであるってこと。MPL2だとソースコードの変更点は要求があれば公開しないといけない。各ベンダでカスタマイズってのは今後起きるとは思うけど、変更点がわかる以上ブラックボックス化しないから、どうにか対処可能じゃないかと。

もちろんフラグメントは起きるだろうけど、Androidほどはひどくならないんじゃないかな。まぁ今後はどうなるかは興味ある。

Software Design 総集編 【1990~2000】に寄稿しました

このプレゼンを過去に日本ウェブ協会さんでやってたということもあって、

ブラウザの歴史 from Makoto Kato

Webブラウザの歴史的なことの寄稿を久々にした。内容はすごーーーく公平に書いてます。だってMozilla以外にも関わってたし。ブラウザでのSandBoxモデルなんてメジャーなブラウザではChromeが最初だと思ってる人いるみたいだけど、IE7のLow RightIEが最初だとかさ。



これ書いてる時に、Netscape 2.0とかをWindows 7で動かさそうと思ったら、ちょっと問題があるけど動いたところが感動した (テキストボックスが右から左のモードになってしまう)。Windows 95時代のバイナリが動くWindows 7の互換性にね。

なお、セットアッププログラムが16ビットなので32ビット版のWindowsにしかセットアップはできないけどね！

Blink

BlinkというWebKitフォークの話がやってきた。Googleにはエイプリールフールに発表してほしかったね。イースターで祝日だからしょうがないか。

GoogleのWebKitにまつわる話は2010年くらいにマウンテンビューで聞いたことがあるんだけど、Chromeチームはマージに非常に苦労しているという印象だった。だからフォークしてしまうってのはGoogleにとっては非常に正しい判断なんだろうなとは思うし、Googleの抱えている人の数からしてみればWebKitに固執する必要はなく、新しいレンダリングエンジンを投入するだろうなとは思ってたから、一年遅いなってのも印象でもある。

それよりもだ。興味があるのはレンダリングエンジンとかじゃなくて、WebKitというオープンソースプロジェクトの今後だ。実際WebKitはいろんな人たちが関わっているプロジェクトではあるけれど、Googleのチェックイン数が群を抜いてるものでもある。そこからGoogleが抜けることになるとは思うんだけど、ここからWebKit発のイノベーションが消えてしまうのかどうかが気になるところ。今後AppleとかSamsungがどうこのプロジェクトをドライブするのかが見もの。

WebKitは企業がOSSに参加しているものとしていい代表例の一つでもあったとは思うんだけど、実質企業コントロール化されたOSSプロジェクトがメインスポンサーを失うとどうなるのかといういい例になる気がしてる。MeeGoとかも末路はね。。。(Tizenは後継と言ってるけど、実際のところほとんどのコードを破棄してプロジェクトの新規作成に近いので後継と言う表現は間違ってると思う)

FirefoxというかGecko自体も (レイオフの結果) Netscapeというメインスポンサーが抜けた後、現在の形 (Mozilla FoundationからMozilla Foundation / Corporationという形) になるまで非常に苦労をしたわけだし。

あと、ここはLunascapeあたりにWebKitとBlink内蔵ブラウザを期待するんで頑張ってね。BlinkはAPI固まらなそうでChromium以外は苦労しそうだけどさ。

Intel Atomの上でのJavaScriptパフォーマンス

このデータはSunSpiderをAtom Z560 (VAIO P) + Ubuntu 10.10上でのFirefox 4.0b9pre (2010-12-18)とGoogle Chrome 10.0.612.1 devで走らせた結果なんだけど、すごく興味深い。FROMはChromeでTOはFirefoxね。

TEST                   COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:           1.38x as fast     1361.8ms +/- 5.4%   987.8ms +/- 1.0%     significant

=============================================================================

  3d:                  1.41x as fast      224.0ms +/- 11.6%   158.5ms +/- 0.9%     significant
    cube:              ??                  61.7ms +/- 23.3%    64.0ms +/- 1.8%     not conclusive: might be *1.037x as slow*
    morph:             1.48x as fast       47.2ms +/- 8.7%    31.9ms +/- 3.1%     significant
    raytrace:          1.84x as fast      115.1ms +/- 9.3%    62.6ms +/- 1.1%     significant

  access:              -                  130.6ms +/- 12.0%   128.7ms +/- 2.5% 
    binary-trees:      *2.02x as slow*      9.7ms +/- 42.8%    19.6ms +/- 12.8%     significant
    fannkuch:          1.42x as fast       53.3ms +/- 18.4%    37.6ms +/- 2.7%     significant
    nbody:             1.73x as fast       48.4ms +/- 11.9%    27.9ms +/- 2.2%     significant
    nsieve:            *2.27x as slow*     19.2ms +/- 7.6%    43.6ms +/- 2.5%     significant

  bitops:              1.77x as fast       87.6ms +/- 19.7%    49.5ms +/- 4.9%     significant
    3bit-bits-in-byte: 2.79x as fast        7.8ms +/- 5.8%     2.8ms +/- 10.8%     significant
    bits-in-byte:      ??                  17.8ms +/- 37.5%    19.6ms +/- 3.1%     not conclusive: might be *1.101x as slow*
    bitwise-and:       4.19x as fast       30.6ms +/- 22.5%     7.3ms +/- 6.6%     significant
    nsieve-bits:       1.59x as fast       31.4ms +/- 14.6%    19.8ms +/- 8.3%     significant

  controlflow:         1.49x as fast       12.7ms +/- 14.0%     8.5ms +/- 5.9%     significant
    recursive:         1.49x as fast       12.7ms +/- 14.0%     8.5ms +/- 5.9%     significant

  crypto:              1.65x as fast      111.6ms +/- 6.8%    67.6ms +/- 1.1%     significant
    aes:               1.61x as fast       59.7ms +/- 14.7%    37.1ms +/- 2.8%     significant
    md5:               1.64x as fast       26.0ms +/- 7.3%    15.9ms +/- 1.4%     significant
    sha1:              1.77x as fast       25.9ms +/- 7.1%    14.6ms +/- 3.4%     significant

  date:                1.50x as fast      241.3ms +/- 3.7%   161.3ms +/- 1.4%     significant
    format-tofte:      *1.116x as slow*    84.7ms +/- 8.2%    94.5ms +/- 1.2%     significant
    format-xparb:      2.34x as fast      156.6ms +/- 4.6%    66.8ms +/- 4.2%     significant

  math:                ??                  88.1ms +/- 4.4%    91.6ms +/- 1.3%     not conclusive: might be *1.040x as slow*
    cordic:            *1.47x as slow*     19.4ms +/- 10.7%    28.5ms +/- 2.7%     significant
    partial-sums:      1.27x as fast       51.0ms +/- 5.3%    40.1ms +/- 1.0%     significant
    spectral-norm:     *1.30x as slow*     17.7ms +/- 6.0%    23.0ms +/- 2.1%     significant

  regexp:              1.34x as fast       50.2ms +/- 8.4%    37.5ms +/- 7.6%     significant
    dna:               1.34x as fast       50.2ms +/- 8.4%    37.5ms +/- 7.6%     significant

  string:              1.46x as fast      415.7ms +/- 12.6%   284.6ms +/- 1.9%     significant
    base64:            1.44x as fast       30.2ms +/- 6.4%    21.0ms +/- 6.2%     significant
    fasta:             1.25x as fast       60.7ms +/- 5.1%    48.5ms +/- 2.6%     significant
    tagcloud:          1.31x as fast      114.1ms +/- 9.5%    87.2ms +/- 1.4%     significant
    unpack-code:       1.60x as fast      137.3ms +/- 22.0%    85.6ms +/- 2.5%     significant
    validate-input:    1.74x as fast       73.4ms +/- 20.7%    42.3ms +/- 6.5%     significant

いろんなサイトで見るデータってのは、Core 2 DuoとかCore i7で走らせたものだから、互角 (新しいV8を採用してるChromeだからV8の方が速いかも?)なんだけど、Chrome OSがターゲットにしてるであろうIntel Atomプロセッサだと、V8って遅いんだよね。実際の理由は調べてないけど、CPUキャッシュの量が少ないからとかなのかもしれない。

JavaScriptのベンチをCortex-A8上で取ってみると

先週末にNetWalkerを弄っていて、Ubuntu 10.04ベースに変えたんだけど (カーネルはまだ変えてないけど、ポーティングは終了してるから動作テストとかしないと)、ARM版の10.04だと、Chromiumがレポジトリに入っているんだよね。起動速度はFirefoxよりは速いんだけど、ちょっとした疑問が。"V8ってARMでも速いの？"。

そもそもTraceMonkeyのアーキテクチャとして、CPUへの依存コードというのは最小限になっていて、LIRをコンパイルするだけになっている。なので、TraceMonkeyの肝はLIRの質とTracing可能な条件を増やすことで、そんなに各CPU毎の最適化は必要ない(もちろん最終的には必要なのだが)。また、V8ってのはそのような形式ではなくて、ゴリ押しでコンパイルするだけという割り切った仕様になってる。だから、各CPU毎の最適化ってのはちょー必要で、x86以外ちゃんとやってるのかどうかってのが疑問だった。

また、W3C Japanese IGでアクセスのNetFrontの開発の方にお会いした時に、各社ARM上でのJITってどうするのって話になって、「MozillaはARM用のJITは投入されているけど、他社はまだまだ正式投入はまだみたいだね。知る限りNitroもARMのJIT持ってるし、V8もARMのJITあるよ。」という風に答えていたんだけど、実測したことなかったし、ARM上のベンチマークも見たことがない

ということで、いろいろとテストしてみた。

グラフが汚いのはGoogle Docsのせいだけど、TraceMonkeyの方が速いってどんだけ他の会社手を抜いてんねん。Mobileだって重要だろうに。でも、凄く興味があるデータがとれた。

ちなみに、V8ベンチはTraceMonkeyよりもV8の方が速いのは当然。でもx86の時と比べて差が低くなってる。

Google Chromeのユーザー設定

ちょっと実験をしてた関係で、Google Chromeのユーザー設定がどこの入っているのかを調べてた。

ブックマークについては、ユーザーのプロファイル内のBookmarksファイルにJSON形式で保存されてて、ブラウザの設定内容もPreferencesにJSON形式で入ってる。sqlite使ってると思ったから案外意外。ブックマーク自体をする人が少なくなるだろうと思って設計したのかなって感じ。

ただ、Cookieと履歴に関しては、sqliteのデータベース (CookiesとHistory) に入ってる。しかもなぜか日付のデータ形式がFILETIME使ってる。Windows以外のプラットフォームだと面倒かと思うけど、新しいデータ構造を作るよりは既存のもので64-bitのものを採用しただけだろう。あと、フォームのオートコンプリートとかも同じディレクトリにあるファイルに入ってる。

なるほどねって感じだけど、そんなに工夫を入れてるわけでもないというところだね。

実験というのは、このことだけど、C++からJSONを簡単に扱える方法が既存コードではないようなので、JavaScriptベースで実装テストしてただけ。

日本語文書の読みやすさって

テストでGoogle Chromeを使ったときに、ページを見てて違和感があったので、そのメモ。

まずは、Google Chrome 3でのスクリーンショット(サンプルはこれを抜き出している)

なんか、ごちゃごちゃした感じになって、文字が読みづらい感じなんだよね。ってのが感想。

で、次にFirefox 3.5。

そうか、行間か！。CSSで指定してない場合の行間の高さの考えが違うんだと。

Chromeのときに1ドットだったので、WebKitの行間の考え方がおかしい？ってことなのかと思い、Safari 4での行間。

Safariだと読みやすい形で行間が空いている。Chromeの問題か。Googleの中の人たちももう少し日本語を考えてほしいなと。

ほかのブラウザだとどうなのよってことで、Internet Explorer 8ではどうよ。

さすが。日本語のノウハウ持ってるMicrosoftとAppleはちゃんとしてくるよね。

最後にOpera。

予想通りっていうか、そうだろうな。。。

V8のx64 JIT

久しぶりに、Chromeで使われているGoogleのJavaScriptエンジンである、V8のソースツリーを同期したらx64ネイティブのJITコードがコミットされてた。

けど、ビルドできないけどね。

ついでに、Mozillaのはどうなんったんだという話を追加しておくと、TraceMonkeyのx64コードはちょっと前に削除されたんだけど、reduxのツリーにあるx64コードを持ってくる予定らしい。ただ、reduxのツリーのものをそのまま持ってきても、ビルド通らないし、実装が1/3足りないので、実装し直す必要がある。patch branchとか。