ByteScope

QR File Transfer

片方の画面からもう片方のカメラへ、ファイルを光で運ぶ——ネットワークなし、ケーブルなし、ペアリングなし、アカウントなし。

ファイルの分割・符号化・表示はすべてブラウザ内で行われます。アップロードは一切ありません。

ファイルを送る

ファイルを選んだら、もう一方の端末のカメラを動く QR コードに向けてください。フレームは延々とループするので、数枚読み逃しても問題ありません。

ここにファイルをドロップ

クリックして選択も可能 — 最大 5 MB

フレームレート

上げるほど速くなりますが、追いつけないカメラでは読み取れる枚数がかえって減ります。

QR の密度

小さいコードほど確実に読み取れ、大きいコードほど 1 枚あたりのデータ量が増えます。

ブラウザ対応状況

送信側は canvas に描くだけなので、どのブラウザでも動きます。受信側はカメラと、QR のデコード速度に左右されます。

機能ChromeEdgeFirefoxSafari
送信（canvas での QR アニメーション）対応対応対応対応
カメラの利用（getUserMedia）保護されたコンテキスト（HTTPS）と、利用者の許可が必要です。対応対応対応対応
BarcodeDetector（高速読み取り）Chromium 系のみ。しかも Chromium なら必ずあるとは限らず、Linux 版のビルドでは欠けていることが少なくありません。そのためブラウザ名を当てにせず、実行時にコンストラクタと QR 形式の両方を確認しています。一部対応一部対応非対応非対応
フォールバック読み取り（jsQR）どのブラウザでも動きますが、1 秒あたりに読める枚数は少なくなります。対応対応対応対応
送信側の全画面表示iOS Safari はプログラムからの全画面を video 要素に限定しています。対応対応対応一部対応

検出されたブラウザ機能

  • BarcodeDetector …
  • QR 形式に対応 …
  • mediaDevices …
  • 保護されたコンテキスト（HTTPS） …

このツールについて

送信側の端末でファイルを選ぶと、このページはそれをブロックに分割し、Luby Transform方式のfountain codeで符号化して、毎秒5〜20フレームのQRコードのアニメーションとして画面に流し続けます。受信側の端末では同じページを開き、カメラを相手の画面に向けるだけ。フレームがデコードされるたびにプログレスバーが進み、必要なブロックが揃った瞬間にファイルを組み立て、CRC-32チェックサムで検証してダウンロードとして差し出します。2台の間を渡るのは光だけです。ネットワークも、サーバーも、ペアリングも、ケーブルも、アカウントも要りません。だからOSの組み合わせも問いません——Webページさえ表示できれば、それで足ります。

フレームを読み逃しても何も失われない理由

このチャネルは完全な一方通行で、受信側から「37番のフレームをもう一度」と頼む手段がありません。fountain codeは、まさにこの状況のために作られた符号です。ブロックを1番、2番、3番と順に送るのではなく、どのQRフレームも複数のブロックをランダムに混ぜ合わせたものになっていて、十分な数のフレームさえ集まれば——どのフレームだったかは問わず——ファイル全体が復元できます。カメラがブレた、オートフォーカスが迷った、一瞬画面から目を離した。それで失われるものは何もなく、次のフレームが同じ情報を別の組み合わせで運んできます。フレームの4割を落としても転送は完了します。少し余計に時間がかかるだけです。送信側が延々とループし続けるのも同じ理由です。受信側が何を拾えたかを知るすべはありませんが、fountain codeなら知る必要もないのです。

正直な数字——向いている用途と、向いていない用途

これは細いチャネルです。毎秒数KBから数十KB程度で、上限を決めているのはカメラのシャッターと画面のリフレッシュレートです。設定ファイル、SSH鍵、証明書、ウォレットのシード、小さなドキュメント——数MBまでのテキスト系にはちょうどよく、写真ライブラリや動画にはまったく向きません。本領を発揮するのは、同じ部屋にあるのに他の手段では繋がらない2台です。共有Wi-Fiがない、何もインストールできないロックダウンされた業務PC、エアギャップ環境のマシン、頑なに会話を拒む異なるOS同士。送信側はどのブラウザでも動きます（canvasにQRコードを描いているだけです）。受信側はBarcodeDetector APIを持つChromium系——Chrome、Edge、Opera、Android版Chrome——が最速で、それ以外はJavaScriptのQRデコーダーにフォールバックするぶん遅くなります。そして意図的な制限をひとつ。転送サイズには上限があり、バッチ処理や自動化モードはありません。放置できて無制限の画面→カメラのチャネルは、エアギャップ環境からデータを持ち出す経路そのものであり、そのための洗練されたツールを作るつもりはないからです。

よくある質問

実際どのくらいのサイズを、どのくらいの時間で送れますか？

毎秒数KB〜数十KBを目安にしてください。上限を決めているのは符号ではなく、変化し続ける画面をカメラがどれだけ速く正確に捉えられるかです。40KBの設定ファイルなら数秒、数百KBの証明書の束なら1〜2分、数MBが実用上の上限で、ツール側にもハードなサイズ上限があります。それより大きいもの——写真、動画、アーカイブ——にはこのツールは不向きです。1時間プログレスバーを眺めてもらうより、先にそう言っておくほうが誠実だと考えています。

受信側はもう完了したのに、送信側がQRコードを流し続けるのはなぜですか？

送信側には知るすべが本当にないからです。このチャネルは一方通行で、光は画面からカメラへ進むだけで、何も戻ってきません。だから送信ページは、止められるまでfountain code化したフレームをループし続けます。これはバグではなく、ペアリングなしで成立させるための設計そのものです。受信側にダウンロード完了が出たら、好きなタイミングで送信を止めてください。

ファイルはどこかにアップロードされますか？

いいえ。「サーバー側で削除します」という意味の「いいえ」ではありません。経路上にサーバーが存在しないのです。ファイルは送信側のブラウザで読み込まれて分割・符号化され、光として渡り、受信側のブラウザで組み立てられます。両端のDevToolsのNetworkタブで確認できます。ファイルそのものも、その名前も、端末から出ることはありません。サイト側の解析が記録するのは、転送が行われたという事実と、おおまかなサイズの区分だけです。

受信側が自分のブラウザで動かないのはなぜですか？

カメラ側はChromium系だけが実装するBarcodeDetector APIで最速に動きます。デスクトップのChrome、Edge、Opera、そしてAndroid版Chromeです。FirefoxとSafariではJavaScriptのQRデコーダーにフォールバックするため、動きはしますが毎秒読めるフレーム数が減り、転送に時間がかかります。カメラの使用許可も必要です。送信側にはそうした条件はありません。canvasにQRコードを描くだけなので、どのブラウザでも動きます。

これは安全ですか？他人のカメラにも読まれてしまうのでは？

読まれます。はっきり言っておきます。画面が見える人は、誰でもこのファイルを取得できます。QRフレームは暗号化されておらず、このチャネルのプライバシーは、いまいる部屋の物理的なプライバシーそのものです。鍵、シード、認証情報のような重要なファイルは、送る前に暗号化してください（ageファイル、パスワード付き7z、GPGなど）。パスフレーズは別の経路で渡すこと。なお、サイズ上限と自動化モードの不在も意図的なものです。放置できる画面→カメラのチャネルは、エアギャップ環境からの持ち出しツールになってしまうので、私たちはそれを作りません。