關於 load.tw EXIF 與隱私安全的說明
近期看到 Dcard 上有一篇文章提醒使用者不要使用 load.tw，文章主要指稱 load.tw 所宣稱的「自動移除 EXIF」功能實際上不存在，並以作者當時測試的結果，認為使用者上傳圖片或影片可能會洩漏拍攝時間、裝置資訊甚至 GPS 座標。
這篇文章中有一些對於隱私安全的提醒是值得注意的，但其中部分結論其實是建立在特定時間點、特定版本的系統行為上，因此有必要補充目前 load.tw 的實際狀況。
一、目前已經加入自動 EXIF / Metadata 清除機制
首先要直接說明：
load.tw 目前已經具備圖片 EXIF / Metadata 自動清除機制。
也就是說，現在使用者上傳圖片後，系統會進行相應的處理，而不是單純將原始圖片直接存放後再提供下載。
因此，如果文章作者是在功能尚未完成、尚未部署，或舊版本仍然採取原始檔案直存的階段進行測試，那麼測試結果只能代表當時的版本，並不能直接代表目前網站的行為。
網路服務會持續更新，尤其是上傳、轉檔、隱私處理這類功能，本來就可能隨版本變更。
如果過去確實存在處理不完整的情況，我們也不會否認，而是直接修正。
目前的方向非常明確：
使用者上傳圖片後，系統應自動處理可能包含個人資訊的 Metadata，而不是要求一般使用者自己理解 EXIF 並手動清除。
這才是我們認為比較合理的使用方式。
二、「檔案內容不變」與「清除 Metadata」並不是同一件事情
原文章將「你的檔案還是你的檔案，我們不壓縮它、不重新編碼它」與「自動清除 Metadata」視為互相矛盾。
實際上，這兩件事情並不是完全等價的概念。
圖片可以在不大幅改變影像本身的情況下，針對檔案中的 Metadata 進行處理。
簡單來說：
照片畫面內容 ≠ EXIF Metadata。
例如一張照片可能包含：
- 拍攝時間
- GPS 座標
- 相機型號
- 鏡頭資訊
- 軟體版本
- 旋轉資訊
- 其他 IPTC / XMP 等 Metadata
清除這些 Metadata，並不代表一定要把照片重新壓縮到完全不同的畫質。
因此，「沒有重新壓縮圖片」與「移除 Metadata」本身並不是互相衝突的兩個條件。
三、文章中提到的「原始檔案可以下載回來」也需要區分測試對象
如果上傳的是一般二進位檔案，平台沒有對這類檔案進行影像處理，那麼重新下載後內容與原始檔案完全一致，本身並不能證明「圖片 EXIF 沒有被處理」。
因為：
EXIF 清除本來就是針對圖片 / 影音等具有 Metadata 的格式進行處理。
一個完全沒有影像結構的隨機二進位檔案，與 JPEG、HEIC、PNG、MOV 等媒體檔案是不同的測試案例。
如果要驗證 EXIF 清除功能，真正有意義的測試應該是：
- 使用確實包含 EXIF GPS 的照片
- 上傳至網站
- 下載處理後的檔案
- 使用 ExifTool 等工具檢查
- 確認 GPS、拍攝時間、裝置資訊等 Metadata 是否仍然存在
這才是針對「EXIF 是否被清除」的直接測試。
四、關於「以前測試到的結果」
如果文章作者是在系統尚未加入目前這套處理機制時進行測試，那麼他當時看到的結果可能完全是真實的。
這裡並不需要否認測試結果。
但問題在於：
舊版本的測試結果，不應該直接被描述成目前版本的永久狀態。
網站功能會更新，後端流程也會修改。
例如今天網站增加：
- EXIF 清除
- Metadata 清理
- 檔案生命週期管理
- 儲存權限調整
- 防盜連
- 快取策略
那麼幾個月前針對舊版本做的測試，自然不能直接代表現在的系統。
如果有人真的關心這件事情，我反而歡迎重新使用目前版本進行測試。
五、關於「過期檔案仍然可以存取」的問題
文章另外提到連結過期後，R2 上的素材可能仍然存在。
這部分其實涉及兩個不同概念：
前台連結失效 ≠ 儲存層物件立即不存在。
網站可以先讓公開連結失效，再依照後端的生命週期或清理機制處理儲存空間中的檔案。
因此，看到某個 R2 Object 在特定時間點仍然存在，並不能單獨證明「網站宣稱的刪除機制完全不存在」。
不過這確實是一個值得改善與驗證的地方。
對於使用者來說，最重要的是：
已經失效的內容不應該繼續透過公開 URL 被任意取得。
這也是平台應該持續檢查的部分。
六、我們並不鼓勵使用者上傳敏感原始照片
即使平台已經加入 Metadata 清除，也不代表使用者就應該毫無顧慮地把所有原始檔案丟到網路上。
任何公開圖床、雲端硬碟或檔案分享服務，都應該遵守基本的資訊安全原則。
例如：
- 身分證件不要直接公開上傳
- 含有住址的文件不要公開
- 工作機密不要放到公開圖床
- 私人照片應確認分享範圍
- 敏感內容在上傳前最好自行確認一次
平台可以降低風險，但不可能替使用者判斷每一張照片是否適合公開。
七、至於文章中其他對網站架構與 AI 文章的評論
文章後半段對網站架構、文章內容、AI 生成文字以及網站設計有不少評論。
這些屬於作者個人的觀察與評價，我們沒有必要逐項爭論。
網站的程式碼怎麼設計、文章寫得好不好、介面喜不喜歡，都可以被公開討論。
但如果要討論「隱私漏洞」，最好還是回到可以被重現與驗證的技術事實。
例如：
「這個版本上傳含 GPS 的 JPEG，下載後 GPS 仍然存在。」
這是一個可以重現的技術問題。
相反地：
「這個網站看起來像是 AI 寫的，所以功能一定有問題。」
這就不是同一個層次的證據。
我們比較希望大家把注意力放在前者。
八、最後，也想說明一件事情
我們注意到這篇文章對 load.tw 的描述相當完整，甚至包含前端程式流程、R2 儲存行為與網站內容的逐項分析。
我們無法知道作者的動機，也不會在沒有證據的情況下指稱任何人是同行、競爭對手或刻意抹黑。
網路上出現競爭服務、使用者測試服務、甚至公開指出問題，本身都是正常的事情。
如果真的存在問題，我們會修。
如果測試結果是舊版本的行為，我們也會把目前版本的實際狀況說清楚。
我們認為最重要的不是要求大家「相信 load.tw」，而是：
讓任何人都可以自己測試、自己驗證。
如果對 EXIF 是否清除有疑問，可以直接使用 ExifTool、MediaInfo 等工具測試上傳前後的檔案，確認 GPS、拍攝時間、裝置資訊等 Metadata 是否仍然存在。
這比單純相信網站的一篇文章，或者相信另一篇反駁文章，都更有意義。
總結
這篇 Dcard 文章提醒大家注意 EXIF 與個資外洩，本身是一個值得討論的議題。
但需要釐清的是：
文章所描述的測試結果，並不等於目前 load.tw 的系統狀態。
目前 load.tw 已經加入自動 EXIF / Metadata 清除機制，並持續針對檔案處理與內容生命週期進行改善。
如果過去版本確實有處理不足的地方，我們接受這個問題，也會持續修正。
與其爭論誰說得比較大聲，不如直接拿目前版本的檔案測試。
技術問題，就讓技術驗證。
