Firefox Androidにおけるresident key (Discoverable Credentials) 対応

これの続き

Firefox AndroidにおいてはWebAuthnの実装をGoogleのFIDO2ライブラリを使っている。このライブラリはWebAuthn APIをそのままJavaのインターフェイスにしたようなものなので、Firefox AndroidにおけるWebAuthnの対応はこのライブラリの実装内容に依存している。

今年になってこのライブラリがアップデートされ、resident key (Discoverable Credentials) 対応が含まれた。ただ残念?なことにそのAPIを使うと、CredentialsがGoogle Password Managerで他のデバイスとGoogleアカウントを通じて同期するようになる。要は勝手にPasskey対応になってしまう。もちろん同期しないオプションなんてアプリケーション側が使えるAPIには存在しない。なお、デバイスがGoogleアカウントにサインインしてない場合、Passkeyが作成できないというエラーでWebAuthn APIは失敗する。

このような状況なので、いくつか懸念点はあるんだが、Firefox AndroidのStable版はabout:configを使えるわけではないので、デフォルトオフで実装は入れておいた。Firefox 114のBetaおよびNightlyでabout:configで該当設定を変更すれば使えるようになる。

PasskeysがGoogleアカウント経由で同期されるということは、例えば、ChromeでPasskeyを使ってサインインした場合、そこで利用されたCredentialがFirefoxでも使えてしまう (もちろん逆も同じ)。そのような感じでいろいろどうかと思う動作がいろいろあるので、Bug 1831137に解決しないといけない問題は書いてある。個人的にはAndroid 14以上の場合だけ使えるようにしてもいいかもだけど、まだ最終的な結論は決めてない。なぜAndroid 14以降なのかというと、このバージョンではCredential Provier Serviceというものが導入される予定で、Autofill Serviceのようにシステム側で使うように設定しておけば、Google Passowrd Managerではなく、設定したサードパーティのサービスが使える予定らしい。Android 14が出てから考えよう

Intl.MessageFormat

hi18n (i18nライブラリ) の紹介 (1) 設計思想と基本方針というのを見た。このブログ記事を見るとこれは文字列翻訳のメッセージフォーマットを行うライブラリの話らしい。翻訳というのは、Localizaiton (L10N) と呼ぶもので、Internationalization (i18n) とは違う。i18nというのは、文字翻訳じゃなくて、多言語を扱う、表示するということを基本指す。例えば日本語が表示できるとか入力ができるとか。まずwantedly社は正しい言葉を使うようにしてほしい。

さて、本題。

こういうメッセージフォーマットというのは、どうもいろいろ各社持っているらしく、車輪の再発明を各社でやっている状況らしい。そんな状態は労働力の無駄でしかないので、ECMA-402でIntl.MessageFormatというのを作ることになった。元のベースはFirefoxで使っているFluentと呼んでいるライブラリで、そもそもそれはFirefox OSのときに作られた仕組み (今は某社で働いてるZibiがFirefox OSのころからやってて、これをFirefox本体へ持ち込むときにECMA-402のいろんな仕様も追加してた)。

Intl.MessageFormatはただのAPIだけど、メッセージフォーマットの仕様はThe MessageFormat 2.0 Specificationに現時点のドラフトがある。ICU4Xで使えればWASMでも使えるので、自社で同じような機能の車輪の再発明を行っているのであれば、ここでいろいろ意見を言えば取り込まれると思うよ

CSS疑似クラスの:read-onlyと:read-writeが仕様通りに実装されることになった

いろんなやりとりを仕事がらするのだけど、自分のイメージ的には、WebKitは仕様上間違ってるという話を振れば、直してくれることが多くて、BlinkはQAが変な方向に持っていくか、開発者が斜め上の方向の話にしてしまいwontfix扱いになるということが多々ある。

最近やっと直す方向になった、CSS疑似クラスの:read-only / :read-writeがそのパターン。

元々は、Geckoが-moz-プレフィックス付きで実装してたものの一つで、その後、WebKit (確かBlinkに分かれる前) に実装されてた。しかもプレフィックスなしで。実装されたとしても、そもそも仕様として固まっていないものだったので、いろいろと差異が出るので、ちゃんと仕様として書かれたのだが、それが今回の発端である。

仕様がそもそもその時点のブラウザとは違う定義をしていたので (プレフィックスがあれば、別にいいやとは思うのだが、特にWebKitとBlinkがプレフィックスなし)、「これどういうこと？」と思い、WebKitとBlinkに対してバグを登録した。仕様自体を変更するという議論もありだと思っていたので、それぞれ (AppleとかGoogle) がやってくれるでしょ？ってことだしね。

WebKitは、さくっとこのバグを修正。エッジケースでまだ間違ってることはあるだろうけど、こっちが指摘した動作に関しては修正してくれた。

で一方、Blinkはというと、「これGeckoとかと同じ動作にしたからこういう動作なんでwontfix」。という結論に。個人的には「え？ならCSSWGで議論してよ」と。なぜ彼らはwontfixにする際に仕様に対してのコントリビュートとかWeb Platform Tests書くとかしないのかなぁと。たぶん人によるのだけど、残念ながら個人的にはよくあるパターン。

こういう状況だとGecko側もどうしようもないので (しかもGeckoだけプレフィックス付きだし、プレフィックス外すのだったらこれ結論必要だから) 困ると。ということで、CSSWG行きになった。(wontfixと言った張本人がなぜそっちに議論を移さないのかと本当に思うんだが)そこで議論のやり直しが発生した。

結論書くと、結果としては仕様を変えないということになり、emilioがGecko側をプレフィックス削除とともに仕様通りに修正を行った。

さて、問題はwontfixにしてしまっているBlink側ということになる。emilioがそのバグを再オープンし直したが、つい先日やっと直すことになったようで、そろそろBlinkでも直りそうということに。やれやれ。

そもそもBlinkは他の2つ (Gecko、WebKit) に比べて圧倒的な人的リソースを持っているわけだし、シェアも圧倒的なのだから、こういう仕様とは異なる動作の修正にリソースを割いてほしいと思うのだけど。。。。無理かなぁ。。。

WebKitとBlinkのスタンスの違い

最近WebKitとBlinkの実装が異なってることでいろいろ困っているんですが、その話はさておき、WebKitのスタンスが明確にわかるようなメールスレッドが最近あった。

Web NFCのエディタのFrançois Beaufort (Google)がWebKitサイドへWeb NFCについての意見を聞きたいということで、webkit-devにメールを投げたのだけど、そのお話。

メールスレッドはこれ。
https://lists.webkit.org/pipermail/webkit-dev/2020-January/031006.html

事実上WebKitトップのMaciejが、

We do not believe a permission prompt is a sufficient mitigation for the serious security and privacy risks raised by this specification.

という話を出ししてて、まぁプロンプト程度で有効にするしないで決められるようなAPIはおそらく実装されることはないんだろうなと

In addition, we think exposing direct hardware access to the web is a bad idea and compromises the device-independence of the web platform.

ということで、WebKitに関しては基本的にデバイスを触るようなAPIは(よほどのユーズケースがない限り)実装されるのはほぼないようだ。

なお、出来レースなんだろうなという感の強いblink-devへのIntent to experimentは全くこういう話を語られることはないし、LGTMとしか反応がない感強いし、もし議論があったとしてもたぶんpublicな場で議論することはないんだろうなと。

webkit-devでは、とどめにniwaさんに、

I'll go off a bit on a tangent and say that one of the primary strengths of the Web is that users can visit any website without the fear of their computing devices being permanently compromised

というように、"Web" というものの利点が語られて、

If we continue this path, at some point (or maybe we're already there), the Web will turn into any other non-Web platform where ordinary users can (or are advised to) only use well known trusted applications or visit well known trusted websites just like how native apps work today.

言われてて、WebKitの考えるWebの利点と反するようなものはWebKitでは実装されないのだろうとわかる。

いろいろなMeet upでたまにDevice API系の話 (WebUSBとかWebMIDIとか) をする人を見かけるけど、WebKitがこんな感じなのでWICGとかを抜けて標準化に持ってくもの (≒2つのエンジンの合意) はほぼなさげだよなと (Mozillaはプライバシー問題が解決されないものは基本実装されない感じ)

Web Assembly

Firefox Developer Conference 2015 in Tokyoがあったのだけど、そこでemscriptenとWeb Assemblyの話してきた。



Web Assemblyは個人的に今一番ホットな話なんだけど、このイベントの矢倉さんのセッションでもViewSource ConferenceでLukeが話した内容を元に2ページほど触れられている。

あと、先週のBlinkOnでもセッションあったので、これもみるべし。

今のところ、s-expreesionベースのフォーマットでみんな実装実験やってるし、clang/LLVMも:sunfishがバックエンド実装やってる。LLVMについてはasm.jsからのwasmトランスレーターで間に合うからステーブル化の最初のMUSTなことではないけど。ちなみにJavaScripteCore/WebKitはすでに実装テストしてて、CPP->JSにしたものとCPP->JS->WASMにしたもので比較すると2倍の速度で動くっていう結果が出てる。

セッション終わったあと、Jxckさんと話しをしててWeb APIを直接触りたいよねって話をしてたんだけど、なんかAPIは作る話にはなってるっぽい(けど、これは最初のゴールには含まれない)。

基本ゲーム (canvasとWebGLは使いたいよね) が最初のターゲットかなと。

Access-Control-Allow-Credentials

久々にhtml5とか勉強会に行ってみたんだけど、最後の質問の話。Access-Control-Allow-Credentialsについて。質問内容としては、XMLHttpRequest Level 2でクレデンシャルフラグがセットされた時にAccess-Control-Allow-Credentialsをtrueにしないとどうなるか。

スペックの部分はこういうことになってる。

7.2 Resource Sharing Check

1. If the response includes zero or more than one Access-Control-Allow-Origin header values, return fail and terminate this algorithm.
   
2. If the Access-Control-Allow-Origin header value is the "*" character and the omit credentials flag is set, return pass and terminate this algorithm.
   
3. If the value of Access-Control-Allow-Origin is not a case-sensitive match for the value of the Origin header as defined by its specification, return fail and terminate this algorithm.
   
4. If the omit credentials flag is unset and the response includes zero or more than one Access-Control-Allow-Credentials header values, return fail and terminate this algorithm.
   
5. If the omit credentials flag is unset and the Access-Control-Allow-Credentials header value is not a case-sensitive match for "true", return fail and terminate this algorithm.
   
6. Return pass.

ということでAccess-Control-Allow-Credentials: trueにしないとfailするってことらしい。ちなみにこれをレスポンスヘッダへ複数設定した場合もfailするとのこと