短い答え
機密でないファイルと、作業に合う条件のサービスなら、アップロードは適切な選択になり得ます。保存とアクセスは提供者や機能で異なり、削除のカウントダウンだけでは各コピーの行き先を証明できません。
問題は、彼らが嘘をついていることではありません。嘘かどうかを確かめる手段が、こちらにないことです。ファイルが端末を離れた瞬間から、そのあと何が起きるかについての約束は、すべて信用で受け取るしかない約束になります。どれだけの期間保管されるのか、誰が手を伸ばせるのか、削除のタイマーより長生きするバックアップに複製されていないか、その会社が売られたり侵入されたりしたらどうなるのか。そのどれも、外からは見えません。
ですから、役に立つ問いは「このサイトを信用するか」ではありません。「この仕事に、そもそもファイルが出ていく必要があるのか」です。多くの、そして増えつつある仕事について、答えは「ない」です。そして答えが「ない」なら、信用の問いは、答えなければならない問いではなくなります。
「アップロード」が実際にしていること
アップロードはブラウザーから別のコンピューターへファイルデータを送ることです。元のファイルの場合も、変換したコピーの場合もあります。ファイルを選ぶだけではアップロードになりません。ローカルツールは送らずに読めます。
サーバー処理は作業ファイル、要求を識別するログ、結果キャッシュ、バックアップを作ることがあります。確認すべき可能性であり、全サービスが必ず三つのコピーを作るわけではありません。外部のブラウザーテストで内部の削除や保存は確認できません。
名前と埋め込まれたメタデータが一緒に送られる場合があります。写真には場所、時刻、カメラ、ソフトウェア、サムネイルが含まれることがありますが、実際の項目は端末、設定、編集で変わります。全スマホ写真にあると仮定せず、ファイルを確認してください。
それでも多くの道具がアップロードする理由
ファイルが欲しいからではありません。ウェブの歴史のほとんどの期間、ほかに手がなかったからです。ブラウザは動画をデコードできず、指定した画質で画像をエンコードし直せず、ファイル形式を解析できませんでした。FFmpegとImageMagickを積んだサーバーには、それができました。アップロードは商売の仕組みではなく、その仕事ができる唯一の場所でした。
それは最近、静かに事実でなくなりました。ブラウザはいまやWebAssemblyを備え、同じコンパイル済みコーデックをネイティブに近い速度で走らせます。WebCodecsは、端末にすでにあるハードウェアの動画エンコーダーを見せてくれます。Canvas APIは画像を直接デコードしてエンコードし直せます。かつてサーバーが必要だった仕事は、いまやすでにそのファイルを持っている端末の上で走ります。
それでもアップロードする道具は多くありますし、正直な理由もあります。誰も書き直したくない既存の処理系、ブラウザ側にデコーダーのない形式、スマホには本当に重すぎる仕事。あまり正直でない理由もあります。サーバーとは、アカウントと利用枠と有料プランが住む場所だということです。ブラウザの中だけで動く道具は、従量課金にしにくいのです。
自分で試せる4つの確認方法
実際に使う操作と入力で確認します。それぞれは回答の一部を示し、組み合わせると一つだけより強い証拠になります。
1. ローカル操作のために接続を切る
完全に読み込み、キャッシュがあれば準備完了の表示を待ちます。接続を切り、端末内のファイルを処理します。完了すれば、その操作は切断中にサーバーを必要としなかったと分かります。失敗は資源不足や非対応でも起きるので、アップロードの証拠ではありません。成功も再接続後を証明しません。オフラインガイドに説明があります。
2. リクエストを調べる
操作前にDevToolsを開き、一覧を消去してログを保持します。接続先、URLパラメーター、本文、WebSocketメッセージを調べます。転送サイズは応答を示すことが多く、小さな要求も抽出や圧縮したデータを送れます。ファイルのサイズとの比較だけでは不十分です。通常の一覧はWebRTCの送信内容を示しません。伝送コードとブラウザーのWebRTC診断を確認します。
3. Content-Security-Policyを読む
connect-src指令はfetchやWebSocketなどの接続先を制限します。許可済み第三者にもデータは送れます。他の指令は画像、フォーム、資源を扱い、この一覧はWebRTCの相手間通信を説明しません。CSPは制約であり、内容監査や単独の非アップロード証明ではありません。
4. ソース内のデータを追う
公開ソースと生成コードを比較します。選んだファイルをfetch、XMLHttpRequest、sendBeacon、WebSocket、RTCPeerConnectionで追い、フォーム、資源URL、アプリへの引き渡しも確認します。これは例であって全経路ではありません。外部サービスやフィードバックのコードも含め、各経路にどのデータが渡るかが決め手です。
「ブラウザの中で動く」が意味しないこと
正確に言っておく価値があります。この言い回しは緩く使われますし、このサイトも、自分が提案しているのと同じ基準を自分に課さなければならないからです。
- リクエストが一切ない、という意味ではありません。ページ自体がネットワーク越しに届きましたし、無料の道具の多くは、どこかと通信する広告や解析を積んでいます。主張しているのはファイルについてであって、通信全般についてではありません。
- IPアドレスを隠す、という意味でもありません。訪れたどのサイトもそれを見ますし、このサイトも見ます。手元での処理とは、ファイルの中身についての話であって、匿名性の話ではありません。
- 何かを取得する機能があれば、そこは別です。ウェブアドレスを貼り付けさせる道具は、そのアドレスに接続しなければなりませんし、そのサーバーはこちらのIPと、何を求めたのかを知ります。それは欠陥ではなく機能に内在するものですが、本物の例外ですし、道具はそれを丸め込まずに、はっきり書くべきです。
- 「ファイルを削除します」とは違います。ローカル処理は特定の操作がどこで動くかを示します。保存は受信後の提供者の行動についての別の主張です。どちらもそのまま保証とせず、実装と通信機能の境界を確認します。
アップロードして本当に問題ないとき
これは、あらゆるアップロードが間違いだという主張ではありません。中身が機微なものでなく、そのほうが楽なら送ってください。仕事が本当に端末には重すぎるとき、形式にブラウザ側のデコーダーがないとき、あるいはすでに関係があって規約も実際に読んだサービスを使っているときも同じです。
もっと慎重になるべきなのは、ファイルの中身が、公開の場に投稿しないようなものである場合です。身分証、医療画像、契約書、共有するつもりのなかった住所や顔が写っているもの、位置情報を確かめていない写真。それらについては、信用するしかない道具より、確かめられる道具のほうが選ぶ価値があります。信用したほうが裏切りそうだからではなく、確かめられるほうでは、その問いがそもそも生じないからです。
このサイトが、その4つの確認にどう答えるか
確かめろと言っておきながら、自分だけは免除してくれと頼むガイドは、おかしなものでしょう。ですから、順番に答えます。
- オフライン。資源を読み、キャッシュが準備できればローカル処理は動きます。画像URL、為替照会、ブラウザー紹介には接続が必要です。
- リクエスト。処理コードは選んだファイルをアップロードしません。閲覧集計と任意の固定回答は別です。為替は通貨と日付を送り、相手間機能は選んだブラウザーへ意図して内容を送ります。
- ポリシー。通常は外部サービスの接続先を継承します。領収書はFrankfurter、共有とカメラは紹介サーバーを追加します。接続先を制限しても各内容は証明しません。
- ソース。ソースは公開しています。共有モジュールと同梱エンジンも含め、ビルドして結果を比較できます。
プライバシーページに境界を説明します。画像URL取り込み、任意の為替とアプリ引き渡し、ブラウザー間共有、リモートカメラ、広告、Analytics、固定のフィードバックです。意図した転送は、処理用のアップロードとは別です。
ローカル作業の例は目標サイズに向けた圧縮、動画切り抜き、EXIFとGPS削除、画像からPDF作成です。対応形式と保存結果を確認してください。処理用アップロードもアカウントも不要です。
