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

自分のオープンソースへのコントリビューションする際のメアドのドメインはずっと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) におけるパスキー対応が面倒すぎる

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) 対応

これの続き

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で交換 (修理) した

最近、ビデオ会議のときは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

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

1. 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).
2. Change current directory to cloned directory
   • cd mozilla-central (if using mercurial)
   • cd gecko-dev (if using git)
3. 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

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

Enjoy!