2020-02-18

Rakuten miniを手に入れた

最近手に入れたいと思う端末がまったくなかったのだが (開発用で仕方なしに手に入れることはある)、久々に地雷感のするものが現れた、楽天モバイル。無料サポーターに当選したため、ついでにRakuten miniも手に入れてきた

Rakuten miniの契約だけは実店舗に行かないといけないようなので (おそらくeSIMのみの端末のため、設定も含めて面倒みるからだとは思う)、仕方なく実店舗への予約をする羽目に。この予約をWeb経由でしようとしたが平日の昼間しか空きがなかったが、ネットの情報を見る限り、直接店舗に行けば (待ち時間があれど)、予約できるようなので、恵比寿の楽天モバイルまで行くことにした (いつも通うジムの通り道にあったのだけど、いつ出来たの?)

店舗での契約も実に効率よくできてて、
  • 予約をしてなくても店舗の端末で電話番号の登録すれば問題ない。契約可能になれば電話 (またはメールなど) で教えてくれる
  • 通知の際の電話は、自動音声。オペレーターを排除してる
  • Surface端末でいろいろ店員が入力して、自動車運転免許証の写真をとるだけで基本的な契約は終了
  • 楽天IDと紐づくので、楽天IDでいろんな処理を簡素化

特にドコモのような従来の店舗だと、店舗で待たないといけない状況だったりするので (今は変わってるかのかもしれないが)、こういうところは楽天に好感を持った。他社も楽天のように受付だけは店舗の外で待てるような仕組みがほしい (ネットだとできないことをするために仕方なしに行くと本当につらい)。ドコモショップとかはドコモ直営じゃないところがほとんどだから致し方ないけどね。

なお、いいことばかりでもなくて、残念なところは楽天IDと紐づくためにパスワードを入れないといけないところ。自分の場合は楽天IDのパスワードがランダム生成された非常に長い英数字記号を含むものだったこと。まぁ入力つらい。特にRakuten MiniのサイズでしかもiWnnで入力しないといけない (記号入力ほぼ不可)。GBoardも入ってたので、それに切り替えて事なきを得た。

このRakuten Mini、GPUがAdreno 505なので、Firefox Preview NightlyだとWebRenderがデフォルト有効 (Bug 1602597) なので、実験端末として有望でした。

2020-01-23

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はプライバシー問題が解決されないものは基本実装されない感じ)

2019-06-27

New Firefox Preview for Android

自分はちょうど半年前くらいにGeckoView Team (要はAndroid用のGeckoを作るチーム) に移籍してる。Input Systemとかがメインで (Windows + macOS + Linux は自分と中野さんがやってるのでAndroidがそれに加わったようなもの)、それ以外もいろいろバグ対応とかしてる。

GeckoViewってのはモバイルというかAndroid版の戦略変更によってここ2年くらいMozillaが作ってるもので、フロントエンドのUXさえ作ればいろんなバリエーションのブラウザを作りやすくなるという代物。例えばFirefox Focusようなものや、Firefox Reality、Amazon EchoShowでGeckoベースのブラウザを作ったりするなど、いろいろバリエーションが増やせるようになった。

そもそも従来のAndroidに内蔵するWebViewにはいろんな制限があって、簡単に言えば元となってるChromeと同様のWeb APIをサポートしてるわけではない。だからWebViewを使ったブラウザというのはそのバージョンのChromeと同等ではない。(もし同等なものができるのであれば、ChromeがWebView使ってると思う)。GeckoViewはそうではなくて、Geckoで実現可能なものはすべて使えるようにAPIをいろいろ追加してる

超簡単なブラウザを作るのであれば、mozilla-centralのツリーに入ってるGeckoView Exampleのがサンプルになる。見てみればわかるけど、簡単なものを作るだけであれば、非常に少ないコードでブラウザをつくることができる。またこれだとヒストリ機能とか足りないので、Android Components (a-c)というものを使うことでブラウザをより現代のブラウザらしくつくることができる。なおa-cはGeckoViewじゃなくてもServoとかシステムWebViewとかに対しても動作するようになってる。

ということで従来のFirefox for Android (Fennec)はGeckoViewを使ってるわけでなかったのだけど、このGeckoView版といえるFirefoxがFenixと呼ばれてた、このFirefox Previewになる。

GeckoViewになって一番うれしいことは、やっとマルチプロセスであるということ (今後FissionとかWebRenderもあるので、プロセス数は増えると思う)。そのおかげでパフォーマンスはよくなってるはず。Firefox 68からでもあるけど、aarch64への標準対応もかな?

なお、従来のFennecは68で最後になる。ESRブランチに移行するので、セキュリティ修正等は当分行われる (今のところいつまでは決まってない)。

このFirefox Previewはまだ開発版なので、Tracking ProtectionとかPWAとかWeb Extentionのサポートが欠けてるけど、これは正式版までにははいるはず。要望やバグ報告は、Bugzillaではなくて、githubへ。日本語じゃないと無理であれば、Mozillazine.jpのフォーラムへ投稿してください。見ておきます。