先月 data URI scheme について書きましたが、今日はひょんな事から file URI scheme のお世話になりました。きっかけはこんな事でした。
「場所がわかっているファイルを簡単に開きたいのだが？」
そこで思い出したのが file URL [RFC8089]です。さっそく、ブラウザにファイルの場所（パス名、つまり file URL）をコピペしたらパッと開きました。おっと！なんだこのサクサク感は！これこそ自分が求めていたものですよ。
ウェブブラウザで file URL を使えば、ローカルなフォルダやプレーンテキスト系のファイルを快適にブラウズできます。文字サイズの拡大縮小もブラウザ機能で簡単にできます。ウェブ系とシームレスに「ブックマーク」が管理できる点も素晴らしいです。
Mac の Finder にしろ Windows のエクスプローラにしろ、あのもっさり感にはうんざりしています。それに老眼のため「字が小さくて読めない！」「ポインターが合わせられない！」とか、「ダブルクリックができない！」とか（笑）。フォルダの中身をナマで見たいのに！とか。
ウェブブラウザは、HTTPをはじめとする上位レベルの、個別のアプリケーションプロトコルによる、明示的なリモートサーバへのアクセスを実現しています。一方で、昨今隆盛のネットワークドライブ（仮想ドライブ）に見られるように、下位レベルにおいて、リモートなファイルとローカルなファイルと区別せずにアクセスができる環境も整ってきました。
このように下位レイヤでリソースのビューが一元化が実現されていれば、お目当てのリソースに対して具体的にどのようなプロトコルでアクセスしているかを、エンドユーザが気にする必要ありません。それはまったくのところ、file:///path/name で十分なのです。
当社で開発中の技術の応用においては、リソースへのアクセスを、こちらのエンドポイント（ユーザアプリ）からあちらのエンドポイント（リソース）に至るどこかの地点で捕捉し介入する必要があります。その地点としては、個別アプシケーションプロトコルのどこかのノード、あるいはリモートファイルアクセスプロトコルだと思って来たのですが、いろんな意味でどうもイマイチです。
それで今日思ったのは「やっぱブラウザでいいんじゃね？」ということです。ブラウザでやる、というのは最初に考えることではありますが、ブラウザ以外のアプリからその恩恵にあずかれないというのが難点だと思っていました。ですが今思い出したのは「ブラウザをサーバにすればいいじゃん」ということです。ああ、昔はそんな事を考えていたなと。ブラウザはクライアントとしての機能は完備していますから、これを再び（いろんなプロコトルの）サーバとしてサービスすれば良いわけです。要するに結局、プロキシですね。
ここで考えを戻すと、たとえば sftp://xxx なんてのもブラウザで実装してあれば、プラットフォームでの実装を待つ必要もないわけです。
機能面以外で考えられる問題点はやはり、セキュリティ・プライバシーの問題です。なにしろ、今日のブラウザはプライバシーにアクセスするためのポータルです。これにサーバの口をつけて外部からアクセスされてしまうと、非常に危険だろうなとは感じます。だからそこはガッチリとガードするか、根本的に不能にするかですね。
逆に言えば、ファイル転送プロトコルのような下位のレベルでは、上位レイヤにおけるような意味構造に基づく細粒度のセキュリティ保護が難しいので、下のレイヤほどトンネルされると危険、制御不能とも言えます。
さてそれで、現状の主要ブラウザにおける file URL の実装はどうなっているかと見てみると、これがもう data URI よりもサブイ状況（笑）↓
20年前からまるで進歩していないですね。せめてフォルダ階層のパンクズリストぐらい出してよ、25年前のDeleGateですらやってたんですから、と思います。見た目は、まあしょうがないというか、いっそ清々しいです。Finderの代わりに使うには、アップロードの機能が無いのが困ります。
実装は、おそらく共通のライブラリをまんま使っているだけなのでしょう。見た目がほぼ全く同じです。FireFoxだけは、わずかな工夫をしています。またSafariは独自の丸投げ路線で、macOS上ではFinderを、Windows上ではエクスプローラを呼んで済ませています。
見た目がこれだけしょぼいので、実装にも手が入れ易いのではないかと期待してしまいます。
2020-0509 sato@izmoh