Scribble at 2021-09-24 09:52:22 Last modified: 2021-09-27 08:20:00

ここでは何度も紹介している Firefox 用の（旧世代の）アドオンである Scrapbook (1.5.9.1-signed.1-signed, 2019-07-07) だが、このところページの保存スピードが速くなった。もちろん２年くらい前に開発は止まっているため、アドオンのコードが改善されたというよりも、Waterfox Classic のパフォーマンスが現在も改善されているということなのか、あるいは Scrapbook のページ保存処理でネックになっていた何らかの通信をカットするようになったかのどちらかだろう。この後者の理由は、たとえば Waterfox がディフォールトでサード・パーティのリソースや、CDN でホストされている外部ファイルとしての CSS や JavaScript をアドオンからアクセスできないようにしたのかもしれない。もちろん、それらへのアクセスについて明白に遮断するなら、タイムアウトまで待機するなんて無意味だから、即座にリクエストが破棄される。そして、アクセスを許可されたものだけにアクセスするというわけである。実際のところは、原因がよくわからない。もちろん、後者のように、これまでページの保存に時間がかかっていた理由の一つである、外部リソースへのアクセスが本当に遮断されているかどうか、Firefox のインスペクタ（いわゆる「開発者ツール」）に含まれる「ネットワーク」のモニタリング機能で確認できればいいのだが、アドオンの通信はこれでモニタリングできないのである。よって、あくまでも推測でしかない。根拠として、保存したページをローカルで表示すると、ページのレイアウトが崩れてしまっているからだ。つまり CSS を保存できていない。一例として、The New York Times のトップページは、かなり容量として大きいとは思うのだが、いまでは Scrapbook で即座に保存できてしまう。これまでなら数十秒は保存にかかっていたのだから、これはこれでありがたいのだけれど、ローカルでページを表示してみると崩れてしまっている。そして、このページのスタイルシートは、大半が nyt.com という別ドメインにあるため、無視されている可能性がある。

CDN を使ってもいいし、もちろん自社で運用している別の FQDN のホスト・マシンからコンテンツを読み込んだって構わないのは確かだ。よって、必ずしもクロス・ドメインのアクセスが何でも無条件に遮断するべきアクセスというわけではないのだし、もし Waterfox の通信ルールがこういう方針でむやみに厳しくなったのであれば、これはこれで是非を議論したほうがいいのかもしれない。ただ、クロス・ドメインのファイルが読み込まれないていどのことで、コンテンツとして UA 側にレスポンスするべきデータを必要最小限でも送り返せないというページは、それはそれで「嘘つき」の一種であるとは言える。なので、Waterfox の通信ルールが本当に変更されたとしても、これまた一概に非難するものでもあるまい。正直、僕も昨今の〈React バカ〉というか、JavaScript でコンテンツをロードして表示する（そして、その JavaScript はマーケティングやアド・ネットワークのサーバからしかリダイレクトされない）という、不誠実としか言いようがないコンテンツ配信方法を採用している連中の提供するコンテンツなど、可能な限り僕の人生で求める情報のソースとしては排除したい。だが、必要な情報に限ってバカが配信しているということも、凡俗の世の中ではありえる話だ。バカがものを書いて、クズどもがウェブ・コンテンツとして提供していても、僕にとって必要な情報というものがある。これは仕方のないことだ。