Web ツールに何かを入力すると、その中身はツールのサーバーに送られることが多い。文字化けした CSV を直すサイトにファイルを上げれば、ファイルはそのサイトのサーバーに届く。メールのヘッダを解析するサイトに貼り付ければ、宛先のアドレスも社内のサーバー名も一緒に届く。サーバーの側で「保存しません」と書いてあっても、利用者にそれを確かめる手段はない。
おたすけで公開しているツールは、入力をなるべくサーバーに送らないように作っている。そう書くのは簡単だが、ブラウザの中だけでできることには限りがある。この連載では、九つのツールがブラウザの中で何をしているのか、どこでその限りにぶつかったのかを、一つずつ書いていく。
ブラウザの中で処理するということ
Web ページは、サーバーから HTML と JavaScript のファイルを受け取り、ブラウザがそれを実行することで動く。ファイルを受け取ったあとの計算は、利用者の端末の上で行われる。入力したものをサーバーに送り返すかどうかは、その JavaScript の書き方次第である。
つまり、処理をすべて JavaScript に書いてページと一緒に配れば、入力はサーバーに届かない。サーバーの仕事は、ファイルを配ることだけになる。
この作り方には、運営する側の都合もある。おたすけのツールは Cloudflare Workers で公開していて、静的なファイルの配信は無料で回数の制限もない(Cloudflare の説明)。サーバーでプログラムを動かすと、無料の枠を使い、利用が増えれば費用がかかる。入力を受け取らない作りは、利用者にとっても運営にとっても軽い。
九つのツールは、それぞれどこに何を送っているか
とはいえ、全部のツールがサーバーに何も送らずに済んだわけではない。入力がどこへ届くかは、ツールごとに違う。
- メールヘッダ解析、文字化け直しツール、QR コード読み取り・作成、日本語 OCR、PDF 墨消しチェッカー、動画の切り出し・圧縮は、入力をどこにも送らない。これらのサイトには、サーバーで動くプログラムがそもそも置かれていない。
- DMARC チェッカーは、入力したドメイン名をこのツールのサーバーには送らないが、Google と Cloudflare の公開 DNS には送る。DNS を引くこと自体が、診断の中身だからである。
- ドメイン健康診断も、ドメイン名を公開 DNS に送る。加えて、ドメインに MTA-STS の設定があるときに限り、ドメイン名をこのツールのサーバーに送る。MTA-STS のポリシーファイルは、ブラウザからは読めないからである。
- セキュリティヘッダーチェッカーは、入力した URL をこのツールのサーバーに送る。他のサイトの応答ヘッダーは、ブラウザからは読めないからである。
ツール以外の通信もある。どのツールのページも、閲覧の状況を知るために Google アナリティクスと
Cloudflare Web Analytics を使っている。Google アナリティクスに送られるのは、閲覧したページの
URL や端末の種類などである。DMARC
チェッカー、ドメイン健康診断、セキュリティヘッダーチェッカーは、結果を共有できるよう、診断したドメインや
URL をページの URL(?domain= や
?url=)に入れる。そのため、診断の対象が、閲覧したページの URL
の一部として計測に含まれうる。ページの配信にともなって、Cloudflare のアクセスログにも IP
アドレスなどが一時的に記録される。入力の中身を送らないことと、何も通信しないことは別である。
ブラウザの中だけでは足りなかったところ
ブラウザの中で処理すると決めても、ブラウザには、できないように作られていることがいくつもある。
ブラウザの JavaScript は、DNS を直接引けない。DMARC チェッカーは、HTTPS で DNS を問い合わせる DNS over HTTPS を使い、Google と Cloudflare の窓口に頼った。ブラウザは、他のサイトの応答ヘッダーを自由に読ませてくれない。セキュリティヘッダーチェッカーは、そこでサーバーを置くことにした。ドメイン健康診断も、DNS は DMARC チェッカーと同じ方法で引くが、MTA-STS のポリシーファイルは同じ理由でブラウザから読めず、そこだけサーバーを通している。
ブラウザには、QR コードを読む標準の機能が、まだどの環境にもあるわけではない。QR コード読み取りは、C++ で書かれたライブラリを WebAssembly にして持ち込んだ。日本語 OCR はもっと大きく、およそ 150 MB の機械学習モデルをブラウザにダウンロードさせ、端末の CPU で動かしている。PDF 墨消しチェッカーも、PDF の読み書きに Chrome の PDF 表示と同じ PDFium を WebAssembly にして持ち込んだ。
動画の切り出し・圧縮は逆に、動画のエンコーダを持ち込まなかった。動画の符号化には、ブラウザに組み込まれたエンコーダを WebCodecs という API で呼んでいる。そのぶん、どの形式で書き出せるかはブラウザによって変わる。
メールヘッダ解析と文字化け直しツールは、仕組みとしては素直で、文字列やバイト列を読むだけで済む。そのかわり、手がかりの少ない中から「どの行を信じるか」「どの文字コードらしいか」を決めなければならない。
通信が切れても使えるのか
入力を送らないなら、一度ページを開けば通信がなくても使えるはずだ。以前は、そう考えて三つのツールに Service Worker(ページとネットワークのあいだに入って、ページのファイルを端末に保存しておく仕組み)を入れていた。
今はこれをやめている。一度開いたページで作業を続けられればよく、ページ一式を端末に保存しておくのはその目的には大がかりすぎた。やめたあとも、古い版を保存したブラウザが古いページを出し続けないよう、Service Worker を自分で解除させるファイルだけを置いている。今のツールは、ページを開くときにインターネットへの接続が必要である。ページを開いたあとなら通信が切れても処理を続けられるツールはあるが、それは開いているページに限った話で、「オフラインで使える」と言える状態ではない。
送っていないことを確かめるには
冒頭で、「保存しません」と書いてあっても利用者には確かめる手段がない、と書いた。ブラウザの中で処理するツールは、その点が少し違う。ブラウザの開発者ツールを開き、ネットワークの一覧を見ながらツールを使えば、入力の中身がどこかに送られていないかを自分の目で確かめられる。この連載に書いたことも、同じ方法で確かめてもらえる。