現状と課題
ここまで見てきたように，File APIを使うことで，JavaScriptでファイルを直接加工してからアップロードするということが可能になりました。今回取り上げたのは，「ブラウザ（ローカル）で暗号化してアップロード」することですが，これはHTML5のFile APIで可能になったことの，ほんの一例に過ぎません。専用アプリケーションを使わないとできないと思われていたようなことがプラグインなしで，JavaScriptだけで実現可能になったというのは，たいへん画期的なことです。
JavaScriptの速度は劇的に改善されていますし，巨大なファイルに対する処理であっても実用的な速度で動くようになっています。適度にファイルを分割して処理させることで，ブラウザの動作が固まるといったこともないでしょう。また，必要に応じてWeb Workersを使えば，完全にバックグラウンドで処理することも可能です。場合によってはWeb WorkersとpostMessageでデータを受け渡すコストのほうが高くなってしまうので，データのサイズに応じて処理を切り分けるのものよいでしょう（注14）。
暗号化の代償は
本連載の最後に，クライアントサイドでの暗号化について，筆者なりの考察を書いてみます。クライアントサイドで暗号化を行い，運営者側にもファイルの中身がわからないようなストレージサービスを提供する場合，大きな問題点が2つあります。一つはストレージの運用コストの問題，もう一つはプライバシーと利便性のトレードオフの問題です。
暗号化と重複排除
暗号化することで，ストレージ容量を逼迫する問題があります。
多くのストレージサービスは，すでにアップロードされたファイルがアップロードされる場合，ディスク上へ新規に保存せず，既存のファイルへの参照として保存することでストレージコストを節約しています。それに対して，ユーザが各々勝手に，ファイルを暗号化して巨大なファイルをアップロードしていくと，「中身は同じファイル」なのにユーザによって生成される暗号化済みのファイルはバラバラ，という状況が発生してしまうわけです。
ここで，運営者にも中身がわからない暗号化を行ったまま，重複排除を行う方法として，Convergent Encryption（収束暗号化）という手法が知られています。bitcasaというサービスがこれを行っていると言われています。
ユーザの多くが「運営者にもわからない暗号化」を望んでいる場合には，あらかじめ運営者側が用意された，重複排除も考慮した暗号化ロジックを使うことでストレージの効率を高めることができます。今回例に挙げたMegaでは，どの程度重複排除の処理が行われているのか，筆者はまだ把握しきれていませんが，少なくとも既存のファイルを自分のファイルマネージャ上にコピーする，といった処理であれば，既存のファイルへの参照のみを保存してストレージコストを節約するといったことができるでしょう。そうすると，悪意を持ってストレージコストを意図的に浪費する，といった攻撃への対策は難しくなります。そうしなければ，Megaでは「ファイルの中身がわからない」わけですから，暗号化前のファイルが意味のあるファイルだったのか，それともランダムに生成された意味のないバイト列だったのか，正当な利用なのかサービス妨害行為なのか，それすらも区別が付かなくなってしまうというわけです。
暗号化と検索
さらには利便性との兼ね合いもあります。運営者にも中身がわからない，完全にプライバシーが守られたストレージを提供する代償として，Megaは「単なるストレージ」として使うことしかできなくなってしまいます。
動画ファイル向けのストレージサービスであれば，モバイル機器向けに変換する機能があるとユーザは便利でしょう。また，写真に特化したストレージであれば，Exif情報を読み取って撮影時刻や場所によって整理をしたり，色や画像の特徴によって分類したり，顔認識技術によって写っている人をキーにして整理をしたり，オンラインで簡単な画像編集を行うといったこともできるでしょう。サーバ側で「ファイルが何であるのか」が読み取れるようになっていれば，さまざまなことが可能になるのです。スキャンした書類や書籍であればOCRによってテキストに変換して全文検索を可能にしたり，さまざまな形式のドキュメントをブラウザ上で閲覧できるように変換したりといったことができます。
Megaは「ファイルの中身がわからない」ということをセールスポイントにしてしまった結果，このような「ファイルの中身がわかる」ことによる付加価値を提供できません。暗号化と検索を両立させることは非常に困難なのです。ファイルを暗号化することで運営者からもわからないということは，サーバ側での検索や整理もできなくなるということです。
ただ，ちょっとした検索機能程度であれば，ファイル名での検索など，メタ情報をいくつか抽出しておいてクライアント側でできる程度のことを，クライアント側で行うということもできます。画像や動画であれば，あらかじめクライアント側でサムネイル画像を生成しておいて一緒に保存しておく，程度のことはできるでしょう。いずれにせよサーバ側で中身がわからないためサービスの内容が大幅に制約されることになります。
暗号化か，利便性か
暗号化によるプライバシーの確保と利便性の獲得は，まさにトレードオフなのです。けっして誰にも見れれてはいけないような秘匿すべきファイルを保存する目的であれば，クライアントサイドでの暗号化／復号が行われることによる安心感は，ほかの付加価値を上回ることになるでしょう。
こういったサービスの需要が高まるのは，逆に言えば，既存のサービスが信頼を失ったときや，警察機関などによる捜査などによって，プライバシーリスクが無視できないという状況になったときでしょう（注15）。
連載のおわりに
日本の暗号化状況
もともと，エンドユーザのプライベートなやりとりは，運営者側にもわからないことが前提であったはずでした。
しかし，今回取り上げたストレージサービスだけでなく，日本発のSNS（Social Networking Service）などで，運営者がメッセージの中身を見る（検閲する）ということが，もはや日常茶飯事のように行われてしまっています。文化的に，JavaScriptの使えないフィーチャーフォンが発達したこともあります。いくらFile APIなどによりサービスの秘匿性が高まっても，JavaScriptが使えなければ実現しようがありません。フィーチャーフォンですので，PCブラウザのように秘密鍵の保持もできません。ブラウザの制約により，ローカルに秘密情報を持つことができなかったのです。
結果として，本来ならば当然End-to-Endのやりとりが行われているべきだったプライベートなやりとりが，運営者から筒抜けの形で保存されています。その結果，諸問題が生じているのも事実です。
いまこそ立ち上がれ，フロントエンドエンジニア
筆者はこのような状況を鑑みて，そろそろフロントエンドの周辺が再考されてもよいのではないか，と考えています。
巨大な資本を持ち，サーバ資源をたくさん持っている企業がとかく勝ち続けている日本のWebサービス界隈。筆者は，巨大な起業が勝ち続けるという状況を，フロントエンドからのアプローチで，ある程度打破できるのでは，と考えています。今回見てきたように，HTML5のFile APIのような新しいテクノロジは，まさに新しい扉をこじ開けるための鍵となっていると言えるでしょう。リソースがなくても別の土俵で戦えるはずです。フロントエンドエンジニアの腕の見せどころですね。
1 年間続いた本連載では，フロントエンド周りのJavaScriptやセキュリティ／プライバシー，UIのことを取り上げてきました。ヒットするWebサービスを作るには，そのUIはもちろん重要です。しかし，クライアントサイドでしかできないことを実装するのは，みなさんフロントエンドエンジニアの仕事です。この連載がみなさんの手助けとなれば，これほど嬉しいことはありません。
