LocalTransfer.
// 隣の端末に、まっすぐ渡す
LocalTransfer は、Picolas が個人で開発・運営しているブラウザ間のファイル転送ツールです。 このページは操作手順の説明ではなく、なぜサーバーを経由しない形にしたのかを運営側から書いたものです。 実際の使い方は開いてすぐ分かる作りにしてあるので、先に試したい方は本体へどうぞ。
1 メートル先の PC に、動画を送れなかった
きっかけは、スマホで撮った数百 MB の動画を、目の前のノート PC に移そうとしたときでした。 ケーブルは見当たらず、メールには大きすぎて添付できず、 結局クラウドストレージにアップロードして、PC 側で開いてダウンロードしました。 往復で十数分かかりました。2 台の端末は同じ机の上にあり、同じ Wi-Fi につながっていました。
冷静に考えると、このとき動画は自宅の Wi-Fi を出て、回線を通ってどこかのデータセンターに保存され、 また同じ経路を逆向きに戻ってきています。物理的には 1 メートルの移動のために、 何百キロも往復させたことになります。しかも途中に、自分の管理下にないコピーが一つ残りました。
同じことをするアプリはいくつもありますが、たいてい両方の端末に同じアプリを入れる必要があります。 自分の端末同士ならまだしも、その場で会った相手に「まずこれをインストールしてください」と頼むのは現実的ではありません。 ブラウザなら、どの端末にも最初から入っています。 そこを起点にすれば、インストールを頼まずに済むはずでした。
クラウド経由の受け渡しは、離れた相手に渡すための仕組みです。 目の前の相手に渡すときまでその経路を使っているのは、単に他の選択肢が用意されていなかったからです。
ファイルの通り道を、サーバーの外に出す
LocalTransfer は WebRTC という、ブラウザ同士が直接通信するための仕組みを使っています。 ビデオ通話で映像と音声をやり取りするのに使われている技術で、そこにファイルを流しています。 配信しているのは HTML と JavaScript だけで、ファイルを預かって中継するサーバーを持っていません。
1. 中身は端末から端末へ直接流れる
送信側で読み込まれたファイルは、細かく分割されて相手の端末へ直接送られ、向こう側で組み直されます。 サーバーに一度置いてから取りに行く方式ではないので、保存期限も、削除の約束も出てきません。 置いていないものは、消す必要がありません。
2. 通信路そのものが暗号化されている
WebRTC のデータ通信は DTLS で暗号化されます。これは追加した機能ではなく規格上そうなっているもので、 オフにする設定もありません。同じ回線を使っている第三者が通信を覗いても、中身は読めません。
3. 接続を作る部分だけは、外の助けが要る
ここは正直に書いておきたいところです。2 台の端末が直接つながるためには、 お互いの居場所を知る必要があります。この顔合わせの手続き（シグナリング）だけは、外部との通信が発生します。 やり取りされるのは接続に必要な情報だけで、ファイルの中身はここを通りません。 握手が済んだ後は、二者間の直通の経路にファイルが流れます。
「サーバーを一切使っていない」ではなく「ファイルの中身がサーバーを通らない」が正確な表現です。 この違いを曖昧にしたまま安全性を主張する説明を見かけますが、 利用者が判断できるように、どこまでが直通なのかは明示しておくべきだと考えています。
4. 同じ Wi-Fi なら、インターネットの外側で完結する
送り手と受け手が同じネットワークにいる場合、経路は宅内・社内のネットワーク内で閉じます。 外に出ないので速度は回線契約に縛られませんし、上りの遅い回線でも影響を受けません。 冒頭の「机の上の 1 メートル」は、本来この速さで終わる作業でした。
渡すまでの流れ
アカウントも URL の発行もありません。両方の端末でページを開いて、番号を合わせるだけです。
向いていない使い方
直接つなぐ設計には、はっきりした弱点があります。宣伝しにくい部分ですが、 先に知っておいたほうが困らないので書いておきます。
両方が同時に開いている必要がある
これが最大の制約です。サーバーに置いてから取りに行く方式なら、相手は都合のいい時間にダウンロードできます。 直接つなぐ方式では、送り手と受け手が同じ瞬間にページを開いていなければ成立しません。 「渡しておく」ができず、「今から渡す」しかできないということです。 深夜に送っておいて朝に受け取ってもらう、という使い方には向きません。
ネットワークによっては直接つながらない
企業や学校のネットワークには、端末同士の直接通信を通さない設定のものがあります。 その場合は接続が確立しないか、著しく遅くなることがあります。 同じ Wi-Fi 同士のときが最も安定し、条件が厳しいネットワークほど不利になる、という傾向があります。
転送中はタブを閉じられない
処理しているのがブラウザ自身なので、途中でタブを閉じたり端末がスリープしたりすると転送は止まります。 大きなファイルを送っている間は、両方の画面をそのままにしておいてください。 この点はクラウド経由のほうが確実に楽です。
LocalTransfer が担当するのは「今この場で、目の前の端末に渡す」場面です。 非同期の受け渡しや、長期の共有はクラウドのほうが適しています。用途で使い分けるのが現実的だと思います。
実際に効く場面
制約を裏返すと、得意な場面ははっきりしています。 相手がその場にいて、ファイルが大きく、クラウドに置きたくない——条件が重なるほど有利になります。
- スマホで撮った動画や写真を、そのまま PC に移す。ケーブルもアプリも探さずに済みます。
- 打ち合わせの場で、相手にその場で資料を渡す。相手にインストールを頼まずに済むのが効きます。
- 社外に出したくない書類を、同じ社内ネットワークの同僚に渡す。経路が社内で閉じます。
- 出先で回線が細いとき。同じ Wi-Fi にさえつながっていれば、外向きの速度に左右されません。
- アップロード容量の上限に引っかかる大きなファイル。預けないので、保管側の制限が発生しません。
Local Suite の中での役割
Picolas では「データを端末から出さない」という一つの方針で、用途の違う小さなアプリを個別に公開しています。 その中で LocalTransfer が担当しているのはファイルを運ぶ工程です。 ファイルを加工する工程は OFFiler が持っています。
この 2 つは組み合わせると筋が通ります。OFFiler で写真の位置情報を消したり、 PDF から不要なページを抜いたりしてから、LocalTransfer で相手に直接渡す。 加工も転送もサーバーを経由しないので、ファイルは一度も他人の管理下に置かれずに相手の端末へ届きます。 別々のアプリに分けているのは、片方だけ使いたい人に両方を読み込ませないためです。
よくある質問
ファイルはサーバーに保存されますか？
保存されません。ファイルの中身は端末間を直接流れます。接続を確立するための情報のやり取りだけは外部との通信が発生しますが、そこにファイルの中身は含まれません。
インターネットに接続していなくても使えますか？
送る側と受け取る側が同じ Wi-Fi やネットワーク内にいれば、インターネットを経由せずに転送できます。ただしページ自体を最初に読み込む際には接続が必要です。
相手にもアプリのインストールが必要ですか？
不要です。双方ともブラウザでページを開くだけで使えます。相手にインストールを頼まなくていいことを、設計上の優先事項にしています。
ファイルサイズの上限はありますか？
1 ファイルあたり最大 2GB まで対応しています。複数のファイルをまとめて送ることもできます。
相手が後から受け取ることはできますか？
できません。両方が同時にページを開いている必要があります。ファイルを預かる場所を持たない設計上の制約です。時間をずらして渡したい場合はクラウドストレージのほうが適しています。
接続できないことがあります。
端末同士の直接通信を制限しているネットワークでは、接続が確立しないことがあります。同じ Wi-Fi に両方をつなぎ直すと成功しやすくなります。
これから
LocalTransfer は個人で運営しているため、更新のペースは大きくありません。 優先しているのは機能追加より接続の成功率と、失敗したときの分かりやすさです。 直接つなぐ方式は環境によって結果が変わるので、 つながらなかったときに何が起きたのかが利用者に伝わることが、この種の道具では重要だと考えています。
うまくつながらなかった環境の情報や、こういう使い方をしたいという要望があれば Picolas のお問い合わせから送ってください。