モバイル暗号化ファイル転送：外出先で安全に共有

モバイルファイル暗号化は iOS の Safari と Android の Chrome / Firefox で Web Crypto API を使って動作します — デスクトップと同じ crypto.subtle.encrypt 呼び出しです。写真ライブラリやファイルアプリから選んだファイルは、バイトが端末から離れる前に AES-256-GCM で暗号化されます。負荷がかかるのは PBKDF2 鍵導出で、 iPhone 14 Pro では60万イテレーションが約350msで完了します。最近の休暇から取得した500MBの .mov ファイルでは、実際のボトルネックはアップロード帯域幅であり、暗号化ではありません。モバイルファーストの転送サービスはネイティブアプリを必要としません — ブラウザに必要なすべてが揃っています。

ネイティブアプリよりブラウザが優れている理由

モバイル向けファイル転送のネイティブ iOS / Android アプリ（ Dropbox 、 WeTransfer の2023年以前のアプリ）は広範な権限を要求し、使用後もメモリに残り、広告をプッシュします。ブラウザベースのワークフローはインストール不要で、一度実行してタブを閉じれば終わりです。さらに重要なことに、真のゼロ知識アプリの App Store 拒否（ Cryptee の2021年の経緯が記録されています）により、ブラウザデリバリーが暗号化ロジックがアプリストアの更新によってサイレントに差し替えられないことを保証する唯一の手段です。同じ JavaScript バンドルがどこでも動作し、 SHA-384 ハッシュで検証可能です。

iOS と Android での Web Crypto API

iOS 17 以降の Safari 17 は crypto.subtle を完全にサポートします（deriveKey、encrypt、decrypt、sign、verify）。 Android の Chrome はバージョン37（2014年）から対応しています。両実装ともネイティブ OS プリミティブ（ iOS は CommonCrypto 、 Android は BoringSSL ）に委任するため、暗号化は ARM の AES 命令によるハードウェア加速です。5MBのチャンクは Pixel 8 で約15msで暗号化されます。 API は未加工の鍵素材を JavaScript に公開しません（ CryptoKey オブジェクトは不透明なハンドル）。これはモバイルブラウザで拡張機能の数がはるかに少いことと合わせて、悪意ある拡張機能への耐性に貢献します。

メモリを爆発させずに大容量ファイルを処理する

モバイル Safari の JavaScript ヒープは6GB RAM の iPhone で約2GBに制限されており、古いデバイスではさらに少ないです。「ファイルを ArrayBuffer に読み込み、暗号化し、アップロードする」という単純なパターンは1GBを超えるものでクラッシュします。ストリーミングが必須です。 File.slice() で5MBのチャンクを読み込み、それぞれを HKDF で導出されたサブキーで暗号化し、 fetch() と ReadableStream ボディ経由でアップロードします。プログレッシブアップロードにより、10GBの動画でもピークメモリが50MB以下に抑えられます。 Android の Chrome はバージョン105からストリーミング fetch リクエストをサポートし、 Safari は17.4で完全サポートを追加しました。

バッテリーと発熱の考慮

AES-256-GCM はハードウェア上で安価です — ARMv8 の Cryptography Extensions により DRAM 速度近くで実行されます。 iPhone 14 Pro での1GB暗号化はバッテリーの約2%を消費し、そのほとんどはアップロードのラジオによるもので CPU ではありません。ユーザーが熱を感じるのは高いイテレーション数の PBKDF2 です。OWASPの2024年推奨の120万イテレーションは700msかかり A17 を一時的に90°Cに上昇させます。イテレーションを60万に調整するとセキュリティと発熱のバランスが取れます。 Argon2id（m=32MB）は持続的なワークロードでよりマイルドです。メモリハードネスは遅いですがパワーデンシティが低いからです。

モバイル通信・Wi-Fi・アップロードの信頼性

モバイルアップロードは失敗します。地下鉄のトンネル、エレベーター、Wi-Fi から LTE への切り替え — これらのいずれかが単純な fetch() を kill します。堅牢なモバイル転送ではチャンクレベルの確認を持つ再開可能なアップロードが必要です。 tus.io（tus 1.0 仕様、広くサポート）や S3 マルチパートアップロードなどのプロトコルが対応します。各5MBチャンクが独立してアップロードされ、失敗した場合はそのチャンクのみを再送します。クライアントはチャンクの状態を IndexedDB に保存するため、ブラウザタブのリロードや iOS のタブ退避でも全体の作業がリスタートしません。 SwissTransfer と HexaTransfer の両方が再開可能アップロードを実装しています。 WeTransfer のモバイル Web フローは実装していないため、 LTE での2GBアップロードはしばしば失敗します。

キーボード入力とパスワード UX の問題

スマートフォンのキーボードで16文字の強力なパスワードを入力するのは苦痛です。代替手段を提供します。送信者の画面からパスワードを含む QR コードをスキャンする、ネイティブパスワードマネージャーから貼り付ける（iOS は .well-known/apple-app-site-association の Web 相当物経由でキーチェーンから入力）、または以前の転送時に登録したパスキーを使用します。一時的なケースには、 Web Share Target API を使って Signal などのコンパニオンアプリがユーザーに再入力させることなくパスワードを注入できるようにします。

アクセシビリティと小さな画面

4.7インチの iPhone SE はデスクトップスタイルのドラッグアンドドロップアップローダーには合いません。モバイル暗号化 UI はビューポートを尊重すべきです。フルスクリーンファイルピッカー、ソフトキーボードの上に表示されたままのプログレスバー、すべてのボタンへの VoiceOver ラベル（アクセシビリティのための aria-valuenow 付き role="progressbar"）、 Apple HIG に従った最小44×44pxのタップターゲット。ホバー状態の背後にコントロールを隠さないでください — タッチにはホバーがありません。 iOS の低電力モードでテストしてください。これはバックグラウンドタイマーを throttle し、ポーリングベースの進捗更新を壊します。

iOS Safari の落とし穴

Safari on iOS にはいくつかのトラップがあります。 Fetch API のアップロード進捗イベントは iOS 16.4 以前では確実に発火しません。 File System Access API がサポートされていないため、 Chrome のようにローカルストレージから大きなファイルをストリームできません。 Safari はメモリプレッシャーで非アクティブなタブを積極的に退避させ、進行中のアップロードを kill します。対策として、 XMLHttpRequest と進捗イベントをフォールバックとして使用（まだ動作します）し、アップロード中はタブをフォアグラウンドに保ち、大きなファイルの場合は画面をロックしないようユーザーに警告します。

Android の広いデバイスの断片化

Android は Pixel 8 Pro から Android Go を動かす8,000円の Moto e14 まで多岐にわたります。 Web Crypto はすべてで動作しますが、パフォーマンスは大きく異なります。2GHz の MT6762 は60万回の PBKDF2 イテレーションに1.8秒かかりますが、 Apple M3 クラスの端末では200msです。 Device Memory API と Hardware Concurrency でデバイスを検出し、それに応じてイテレーション数を調整します（Go デバイスでは30万まで下げる）。モバイルのみの接続ユーザーには1GB超のアップロードが不安定になる可能性を警告します。その見返りは、暗号化された転送がフラッグシップを要求せずに世界の多数の電話で機能することです。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。