won't fix

TP-Linkの2.5Gスイッチングハブが壊れた

2026-03-04T15:29:00.000+09:00

2021年に買ったTP-Linkのスイッチングハブ (5ポート2.5G) が壊れた。買って5年経たないくらい

最近たまにデスクトップPCのネットワークが切れる現象が発生していた。デスクトップ側のチップかドライバの話だろうと考えていたのだが、最終的にスイッチングハブの電源ランプが点滅し始めて一切ネットワークポートが認識しなくなった。予備のハブ (Edge Router-X) に繋ぎ変えると当然の如くネットワークは復活するのでどうもTP-Linkのスイッチングハブが壊れたようだ。ちょうど買ってから5年くらいでかつ、低価格な2.5Gなスイッチングハブの先駆けみたいな製品だし、ファームウェアも初期のV1だったので、そんなものだろうという感じかも。TP-Link自体は福岡大学事件から信用はしてないのだが、スイッチングハブならマシだろうということで買ったのだが、Amazonのレビューとかを見るとやはり壊れている人が何人もいるそうなのでまぁそういう品質だろう。

なお、このスイッチングハブの保証期間は5年ということなので、試しにサポートにメールで問い合わせたところ、故障機材送付することになり、結果として新しいスイッチングハブと交換になった。V1ファームがV2ファームに変更になってたけど何が変わったのかは知らない

eero 7を手に入れた

2026-02-28T18:23:00.000+09:00

今や親会社がAmazonであるeeroだが、2024年頃から日本でもネットワークルーターを販売している。ちょっとは気になっていたのだが、セールで割引があったのと自宅で使っているASUSのルータが古い(Wi-Fi6未対応)のもあって試しにeero 7を買ってみた

UniFi (Dream Router 7とかDream Express 7)とかでも良いのだけど、これらを買うほど機能はいらないし、そもそもルーターにVPNとかはいらないので (tailscaleで満足してる)、モノは試しということで。知人も買ってないしね

使ってみたところ、今どきのルーターらしく基本が自動設定でなんでもしてくれて、例えばWAN側がIPoE対応であればそれを認識してそのプロバイダに適した設定にしてくれる。自宅はahamo光なのだが、SFPのメディアコンバーター経由で直接ルーターに差してみたところ、ちゃんと接続できた。ただ自動設定が失敗した時に手動設定で細かく設定できないので、自動設定で動くか動かないかでこのルーターの評価は分かれそうとは思う。

はっきり言って、LAN側のDHCPの設定くらいしかできないので (ブリッジとか手動とかもできるが)、ネットワーク設定みたいなのはわかりませんというユーザー向けの商品だなと。

なおeero Plusというサブスクもあるらしく、VPN / DDNS / wiki無線分析 / 1passwordが使えるらしいが、月1500円という値付けは強気だなと思う

AndroidアプリでPasskeys対応したと行ってもだいたいGoogle Passowrd Managerのみという状況は理解出来る

2026-02-14T13:34:00.002+09:00

巷のAndroidアプリケーションが「Passkeys対応しました」という話が出ても、実際にはAndroidデバイスでの自動入力の設定に従ってPasskeysプロバイダが選択されるのではなく、Google Password Manager(以下GPM)が使われることが多いと思う。AndroidでPasskeysプロバイダ(実際にはCredential Managerサービス)が自動入力でサポートされたのはAndroid 14からなのだが、Android 14以降のデバイスを使っていて、かつ自動入力をGPM以外(例えば1Password)に設定していたとしても、GPMが使われている場合をよく見る。

Googleは過去のAndroidバージョンでWebAuthn対応を容易にするため、FIDO2ライブラリを別途提供している。このライブラリは、Passkeysの場合、Android 14以降であってもGPMを使うように設計されている。Android 14以降のみをターゲットにするアプリはほぼ存在しないため、このライブラリを使うのが最も手っ取り早いからだろう。また、WebAuthnリクエスト用のJSONデータ構造などもライブラリ側で吸収してくれるため、WebAuthnの詳細な知識なしでPasskeys対応アプリケーションの実装が可能である。

Firefox for AndroidではCredential Manager対応をJetpackなしで実装しているため、FIDO2ライブラリとCredential Managerの両方を使うようにしている。これが非常に面倒で、例えばWebページがPasskeysを使ったログインをリクエストしてきたとしよう。その認証情報がどのプロバイダに入っているかという情報はWebブラウザ側にはないので、どうしようもない。仕方なく、まずGPMに認証情報が入っているかを確認し(GoogleのFIDO2ライブラリにはそのような機能が数年前に追加された)、そこになければCredential Managerに問い合わせするようにしている。これも苦肉の策なのだが、Chromeのコードを見ても同じようなことをしていて、まあ何とも言えない感じである。

またCredential Manager対応したとしても、Firefoxに寄せられているバグ報告を見ると、Bitwardenにしているのだけど動かないとかの報告がたまにある。こっちでは全く再現できないのだが (自分は1passwordとBitwardenで常にテストを行っている)、まぁデバイスやGoogle Play Serviceの依存関係で動いたり動かなくなったりするっぽいので、トラブルの元でもある

こんな状況なので、Credential Manager用のAndroidXライブラリを使うよりも、圧倒的にFIDO2ライブラリを使った方が楽である。そもそもChrome for Androidがサードパーティ製のPasskeysプロバイダを積極的に使う仕組みになっていないので、Google側もきちんと問題をトラッキングできていないような気がしている。

こういうところはWindowsやmacOSのように、WebAuthnのクライアント機能自体をAPIとして提供した方が、クライアントアプリ側で全く考える必要がないし、そもそもFIDO2ライブラリ側ですべて吸収すればよかったのにそうしないところが、Googleのセンスのなさというか、まあ言い方を変えれば、雇った人たちの仕事を作ってあげたんだろうね、としか言いようがない。

ZwideのSA11というN150なWindows タブレットを入手した

2025-08-20T09:32:00.000+09:00

Surface Goがもっと安ければ検証用のPCとして買おうと思ってたのだが、Zwideという会社のSA11 が安かったので買ってみた。

ZwideはどうもODMをやっている深圳の会社っぽいけど、最近は自社ブランドのPCをいくつか作っている。というかどこかでみたことあるようなデザインのPCがいくつかあるので、そういう会社何でしょうってことだろう。

このPC自体は、世の中で出回っているN100とかを採用したPCでなくTwin LakeなN150だが、Twin Lake自体がAlder Lake-Nの改良版でしかないので、消費電力的に優位なだけでほぼN100と変わらない (らしい)。同じIntel 7での製造ってことなので、今後はN100がN150に置き換わるのだろう。

自分は試していないのだが、Linuxを使うとタッチパネルのドライバに難があって、タッチしたポイントが正しくないらしい。自分はLinuxでのテスト環境としては使わないけど、Windows以外を使うときは要注意みたい。

あと、この値段でUSI 2.0のスタイラスペンが使えるというのは大きなメリット。Amazon Fire HD 10用のスタイラスペンがUSI 2.0準拠なので試しに使ってみたところ、ちゃんと使用可能でした。

Switch2 の Web ブラウザ

2025-08-18T19:44:00.006+09:00

数年前にNintendo Seattle (マイクロソフトの本社の敷地に隣接する任天堂のアメリカ拠点) のオープンポジションでChromiumがらみのものがあったので、Switch2 はもしかして、WebKitではなくて、Chromium/Blinkベースになるかと思ってたけど、結局は、

Mozilla/5.0 (Nintendo Switch; WifiWebAuthApplet)
AppleWebKit/613.0 (KHTML, like Gecko)
NF/7.0.3.8.16 NintendoBrowser/5.2.0.35533

ということで、WebKitベースのままだったのだが、Switchも含めて一番よくわからないのは、

証明書のダイアログが実装されていること。これはたぶんNetFrontの機能なんだろうな。なおJavaScriptエンジンのJITは無効になっている模様 (ゲームとかだと有効にできるかもだがSDK次第でしょう)

Iterator.size_hint

2025-07-22T23:11:00.004+09:00

Iteratorトレイトにsize_hintというメソッドがあるけど、Iterator.collect()でVecにするときは、このsize_hintを実装するかしないかでVecの初期キャパシティが決まるので、collectのパフォーマンスに影響があるということを今日初めて知った。

Ref: https://github.com/unicode-org/icu4x/pull/6764 / https://bugzilla.mozilla.org/show_bug.cgi?id=1974993

TemporalのV8での実装

2025-05-24T17:00:00.005+09:00

GoogleのInternatiolization teamに所属するShane CarrがRust Weekでプレゼン (2:50:00くらいから) してるんだが、

GoogleのV8 (Chromium等で使われるJavaScript Engine) がTemporalの実装のバックエンドにICU4Xを使うことになりそうだ。そもそもShaneはICU4XのChairだし、Temporalの仕様策定もおこなっている人なので、そういうことなんだろう。

Firefoxも現在はICU4X 1.5ベースの実装が使えるようになっているが、次のサイクルで自分がICU4X 2.0ベースに変更する予定だが、SpiderMonkeyとV8の実装はそろそろ固まりそう。ただWebKitどうするんだろ。ICU4Cベースでどうにかするんですかね...

HiFive Premier P550を手に入れた

2025-01-12T15:38:00.003+09:00

SiFive P550というコア使ったHiFive Premiver P550というボードを入手した。メモリ16GBが日本円で約60000円強。前買ったUnmatchedはドルだと$250高かったけど、円的にはそんなに変わらず。円安...

Install Ubuntu to SSD

確かまだPremier P550対応のDTSなどLinuxのコードはメインラインには入ってないけど、eMMCにはUbuntu 24.04 TLSがプレインストールされていてシリアルコンソール経由でログインすることが出来るが、SATAポートがこのボードに存在しているので、SSDにインストールすることにする

イメージを取得

https://github.com/sifive/hifive-premier-p550-ubuntu/releases/tag/2024.11.00にUbuntuのイメージが置かれているので、これを入手する

ディスクに書き込む

まずxzで圧縮されているので、展開

xz -d ubuntu-24.04-preinstalled-server-riscv64.img.xz

SSDが/dev/sdaだとして、ddコマンドでディスクに書き込む

dd if=ubuntu-24.04-preinstalled-server-riscv64.img of=/dev/sda bs=1M

この状態でリブートするとSSDが(hd0)になるので、SSD経由でブートする。ただし、eMMCはこのイメージを書き込んであるっぽいので、GPTのUUIDが全部一緒になるので、好みにおおじてGPTを変えてupdate-grubかけたほうがよい

Unix Bench

------------------------------------------------------------------------
Benchmark Run: Sun Jan 12 2025 06:34:27 - 07:02:47
4 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       12927124.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2641.1 MWIPS (9.9 s, 7 samples)
Execl Throughput                               1176.6 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        229490.7 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           72809.9 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        374429.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                              475331.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  31965.9 lps   (10.0 s, 7 samples)
Process Creation                               2703.0 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   3510.5 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1154.5 lpm   (60.0 s, 2 samples)
System Call Overhead                         590916.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   12927124.9   1107.7
Double-Precision Whetstone                       55.0       2641.1    480.2
Execl Throughput                                 43.0       1176.6    273.6
File Copy 1024 bufsize 2000 maxblocks          3960.0     229490.7    579.5
File Copy 256 bufsize 500 maxblocks            1655.0      72809.9    439.9
File Copy 4096 bufsize 8000 maxblocks          5800.0     374429.0    645.6
Pipe Throughput                               12440.0     475331.9    382.1
Pipe-based Context Switching                   4000.0      31965.9     79.9
Process Creation                                126.0       2703.0    214.5
Shell Scripts (1 concurrent)                     42.4       3510.5    828.0
Shell Scripts (8 concurrent)                      6.0       1154.5   1924.2
System Call Overhead                          15000.0     590916.1    393.9
                                                                   ========
System Benchmarks Index Score                                         463.6

------------------------------------------------------------------------
Benchmark Run: Sun Jan 12 2025 07:02:47 - 07:31:09
4 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       51689178.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    10560.7 MWIPS (9.9 s, 7 samples)
Execl Throughput                               4324.4 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        758792.3 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          282576.0 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1383510.8 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1893625.3 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 218013.6 lps   (10.0 s, 7 samples)
Process Creation                               9020.4 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   9097.3 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1184.8 lpm   (60.1 s, 2 samples)
System Call Overhead                        2362850.1 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   51689178.8   4429.2
Double-Precision Whetstone                       55.0      10560.7   1920.1
Execl Throughput                                 43.0       4324.4   1005.7
File Copy 1024 bufsize 2000 maxblocks          3960.0     758792.3   1916.1
File Copy 256 bufsize 500 maxblocks            1655.0     282576.0   1707.4
File Copy 4096 bufsize 8000 maxblocks          5800.0    1383510.8   2385.4
Pipe Throughput                               12440.0    1893625.3   1522.2
Pipe-based Context Switching                   4000.0     218013.6    545.0
Process Creation                                126.0       9020.4    715.9
Shell Scripts (1 concurrent)                     42.4       9097.3   2145.6
Shell Scripts (8 concurrent)                      6.0       1184.8   1974.6
System Call Overhead                          15000.0    2362850.1   1575.2
                                                                   ========
System Benchmarks Index Score                                        1591.8

大体Unmatchedの2倍くらいの速度

2024年に買ったもの

2025-01-10T16:37:00.004+09:00

買ったものを書いているけど、これ以外には、家 (賃貸) のトレイが壊れたため、結果として新しいトイレのユニットに入れ替わった (元のトイレは25年前のもの)。今どきトイレは水の使用量が少なくなっていたりするけど、そもそもシャワートイレにしないところが、大家...とは思ったが

Google Pixel 8a

これをメイン機にして、いままで使っていたPixel 6aをテスト機に格下げしました。前までの手頃値段感はなくなったけど継続して買っている。個人的にPixel買っている理由は、Androidのアップデートが長期的に行われそうなところ、aシリーズであれば手頃な値段に落ち着いていることと、万一画面が割れたとしても、iCrackedで当日持ち帰りの修理が可能なところ (Googleでの修理扱いになる) なだけで、これを満たしているのであればどれでもいいんだが

Panasonic 食器洗い乾燥機 SOLOTA NP-TML1

5月に購入。食洗機があると生活が変わるという記事を見たりするのだけど、ふと買ってしまった。確かに便利だし、寝る前に洗い忘れて、朝マグカップを洗うなんてことは日常だったので、生活はより楽にはなった。ただこの食洗機のレビューにいつも書いてあることだけど、これが受け入れられるかどうかで評価が変わる

洗浄、乾燥で合計2時間かかる
大きさが用途に合わないと、使い物にならない

ただ台数は売れないだろうから、ずっと同じものを5年以上売るんだろうね (Panasonicのロボット掃除機みたく)

象印オーブンレンジ EVERINO ES-GW26

10月に購入。元々持っていたオーブンレンジ (三菱電機製) は20年以上使っていたしまったく壊れる気配がなかったのだが、新しいものが欲しくなって購入。今どきの電子レンジってこんなに機能豊富なんだなと改めて感動。スチームオーブンと迷ったけど、十分満足

デロンギコーヒーグラインダー KG79J

12月に購入。コーヒー自体はドルチェグストを使っているのだけど、種類に飽きてきてコーヒー豆を買ってきたくなったのでミルを購入。価格も手頃だし、機能自体は挽く粗さを選べたり満足なのだが掃除が超面倒。メンテンス性が悪いという評判は見てたのだけど、これがね...

RISC-VにおけるCrypto命令 (Crypto Extension)

2025-01-07T02:00:00.028+09:00

やっとこさVector Extensionも1.0になり、そろそろいろんなExtensionを実装したSoCも出てくるとは思うけど、年末の移動時間のなかでいろいろ現在のCrypto Extensionを勉強してた

Crypto ExtensioもScalar命令版とVector命令版の２つがあって、Scalar版は組み込みとか用途向けの、レジスタとかを増やしたくない実装用で、Vectorはその名の通りVectorレジスタを使ったもの。試しにAESのEncryptionを実装してみる

Scalar版

Scalar版は以下のようになる。

void
riscv64zkn_aes_encrypt_block_128(uint64_t* expandedKey,
                                 uint8_t *output,
                                 const uint8_t *input)
{
  uint64_t state0 = *((uint64_t *)input);
  uint64_t state1 = *((uint64_t *)(input + 8));

  // Add round key 0 to initial state
  state0 = state0 ^ *expandedKey++;
  state1 = state1 ^ *expandedKey++;

  for (int i = 1; i < 10; r++) {
    uint64_t c0 = __riscv_aes64esm(state0, state1);
    uint64_t c1 = __riscv_aes64esm(state1, state0);
    state0 = c0 ^ *expandedKey++;
    state1 = c1 ^ *expandedKey++;
  }

  // Final round
  uint64_t c0 = __riscv_aes64es(state0, state1);
  uint64_t c1 = __riscv_aes64es(state1, state0);
  state0 = c0 ^ *expandedKey++;
  state1 = c1 ^ *expandedKey;

  *((uint64_t *)output) = state0;
  *((uint64_t *)(output + 8)) = state1;
}

Vector版

Vector版。まだVector Crypto ExtensionのIntrinics命令はStableじゃないので、インラインアセンブラ使ってる。

static vuint32m4_t
vaesz_vs(vuint32m4_t rd, vuint32m4_t vs2)
{
  __asm__("vaesz.vs %0, %1" : "+vr"(rd) : "vr"(vs2));
  return rd;
}

static vuint32m4_t
vaesem_vs(vuint32m4_t rd, vuint32m4_t vs2)
{
  __asm__("vaesem.vs %0, %1" : "+vr"(rd) : "vr"(vs2));
  return rd;
}

static vuint32m4_t
vaesef_vs(vuint32m4_t rd, vuint32m4_t vs2)
{
  __asm__("vaesef.vs %0, %1" : "+vr"(rd) : "vr"(vs2));
  return rd;
}

SECStatus
riscv64zvkn_aes_encrypt_block_128(uint32_t* expandedKey,
                                  uint8_t *output,
                                  const uint8_t *input)
{
  size_t vl = __riscv_vsetvl_e32m4(4);
  vuint32m4_t state = __riscv_vle32_v_u32m4((const uint32_t *)input, vl);

  // Add round key 0 to initial state
  vuint32m4_t K = __riscv_vle32_v_u32m4(expandedKey, vl);
  expandedKey += 4;
  state = vaesz_vs(state, K);

  for (int i = 1; i < 10; r++) {
    K = __riscv_vle32_v_u32m4(expandedKey, vl);
    expandedKey += 4;
    state = vaesem_vs(state, K);
  }

  // Final round
  K = __riscv_vle32_v_u32m4(expandedKey, vl);
  state = vaesef_vs(state, K);
  __riscv_vse32_v_u32m4((uint32_t *)output, state, vl);
}

Conclusion

RISC-Vの場合Load/Restoreをまとめないとvlenの長さを指定するvsetvliが大量に利用することになるので、速さに直結するかもということと、コンパイラ (gcc、LLVM) の最適化もまだまだっぽい
両方ともx86のAES-NIに似た感じなので、AES-NIの経験値があれば、難しくないかも

So-net 光 with フレッツS から別会社の光コラボ回線への転用が地雷すぎる

2024-09-27T16:02:00.008+09:00

自分のオープンソースへのコントリビューションする際のメアドのドメインはずっとso-net.ne.jpなのだが (もちろん別にドメイン持ってるし、それを使ったメアドもある) 、いろいろ思うこともあり、自宅の回線をSo-netではない回線に変えることにした

そもそもフレッツ使っているのは2020年ころまでADSL使ってのもあって、NTTから工事手数料無料でフレッツ光に切り替えるキャンペーンを使ったからってのが一番の理由なのだが

当然のことながらPPoEだと遅いときがたまにあるので、IPoEオプションを使っているのだが、別の光コラボ回線に切り替えるにあたって、解約する必要があるようなので、先にSo-net側のIPv6オプションをWeb上で解約した (はずだった)

解約したのに関わらず、解約申込み中のままになっており、数日待てど一切ステータスが変化しない

おそらく月末処理にしているか、間違えて解約する人向けに数日待つ仕様にしているのだろうが、こっちとしては、光コラボ回線への切り替えの日付が決まっているので、即時解約されないと困る

そのため、サポートに問い合わせると、初めの担当者は「転用の日にコース変更とIPv6オプションの解約をWebからすれば問題ない」と回答してきたのだが、どうも転用という作業がどういうことがたぶんわかってないようだ

いろんな情報を集めると、転用元のIPoEが解約されていないと転用先でIPoEが使えないため、下手すると転用の契約自体がキャンセルされるなりして、両方つかえなくなることも起きるらしい

安全に行くなら切り替えの前の日にはIPoEが解約されていたほうがいい感じなので、もう一度サポートに問い合わせた

サポートに「いつ解約になるのかを教えて欲しい。転用が控えているのですぐ解約できないと困る」と伝えたところ、サポート経由だと即時解約が可能らしく、その担当者経由で即時解約してもらった

Webページでのオプション変更では解決できず、サポートにチャットをしないと (So-netは電話サポートは別契約が必要)、解決しないだなんて、地雷だよな

なお、Googleで検索した際に表示されるこれもウソ。こっちは1週間待ったけど、解約申込み中にままだった

2024/9/28追記

1日経って、転用当日 (というよりも転用先の工事予定時間すぎ) に接続を見てみたところ、転用先のIPoEでつながっておらず、従来のフレッツのままということが判明

以前説明してもらったようにIPoEが未だに使えているという状態 = 転用に失敗しているということで、しょうがなくSo-netにまたチャットサポートを投げてみたところ、「エラーが発生してて、解約処理ができてない」ということがやっとわかった

サポートの人に苦言するのは申し訳ないけれど、ちゃんとした社内の技術担当がフレッツ側にチケット投げて作業すればいいはずの話のようにしか聞こえないのに、サポートの人はうちではいつできるのかわからないの一点張りでこの問題の解決する道筋がでないので、積んだ状態。ホント困った。このせいで来月も料金発生するのかと思うと、So-netはISPとしてひどい有様になったんんだなぁと残念な気持ちになった。はぁ

あと別会社の光コラボ回線への転用は、その転用元にとってはユーザーが逃げるということでもあり、そういうところのサポートを対応したくないという気持ちはわかるのだが、出てくるサポートの人が不正確な情報をユーザーに説明するのはどうかと思う

最初の人は切り替わってからコース変更で問題ない (v6オプションのことは触れない) と言っていたり、切り替えにあたってFAQなりWebのセルフサポートで済むようにすれば、ユーザー側は無駄なコストをかけなくてすむし、サポートへの問い合わせというコストを払う必要もないわけだ

So-netはNuro光で良い話を聞かないけど、なるほどなーと思える対応でした。まだ終わってないけどな

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

2024-08-01T16:20:00.004+09:00

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対応すれば、みんなハッピーだったのでは?やっとサードパーティ製品で対応が増えてきたところだしさ

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

2023-05-11T17:41:00.004+09:00

これの続き

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が出てから考えよう

MacBook Air (2020) M1のUSB-Cポートが壊れたのでApple Storeで交換 (修理) した

2023-04-22T08:24:00.003+09:00

最近、ビデオ会議のときはMacBook Airを使っている。理由は自宅で使っているDebian/sidな環境でスピーカーフォンが使えたり使えなかったりと不安定だからなのだが (これはpipewireに変わってから頻発してるので、どうにか原因は突き止めたいと思っている)、ミーティングの時間にMacBook Airを使おうとしたら、電源が入らなくなっている。USB-Cポートが一つ壊れていたのだが、こっちのポートも壊れたか、マザーボード自体壊れたっぽい。新しいものを買うという選択肢もあるのだけど、すぐ直ったらラッキーなので、Apple Storeに修理の予約を入れた。

Apple Storeで現象の説明 (電源が入らない) を説明した後、USB-Cポートも一つ壊れているので、両方壊れているのかもしれないという話をしたところ、一回中身見ますね、ってことで自分のMacBook Airをバックヤードに持っていって、分解して調査をしてもらった。

その後、すぐ戻ってきて、

壊れたUSB-Cポートは、どうもゴムらしきものが挟まっていて、それが原因っぽい
今まで使えてたUSB-Cポートは洗浄してみてどうなるかを調べる

という話になり、作業した後にチェックすると、今まで使えてたUSB-Cポートはちゃんと動作する (= 充電が開始され、電源が入る) ようになり、もう一つの前から壊れてたポートは、動かなかったり動いたりと不安定な状態だった。「このままでもいいですけど、ボード交換という修理も可能です。交換の場合は15000円強になります」という説明を受けて、それだったら修理にするということで修理に出した。値段の大部分は作業料で、実際のボード部分は2000円らしい

修理に出したのが夕方で翌日の夕方には修理完了ということで、Apple Storeでピックアップ可能になってた。一日でピックアップできるのは非常に満足だった。昔東芝が秋葉原のサービスセンター持ってた時に、運が良くてすぐピックアップ可能だったのだけど、販売元が修理の際にちゃんと説明してくれるのは非常に満足度高いよねと

How to build Firefox for Linux/riscv64 on Ubuntu 22.10 + Unmatched

2023-03-24T12:32:00.012+09:00

A people asks me about how to build Firefox/riscv64. Since all patches to build it are merged, so the instruction is updated from previous. The following instruction is on Ubuntu 22.10 on riscv64gc

Clone firefox code from mozilla official repository
- hg clone https://hg.mozilla.org/mozilla-central (Mercurial)
- git clone https://github.com/mozilla/gecko-dev (git).
Change current directory to cloned directory
- cd mozilla-central (if using mercurial)
- cd gecko-dev (if using git)

Create mozconfig file in current dicrectory. File content is the following

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir
mk_add_options AUTOCLOBBER=1

ac_add_options --enable-application=browser
ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --disable-tests
ac_add_options --without-wasm-sandboxed-libraries

Install rust. See rustup.rs
Install clang and nodejs
- sudo apt install clang nodejs
Run ./mach bootstrap and select "2. Firefox for Desktop"
Run ./mach configure
Run ./mach build. It spends 8-9 hours.

Enjoy!

Google Mobile ServiceのFIDOパッケージを使うと勝手にPasskey対応になる

2023-03-22T10:47:00.008+09:00

Google Mobile Service (GMS) にFIDOのパッケージがあるんだが、今年リリースされたVersion 19でWebAuthnにおけるDiscoverable Credentials (Resident key)の対応ができるAPIが追加されている。

Blinkを使っていないとあるWeb BrowserのAndroid版におけるWebAuthn対応はこのGMSのパッケージを使っているおかげで、Resident keyの対応をしていなかったのだが、このパッケージのバージョンにアップデートすれば解決するかも？と考えて、手元で修正コードを書いてみたんだけど、以下のように表示されて勝手にPasskey対応になるっぽい。

上記のように勝手にPasskey対応になってしまい、しかもGoogleアカウント内に同期されちゃうから、とあるWeb Browserの事情だと実装するには、いろんな人たちの許可取らないといけないので、Resident key対応は一時中断することにした。個人的にはPasskeyを使うかどうかのオプションが欲しいのだけどないっぽいし、あの検索会社自体の都合でそれをつけてくれるのはないだろうな、しかもこのパッケージ、GMSだし。

Pixel 6aの画面が割れたのでiCrackedで修理した

2023-03-16T13:37:00.001+09:00

仕事でスマホOSの開発、デバイスリリースもやったし、今もスマホOS向けのWebブラウザ作ってる仕事をしてるわけだが、なんでもスマホに取り込むということはなおさら信用できない。今回旅先でPixel 6aを落として画面を割ったときも、ガラス面が割れるだけだと良かったのだけど、パネルごと割れてしまって、画面が映らなくなった。そんな状態になったら、画面を確認することはできないわけだから、飛行機のチケットとか (QRコード)、電子マネーのチャージとかもできないわけで。そもそも落とす自分が悪いわけだけど、スマホにすべて取り込むというのは正直ないなと改めて思う。

そんな話はさておき、自分が所有しているアメリカン・エクスプレスではスマホの盗難・故障に対する保証制度 (スマートフォン・プロテクション) というものがあり、修理金額の一部を補填してくれるので、それを行った。そのときのお話。

まず、この保証制度を申し込むためには、以下のものが必要になる

そのスマートフォンを買った際の領収書。Pixelの場合はGoogleから買った際に送られてくるメールで問題なし
故障を証明する写真。今回は画面が割れている本体の画像
修理内容、代金を証明する書類。今回の場合はiCrackedで修理を行ったので、その作業が書かれた書類。修理されたときに渡される

今回の修理はiCrackedで行った。ここはGoogleの正規サービスプロバイダなので、ここで修理しても本体保証は変わらないらしい。店舗自体が都内にはいくつもあるのでネットで申し込んで空いていれば当日に修理を行ってもらえる。修理時間も1時間もかからないので、郵送よりも実店舗に直接行くのが便利だと思う。

なお、AMEXのスマートフォン・プロテクション、申込みから実質2営業日くらいでお金が振り込まれるので、非常に便利でした。でもGoogleはUSでやっているPreferred Careを日本で展開できないのはなんでだろう。売れてないんだろうな

Oliveに移行しようとしたら、利用可能な口座がありませんと言われる

2023-03-07T19:33:00.006+09:00

親への生活費とか家賃の振り込みを毎月行う必要があり、銀行自体も各々で違うので振り込み手数料をできる限り安くする方法をいろいろとっていたのだが、三井住友銀行 (SMBC) でOliveというサービスが始まり、手数料を下げられそうだったので、移行することにした。

アプリをインストールして、SMBC IDというアカウントを作り、早速口座を移行しようとしたら、"Oliveアカウントに切替可能な口座がありません" というエラーが起きた。Oliveアカウントの切替診断から辿れるFAQを見ても、不可能条件に合致しておらず、SMBC Directから口座の種類を見ても "残高別金利型普通預金" なので、全く理由がわからない。しいてあげれば、この口座はさくら銀行時代に作ったものをずっと使っている。キャッシュカードもSMBCに変更してるし、なにか内部で変な契約になっているしか思えない。

悩んでも仕方ないので、SMBCのチャットサポートで問い合わせようにしても、混雑してて問い合わせできないので、SMBC Direct経由でメールで問い合わせた。

一日後、返事があり、どうも自分の口座は「カードローン（総合口座型）」というものなっているらしく (検索してもほぼ情報が存在しない)、カードローン口座の契約を止めればOliveへの切替可能とのことで家の近くの支店でカードローン口座を止めてきた。銀行の受付で説明しても「？？？」な顔をされたので、これに合致する人はすくないのではと思う。

なんで、こんな契約になってかをいろいろ思い出してみると、心当たりがあって、口座を作った時に「給料振り込み口座にしていただければ、10万円まで口座残高がマイナスになっても可能」というようなものを契約した覚えがたしかにあり (あの頃は新卒社会人でいろいろ借金あった)、それが銀行が変わってくにつれ、最終的に「カードローン（総合口座型）」という契約になったんだろうと推測される。ただ、SMBC Directやアプリで見ても "残高別金利型普通預金" としか表示されないので、わかるはずないよねと。

利用可能な口座がありませんと言われる人は、SMBC Directのメール問い合わせで聞くといいと思う。結果として実店舗行くことになると思うけど

なお補足だが、銀行に問い合わせた時、切替不可能な条件に以下があったのは笑った。そりゃそうか。

* 口座名義に銀行のシステム上反映することのできない漢字が含まれる場合

2022年に買ったもの

2023-01-06T22:16:00.002+09:00

今年は書く内容のあるものを買ってないなぁと思いながら。

clockwork DevTerm R1

ここにすでに書いてあるが、補足。

キーボードがしょぼくて、ゆっくりじゃないと入力がほぼ不可能。結果としてUSBキーボード差さないと使い物にならない。
ローエンドの阿里巴巴のチップ、GPUがまともに入ってないので、表示に関してはただ表示できるレベルの遅さ

初めてRISC-V64デバイス買うのであればいいけど、SiFiveのボード持ってるから、まぁ触らなくなっちゃった

Logicool LIFT

MX Verticalユーザーだったのだけど、トラッキングが調子悪くなってきて (今までのLogicool製品では経験なかった)、買い替えるデバイスをどれにしようか考えてるときに発売になったので。サイズ感はこっちのほうが好みなので、買ってよかった。

Google Pixel 6a

前まで使ってたPixel 4aの画面を割ってしまったので。Pixel 4aのAndroidのバージョンも13で打ち止めだし、14へ向けてのデバイスが欲しかったので購入。充電時とかに無駄に熱くなるとかちょっと重いとか、Pixel 4aに比べると出来がいいとは思わなないけど、しょうがないよね。

なお、画面を割ったPixel 4aは、東急ハンズに入ってる iCracked (Googleの正規修理業者) に持ち込んで画面を交換してもらいました。1時間30分くらいで交換終了して約2万円ほど。壊してもいい検証機に格下げ。

Firefox for macOS版をLinux上でビルドする

2022-12-06T15:30:00.001+09:00

自分用メモ

Firefoxのビルド環境はカスタムビルドされたclangを使っているため、Linux上でmacOS版のビルドができたりする。実際AWS/GCP上のTaskCluster (MozillaのCI) ではmacOS版はLinuxでクロスビルドしてる。問題はSDKのヘッダとかなんだが、まぁここらからもってくるなり別のmacOS環境からSDKのヘッダ・ライブラリ一式を持ってこればどうにかなる。

mozconfigファイルはこんな感じでいけるはず

mk_add_options MACOS_SDK_DIR=/other/MacOS-SDKs/MacOSX11.3.sdk
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-macos

ac_add_options --target=x86_64-apple-darwin
ac_add_options --enable-debug
ac_add_options --enable-optimize
ac_add_options --enable-tests
ac_add_options --with-macos-sdk=/other/MacOS-SDKs/MacOSX11.3.sdk

RISC-VなClockwork DevTermがやってきた

2022-06-02T21:12:00.007+09:00

Clockworkが発売してるDevTermにRISC-V64なボードが追加されてたので買ったところ届きました。

中のパーツは組み立てる必要がある。電源はUSB-C経由だが、18650バッテリー搭載可能。

なお、このボードは阿里巴巴のXuanTie C906コアなAllwinner D1使っているのでこんな感じ。

cpi@devterm-R01:~$ uname -a
Linux devterm-R01 5.4.61 #12 PREEMPT Wed Mar 30 14:44:22 CST 2022 riscv64 riscv64 riscv64 GNU/Linux

cpi@devterm-R01:~$ cat /proc/cpuinfo
processor	: 0
hart		: 0
isa		: rv64imafdcvu
mmu		: sv39

だそうです。Vecter Extension!

同梱のSDカードにUbuntu 22.04ベースの起動イメージが入っているのだが、これはhttp://dl.clockworkpi.com/からダウンロード可能。なお、スクラッチから作る方法も公開されている

なお、参考にUnix Bench

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: devterm-R01: GNU/Linux
   OS: GNU/Linux -- 5.4.61 -- #12 PREEMPT Wed Mar 30 14:44:22 CST 2022
   Machine: riscv64 (riscv64)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   16:18:46 up 3 min,  2 users,  load average: 0.92, 1.11, 0.53; runlevel 2022-06-02

------------------------------------------------------------------------
Benchmark Run: Fri Jun 03 2022 16:18:46 - 16:46:57
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables        2958013.9 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     1045.0 MWIPS (9.9 s, 7 samples)
Execl Throughput                                254.0 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks         44255.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           12537.2 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        116663.8 KBps  (30.0 s, 2 samples)
Pipe Throughput                              163270.2 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  26226.4 lps   (10.0 s, 7 samples)
Process Creation                                696.3 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                    567.4 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                     73.9 lpm   (60.5 s, 2 samples)
System Call Overhead                         383377.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    2958013.9    253.5
Double-Precision Whetstone                       55.0       1045.0    190.0
Execl Throughput                                 43.0        254.0     59.1
File Copy 1024 bufsize 2000 maxblocks          3960.0      44255.0    111.8
File Copy 256 bufsize 500 maxblocks            1655.0      12537.2     75.8
File Copy 4096 bufsize 8000 maxblocks          5800.0     116663.8    201.1
Pipe Throughput                               12440.0     163270.2    131.2
Pipe-based Context Switching                   4000.0      26226.4     65.6
Process Creation                                126.0        696.3     55.3
Shell Scripts (1 concurrent)                     42.4        567.4    133.8
Shell Scripts (8 concurrent)                      6.0         73.9    123.1
System Call Overhead                          15000.0     383377.8    255.6
                                                                   ========
System Benchmarks Index Score                                         120.8

Intl.MessageFormat

2022-05-24T20:42:00.002+09:00

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でも使えるので、自社で同じような機能の車輪の再発明を行っているのであれば、ここでいろいろ意見を言えば取り込まれると思うよ

2021年に買ったもの

2021-12-31T11:12:00.032+09:00

Google Pixel 4a

XPERIA XZ2 Compactを使っていたのだが、3度目の修理になったタイミングでメイン端末の代わりとして購入。XPERIA XZシリーズはほんと出来が悪かったし、ドコモ経由で買ってたので、修理代が非常に安く、あれでは元を取れてないのではと思うものだった。

Googleはこのくらいのミッドレンジの端末が一番コスパいいと思うので続けてほしいと思う。そもそも昔のNexusのときと違ってAOSPそのままではなくなってるし、どれがリファレンスなんだかわからなくなってはいるが。

HiFive Unmatched

2020年にオーダーしたものだったけど、5月くらいに到着。Mini-ITXなケースと電源、AMDのPCIeなGPUを用意すると、普通にLinuxが実用速度でボートするRISC-Vボードなので、いろんなコードを試しにポートしてみた。今年くらいにリリースされるようなSoCだと今度はSIMDとかCrypto Extensionとか実装されてそうし、新しいSoCが入ったボードが出たら買うだろうな。

TP-Link 5ポート 2.5Gbps ハブアンマネージスイッチングハブ TL-SG105-M2

コスパはいいTP-Linkが最安クラスの2.5Gbpsハブを発売したので、早速購入。結構熱は持つけど、速度としては安定してる。そういえば、自分が100Mbpsなハブを買ったのもこのくらいの値段になったころだったなぁと思い出した。

SwitchBotスマート加湿器

部屋が乾燥してて朝起きると喉の調子がわるいので、購入。加湿器を買うんだったらくだらないものを買おうと思い、SwitchBotにした。はっきりいうと加湿器なんてずっとつけっぱなしだし、タンクの水がなくなっているという情報をスマホで見ても、だから？って感じなので、スマホとかからコントロールするような機能は改めていらないなと。

ネスカフェドルチェグスト MINI ME

家でコーヒーの飲む時は一杯毎ドリップして飲んでいたのだけど、面倒になって、コストコでMINI MEを購入。自分のような面倒くさがりな人にとってはこういうカプセルのものが理にかなってた。

山善エアフライヤー YAF-C120

普通の電気フライヤーは持ってはいるのだけど、油の処理がもったいない気がしてて、エアフライヤーで代替できないかと思って購入。はっきりいうと中途半端過ぎて、代替にならなかった。200℃だと微妙に温度が足りない感。たしかにフライドポテトとかは簡単にできるのだけど、その程度かなぁ。今後も使い続けるかは微妙。

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

2021-11-30T10:19:00.005+09:00

バグレポートを受け取って気づいたのだけど、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をちゃんとやらない製品はバグ修正とかにコストかけない (または評価システム上、評価されない) だろうなぁと勝手に思ってる。

いまさらながらAndroidのAutofill Frameworkの困った話

2021-10-08T23:37:00.004+09:00

AndroidのAutofillというのは、カスタムコントロールを使わないアプリにとっては実装は難しくはないのだが、カスタムビューを実装しているアプリでは、自分でいろいろな情報を提供しないといけない。実際には、自動入力用にアプリを最適化するに書かれているように、システムがAutofill用の情報を要求してきたら提供する、フォーカスの状態をシステムに通知するなどを追加実装する必要がある。

全部のアプリケーションでそのような実装しているとは限らないので、実装していないような昔のアプリケーション用にAndroidはおせっかいな機能を追加している。互換モードだ。これはアクセシビリティの実装を用いたautofillのエミュレーションを提供するもので、カスタムビューがアクセシビリティ機能の実装をしている場合は、それを利用してAutofill情報を設定する。そもそもアクセシビリティの実装しててAutofillの実装しないアプリがあるのかと問い詰めたいところではあるが。

この互換モードというのは自動的に切り替わるわけではなくて、Autofillサービス側で事前に設定をする。だから例えばアプリがAutofillの実装を入れたとしても、アプリ側からこの互換モードを無効にする方法は残念ながらない。この互換モードが動作してしまうと、アクセシビリティノードの走査が走ってしまうため、当然ながらパフォーマンス問題を引き起こす。アクセシビリティノードの走査はandroid.view.Viewの実装内で行われているから、該当コードを実行しないようにすれば、アクセシビリティノードの走査が実行されなくなるので、ある程度は回避可能ではある。残念ながらある程度ね。

この互換モードで実行しているかどうかは、こんな感じで調べられると思う。

public boolean isCompatibilityMode(Context context) {
  try {
    final AccessibilityManager manager =
      (AccessibilityManager) context.getSystemService(
                               Context.ACCESSIBILITY_SERVICE);
    if (manager == null) {
      return false;
    }
    final List<AccessibilityServiceInfo> serviceInfoList =
      manager.getEnabledAccessibilityServiceList(0);
    if (serviceInfoList == null) {
      return false;
    }
    for (final AccessibilityServiceInfo info : serviceInfoList) {
      if (info.getId().equals(
        "android/com.android.server.autofill.AutofillCompatAccessibilityService"
      )) {
        return true;
      }
    }
  } catch (final Exception e) {
  }
  return false;
}

アクセシビリティノードを走査させないようにしたとしても、互換モードは引き続きおせっかいなコードを実行する。この互換モードが動作する際には、CompatibilityBridgeと呼ばれるものがアクセシビリティイベントをウォッチするようになる (これについては無効にする方法はない)。そのためアクセシビリティイベントを発火させるとそれに応じて勝手にAutofillの互換コードが実行されてしまう。例えばAccessibilityEvent.TYPE_VIEW_FOCUSEDのイベントを受け取ると、AutofillManager.notifyViewEnteredを呼び指したりする。そのため内部でAutofillフォーカスがアクセシビリティノード上に移動する。たとえアプリケーションがAutofill情報を提供してたとしてもだ。AndroidのAutofillはフォーカスが移った際にAutofill用のリクエストをAutofillサービスに渡すので、互換モードでかつ、もしアプリがAutofillの実装をしてた場合、2度リクエストが飛ぶという困ったことになってる。

今どきのWebブラウザというにはOSのAPIはUI Processで実行される。Webコンテンツ内のアクセシビリティ情報をコンテンツのロード時にContent Processで集められ、集まった後UI Processへ送られる。アクセシビリティ情報の収集というのは非常に重い処理なので、UI Processへ送られるのは、ブラウザにとっては相当後になる。なので下手をするとAutofillフォーカスが予期もしてないアクセシビリティノードに奪われた状態でAutofillサービスがAutofillのUIを出したりしようとするので、ブラウザにとっては予期しない動作になりがちになる。例えば、Bug 1693152とかBug 1715549とか。

このように残念な互換モードを使っているAutofillサービスで有名なのはBitwarden。昔Bitwardenの開発者になんで互換モードに設定しているの？って聞いたけどよくわからない答えを返してきたので、今度こそどうにか止めさせるつもり。このような問題に引っかかるのはたぶん自分だけだと思いたいし、Androidはこの互換モードをアプリ側から止める方法を提供してほしかった。

なお、Bitwardenを使ってて、たまにChromeとかでもAutofillが動かないという話があれば、おそらくこのパターンの話。