我厭倦了向人們解釋隱私權政策。
每次需要發送文件時，我都必須選擇一個服務，然後默默地信任它。信任它不會讀取我的文件。信任它不會用我的文件訓練模型。信任它所說的“我們不會查看您的文件”是真的。
我無法證實這些說法。你也無法證實。
所以我寫了 phntm.sh。我想坦誠地說明它是什麼，它不是什麼，以及它還有哪些不足之處。
核心思想
零知識意味著伺服器確實無法讀取你的文件，不是“不會”，而是“不能”。
如何運作如下：當你將檔案拖曳到 phntm 中時，你的瀏覽器會產生一個 256 位元 AES 金鑰。文件在客戶端使用 AES-256-GCM 加密，之後才會離開你的電腦。只有密文會傳送到伺服器。解密金鑰會嵌入到 URL 片段中，也就是 # 號後面的部分。
關鍵在於：瀏覽器永遠不會在 HTTP 請求中包含金鑰片段。這在規範 RFC 3986 中有明確規定。當你分享 phntm 連結時，接收者的瀏覽器會下載密文，並使用金鑰片段中的金鑰在本機進行解密。我的伺服器永遠不會看到金鑰。
我存儲的是噪音。沒有密鑰，密文在數學上毫無用處。
為什麼選擇開源
因為「相信我們」並不是一種架構。
我已經將 Web 應用和 CLI 都開源了，這樣你們就可以自己驗證這些說法。不要只聽我的一面之詞，請閱讀加密層程式碼，檢查密鑰是否真的沒有被送到任何地方。在做出安全聲明時，這才是唯一誠實的做法。
粗糙的邊緣，我是認真的。
我實話實說，因為這是公開搭建的平台，而不是產品發表會。
加密過程會將整個檔案快取在記憶體中。對於大文件來說，這會是個問題。我知道，這個問題已經在計劃之中了。
CLI 標誌解析功能比較基礎。我沒有使用函式庫，而是自己寫的，雖然是個很好的學習機會，但也意味著它的健壯性還不夠。
我的頁面上使用了 Vercel Analytics。一位評論者指出了這個問題，他的建議是正確的。 RFC 規範仍然有效。瀏覽器不會在 HTTP 請求中傳送資料片段。但是 Vercel Analytics 會在客戶端讀取 location.href 檔案（其中包含哈希值），並將其 POST 到他們的端點。如果哈希值是你的解密金鑰，這就造成了問題。
透過在 beforeSend 鉤子中移除事件觸發前的片段，問題已解決。經驗教訓：在做出安全聲明時，務必審核所有第三方腳本，包括那些你未加思考就加入的腳本。
現在它有什麼用呢？
向未安裝任何工具的使用者傳送文件。他們收到一個連結，點擊連結，文件在他們的瀏覽器中解密並下載。無需註冊，無需安裝應用，無需登入。
文件會在定時器到期後自動銷毀。之後就沒有什麼需要破壞的了。
我在建造這個過程中學到了什麼
我用 Go 語言編寫了 CLI，這是我的第一個真正的 Go 專案。不是教程專案，而是我自己會實際使用的東西。
真正讓我理解 Go 的 I/O 模型的，是封裝 io.Reader 來建立進度條。 HTTP 用戶端執行 io.Copy，進度列會隨著位元組的傳輸而自動更新。這雖是小細節，卻改變了我對可組合性的思考。
整個命令列介面完全基於標準庫，不依賴任何外部庫。這是我們有意為之，也是便於學習的限制條件。
它居住的地方
https://github.com/aliirz/phntm.sh
https://github.com/aliirz/phntm-cli
歡迎提出回饋意見，尤其是在加密層方面。
原文出處：https://dev.to/aliirz/i-built-a-file-transfer-tool-that-cant-spy-on-you-even-if-it-wanted-to-2p39
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
