工作區信任
2021年7月6日，作者 Chris Dias, @chrisdias
我能信任我自己嗎？這是自 1.57 版本更新以來，許多 Visual Studio Code 使用者面臨的終極哲學問題。
雖然我們無法替您回答這個問題，但我們可以告訴您更多關於我們為何引入“工作區信任”這一概念的資訊。
不過，首先來點背景介紹。
貓和鍵盤，以及害群之馬
網際網路上充滿了快樂的事物，比如貓在鍵盤上打字的影片。
對於開發者而言，網際網路也充滿了各種工具、軟體包和開源專案。這些都是由善良的人們建立的，他們希望幫助您解決那個已經困擾了您數小時的問題。像 VS Code 這樣的開發工具集成了包管理器、程式碼檢查工具、任務執行器、打包工具等，利用不斷發展的社群中最新、最偉大的技術進步，提供了愉悅的開發體驗。
然而，這個豐富生態系統所帶來的高效率，往往是建立在我們為開發裝置提供了廣泛訪問許可權的基礎之上。再加上快速的演進、病毒式的分享和使用，開發工具成為了一個誘人的攻擊目標，尤其是考慮到攻擊者可以利用我們的裝置進一步傳播攻擊（例如，透過儲存在開發者裝置上的身份驗證令牌，甚至透過開發者編寫的軟體）。
成為一名開發者雖然收穫滿滿，但也是一項有風險的工作。要為一個專案做貢獻，您天生就需要信任其作者，因為諸如執行 npm install 或 make、構建 Java 或 C# 專案、自動化測試或除錯等活動，都意味著專案中的程式碼正在您的計算機上執行。
我們推出工作區信任功能的目標是找到一個恰當的平衡點：既能防範那些想破壞一切的少數“害群之馬”，又能繼續確保我們能擁有所有那些讓開發充滿樂趣的美好事物。
嘿，這不就是個編輯器嗎？
是的，VS Code 是一個編輯器。然而，和大多數現代編輯器一樣，它能夠代表您執行工作區中的程式碼，以提供更豐富的開發體驗。
執行和除錯程式碼是顯而易見的例子。但有些程式碼執行可能不那麼明顯，比如在啟動應用前執行的 preLaunchTask，它可以執行一個構建任務，而這個任務裡可能包含一個與構建無關、執行任意程式碼的額外任務。又比如，某個 npm 模組可能會竊取您的加密錢包私鑰？您只是做了一個簡單的編輯，一個惡意的 linter 就從 node_modules 資料夾載入了，而不是您全域性安裝的那個。甚至閱讀程式碼也可能具有欺騙性，攻擊者可以使用 Unicode 技巧將惡意程式碼隱藏在眾目睽睽之下。天啊，您甚至無需開啟任何原始碼就可能被攻擊。
這裡的目的不是要嚇得您遠離所有優秀的工具（包括 VS Code），也不是要讓您改行。而是為了提高您的意識：當您從網際網路上下載由您不具備任何信任關係的個人或組織編寫的程式碼時，存在著許多攻擊的機會。
打地鼠遊戲
在上述所有場景中，這些工具都按其設計的方式工作，並且在非惡意的程式碼庫中，它們極其高效。設定一個 preLaunchTask 在除錯前構建應用能極大地節省時間，因為您不必在每次更改後都手動從終端構建。Linter 高度可定製，以支援每個團隊偏好的編碼規範和風格（是的，包括製表符與空格之爭）。提交前掛鉤（Pre-commit hooks）可以檢查您是否忘記了什麼，或確保在提交前執行測試。
現在，您不太可能同時遭受所有這些攻擊。事實上，到目前為止還沒有透過 VS Code 發生的攻擊事件，因為有一個強大的專家社群，當新的風險出現時，他們會讓我們知曉。在“工作區信任”功能出現之前，我們的方法是在每個漏洞點透過一個區域性的許可權提示來解決問題。
例如，Jupyter 擴充套件會警告使用者，當您在 Notebook 中開啟視覺化工具時，嵌入的 JavaScript 可能會執行。
ESLint 漏洞是一個棘手的問題，因為它在工作區載入時就會執行（這是我們的第一個模態對話方塊）。
事實證明，這是一場註定要失敗的戰鬥。使用者會被多個（且略有不同）的許可權提示打斷，而這些提示並不適用於整個工作區。我信任你、你、你，不信任你，還有你，但只在週二信任。對我們來說，這就像一場永無止境的打地鼠遊戲，每當一個漏洞暴露出來，就用又一個提示框去堵上它。
因此，我們在構建 VS Code 時遵循的一個模式是：觀察哪些體驗在整個工具和擴充套件中以相似但又不一致的方式實現，然後看是否能將其整合到核心功能中。信任提示就遵循了這個模式，所以我們決定著手構建一個工具和擴充套件都可以利用的體驗和 API，並希望提供一個更清晰的使用者體驗。
信任
現在您已經瞭解了程式碼可能在您不知情的情況下執行的多種方式，希望您能更好地理解為什麼我們一開始就提出這個問題。
我們特意詢問您是否信任此工作區的作者，因為 VS Code 無法判斷程式碼是否惡意（嘿，我們只認識 1 和 0），也無法知道它來自哪裡，或者您是否打算為該專案做貢獻等。
而您，則很聰明，您知道程式碼的來源：您自己（好的）、您的公司（可能還行）、您的朋友小凱（看情況），或者網際網路上的某個陌生人（絕對不行）。
這些資訊有助於讓工具變得更智慧。如果您信任作者，太好了！工具和擴充套件就獲得了綠燈，可以盡情發揮，提供神奇的體驗，而且我們不會再打擾您。
如果您不信任，您就是在告訴我們：小心點 VS Code，不要執行任何程式碼。這就是我們所說的受限模式，在這種模式下，潛在有害的功能會被停用，以便您可以更安全地瀏覽程式碼，並最終做出明智的決定。
但是那個對話方塊！
我們聽到了您的心聲，那個模態對話方塊確實很大，而且每次開啟新資料夾都會出現，除非您採取行動去配置它。
我們一開始的設計並非如此。我們研究了 ESLint 模態對話方塊的風波，並自問是否能透過視覺線索和單個、儘可能延遲彈出的通知提示，來提供一種非阻塞的體驗。我們希望做到不打擾使用者，以受限模式啟動（讓您幾乎察覺不到），然後在最後一刻才提示信任請求。
我們引入了一種“被動”信任通知，您可以透過它告訴我們是否信任該工作區。我們嘗試了各種 UI 處理方式來表明工作區不受信任，包括在“設定”齒輪圖示上增加標記，以及引入一個新的安全圖示。
如果您使用 Insiders 構建版本，您將獲得 VS Code 新體驗的最新迭代，就像我們正在討論的“工作區信任”一樣。Insiders 版本每日釋出，我們用它來構建 VS Code。
其理念是讓使用者（您！）可以根據自己的節奏，決定何時授予或拒絕工作區的信任。只有當工具或擴充套件確實需要訪問許可權時，我們才會彈出一個通知，詢問您是否信任該工作區。
現在，我相信你們中的許多人都會同意，VS Code 有點我們所說的“通知疲勞症”（我保證我們正在解決這個問題 😊）。在我們的測試中，我們發現人們根本不理會這個通知。使用者沒有看到齒輪圖示上的通知，甚至沒有看到新的安全圖示。使用資料顯示，透過被動通知授予信任的比率非常低。在使用者研究中，我們觀察到人們把所有時間都花在以為自己弄壞了什麼東西上，然後又花時間排查故障，試圖回到他們預期的狀態。
我們本想做到不打擾使用者並儘可能延遲提示，但現實是，在受限模式下，產品感覺像是壞了，而人們認為是自己的錯。這對我們雙方來說都不是一個好的處境。
讓您掌控一切
信任一個資料夾的決定對 VS Code 的功能有著根本性的影響，因此經過所有研究後，我們認為正確的做法是在您嘗試開啟資料夾時立即詢問信任問題。因為模態對話方塊具有干擾性，我們試圖透過讓對話方塊功能強大來平衡這一點，這樣您只需回答幾個問題，最終在日常工作中就能大大減少看到提示的頻率。
透過我們自己的內部試用（dogfooding）以及與其他開發者的訪談，我們發現人們通常有一個主資料夾，用來存放他們所有的原始碼，並認為它是可信的。因此，我們添加了直接從對話方塊中信任父資料夾的功能。您只需一次點選就可以信任它及其所有子資料夾，然後您就不會再看到信任提示了。
工作區信任編輯器
工作區信任編輯器讓您對信任的內容有更多的控制權，並將在 1.58 版本中更新，使其更容易配置以滿足您的需求。
因為您可以自定義其行為，所以有很多方法可以進入信任編輯器 😊。點選狀態列中的受限模式訊息、受限模式橫幅中的管理連結、齒輪選單，或者開啟命令面板（F1）並使用 Workspaces: Manage Workspace Trust（工作區：管理工作區信任）命令。
在工作區信任編輯器中，您可以信任當前資料夾、父資料夾（及其所有子資料夾），以及計算機上的任何資料夾。
您還可以快速跳轉到所有工作區信任設定，以微調體驗。
我們如何使用工作區信任
沒人喜歡用牙線，但我們還是會用，因為我們知道這是正確的事。沒人願意考慮安全問題，但我們也知道這是正確的事。透過自定義體驗，您可以在保持開發體驗愉悅的同時，保護自己免受開發中固有的威脅（有趣的牙線？！）。
VS Code 團隊的大多數人開始時都有一個頂級資料夾，他們在那裡處理他們信任的原始碼。例如，在我的 Mac 上，我把所有從 GitHub 上的 Microsoft 組織拉取的原始碼都放在我的 ~/src 資料夾裡。我將 ~/src 指定為受信任的資料夾，其下的所有內容都自然被信任。當我開啟 ~/src/vscode 或 ~src/vscode-docker 等資料夾時，它們都是以完全信任的方式開啟的，因為我信任我的組織編寫和使用的程式碼。
我有一個單獨的資料夾叫做 ~/scratch（“草稿本”的縮寫，您當然可以取任何您喜歡的名字），我把其他所有東西都放在那裡，並預設假定它是不可信的。然後，我再逐個資料夾地做信任決定。
為了簡化我的工作流程，我將 "security.workspace.trust.startupPrompt" 設定設為 "never"。
透過這個設定，我不會被模態對話方塊提示，工作區會直接在受限模式下開啟。我已經決定 ~src/scratch 資料夾是不可信的，所以沒有必要每次開啟一個子資料夾都來提示我。如果我決定確實信任我正在閱讀或編寫的程式碼，我可以透過兩次快速點選為該資料夾啟用信任（點選 VS Code 頂部的受限模式通知，然後點選信任按鈕）。
在我的 Windows 電腦上，情況要更有趣一些。我通常在運行於 Windows Subsystem for Linux (WSL) 上的 Ubuntu 映象中工作，使用 WSL 擴充套件。我信任 Linux 上的 ~/src 資料夾，也信任 Windows 端的 d:\src 資料夾。
團隊中有幾個人更進一步，把頂部的受限模式橫幅也關掉了（"security.workspace.trust.banner": "never"），只留下狀態列的通知。對我來說這有點過了，頂部的橫幅能讓我保持誠實，並提醒我在從網際網路上拉取程式碼時要保持警惕。
開源真棒
我們知道 VS Code 是您用來完成“真正”工作的工具，我們引入的任何減速帶或障礙只會減慢您構建和釋出下一個獨角獸公司的速度。許多人花時間在 Twitter、Reddit 和 issue 中聯絡我們，我們感謝您坦誠的反饋。基於您的意見，我們在 1.58 版本中進行了許多修復和改進，並期待繼續這場對話。
展望未來，我們希望幫助擴充套件作者避免任意程式碼執行，並在受限模式下執行時提供更多功能。我們的路線圖中提到了我們正在與 Visual Studio Marketplace 團隊合作，為擴充套件生態系統帶來額外的安全性（我們稱之為“受信任的擴充套件”），包括驗證釋出者、簽名和特定於平臺的擴充套件。簡而言之，您可以將“工作區信任”視為幫助好的擴充套件做出好的決定。而“受信任的擴充套件”將幫助您防範壞的擴充套件。
以開放的方式構建 VS Code 的好處之一是社群可以幫助我們創造最佳的體驗。所以，請告訴我們如何改進這個流程，在儘可能不打擾您的情況下幫助您保持安全。請（禮貌地！）在現有的 issue 中評論，提交一個新的，或者在 Twitter 上 @code 我們，我們正在傾聽！
謝謝，
Chris 和 VS Code 團隊
（安全地）編碼愉快！