ワークスペースの信頼
2021年7月6日 by Chris Dias, @chrisdias
自分自身を信頼できるか？これは、1.57 アップデート以降、多くの Visual Studio Code ユーザーが直面している実存的な問いです。
私たちがその問いに答えることはできませんが、なぜ私たちがワークスペースの信頼という概念を導入したのかについて、詳しくお伝えすることはできます。
しかしその前に、少し背景を説明しましょう。
猫とキーボード、そして腐ったリンゴ
インターネットは、猫がキーボードをタイピングする動画のような、楽しいものであふれています。
開発者にとっては、何時間も取り組んできた問題を解決するのに役立つ、善意の人々によって作られたツール、パッケージ、オープンソースで満ちあふれてもいます。VS Code のような開発ツールは、パッケージ マネージャー、コード リンター、タスク ランナー、バンドラーなどを統合し、進化し続けるコミュニティからの最新かつ最高の進歩の力を活用した楽しい体験を提供します。
しかし、この豊かなエコシステムがもたらす生産性は、多くの場合、私たちの開発マシンに与えられた広範なアクセス権の結果です。それに加え、急速な進化とウイルス的な共有・消費が組み合わさると、開発ツールは悪用の魅力的な標的となります。特に、攻撃者が私たちのマシンを使って攻撃をさらに広めることができることを考えると（例えば、開発マシンに保存された認証トークンや、開発者が作成したソフトウェアを通じて）、その危険性は高まります。
開発者であることはやりがいのある仕事ですが、リスクも伴います。プロジェクトに貢献するためには、本質的にその作成者を信頼する必要があります。なぜなら、npm install や make の実行、Java や C# プロジェクトのビルド、自動テスト、デバッグといった活動はすべて、プロジェクトのコードがあなたのコンピューター上で実行されることを意味するからです。
私たちの Workspace Trust (ワークスペースの信頼) 機能の目標は、適切なバランスを見つけることです。つまり、すべての人にとって楽しい開発を台無しにしようとする少数の「腐ったリンゴ」から安全を確保しつつ、開発をこれほど楽しくする素晴らしいものをすべて享受し続けられるようにすることです。
ねえ、ただのエディターでしょ？
はい、VS Code はエディターです。しかし、ほとんどの最新のエディターと同様に、より豊かな開発体験を提供するために、ワークスペースのコードをあなたに代わって実行する能力を持っています。
コードの実行とデバッグは明白な例です。あまり明白でないコード実行としては、アプリの起動前に実行される preLaunchTask が挙げられます。これは、ビルドとは無関係な任意のコードを実行する追加タスクを含むビルドを実行する可能性があります。あなたの暗号通貨ウォレットの秘密鍵を盗む npm モジュールはどうでしょうか？簡単な編集をすると、グローバルにインストールされたリンターの代わりに、node_modules フォルダーから悪意のあるリンターが読み込まれます。コードを読むことさえ欺瞞的である可能性があり、攻撃者は Unicode のハックを使って悪意のあるコードを巧妙に隠すことができます。それどころか、乗っ取られるためにソースコードを開く必要すらないのです。
ここでの意図は、世の中にある素晴らしいツール（VS Code を含む）からあなたを遠ざけたり、転職を促したりすることではありません。インターネットからダウンロードした、信頼関係のない個人や組織によって書かれたコードには、多くの攻撃の機会があるという認識を高めることです。
もぐらたたき
上記のすべてのシナリオにおいて、ツールは設計どおりに機能しており、悪意のないコードベースでは非常に生産的です。デバッグ前にアプリをビルドするための preLaunchTask を設定すれば、変更のたびにターミナルから手動でビルドする必要がなくなり、大幅な時間節約になります。リンターは、各チームの好みのコーディング ガイドラインやスタイル（そう、タブかスペースか）をサポートするために高度にカスタマイズ可能です。コミット前のフックを使えば、何かを忘れていないか確認したり、コミット前にテストが実行されることを保証したりできます。
さて、これらすべての攻撃に同時にさらされる可能性は低いでしょう。実際、VS Code を通じた悪用は（まだ）発生していません。なぜなら、新たな機会が生じた際に私たちに知らせてくれる素晴らしい専門家コミュニティが存在するからです。Workspace Trust 以前の私たちのアプローチは、各シナリオを脆弱性の発生時点で、局所的な許可プロンプトで対処することでした。
例えば、Jupyter 拡張機能は、ノートブックでビジュアライザーを開くと埋め込み JavaScript が実行される可能性があることをユーザーに警告していました。
ESLint の脆弱性は、ワークスペースの読み込み時に実行されるため、厄介なものでした（これが最初のモーダルダイアログでした）。
これが、結局のところ、負け戦であることが判明しました。ユーザーは、ワークスペース全体に適用されない、複数（で少しずつ異なる）の許可プロンプトに中断されます。あなたを信頼し、あなたも、あなたも、あなたも、あなたはダメで、あなたは火曜日だけ信頼する、といった具合です。私たちにとっては、脆弱性が露見するたびに別のプロンプトでそれを塞ぐという、絶え間ないもぐらたたきゲームです。
そこで、私たちが VS Code を構築する際に従うパターンの 1 つは、ツールや拡張機能全体で同様に、しかし一貫性なく実装されている体験は何かを見極め、それをコアに組み込めないか検討することです。信頼のプロンプトはこのパターンに従っていたため、ツールと拡張機能の両方が利用でき、（うまくいけば）より明確なユーザー体験を持つ体験と API を構築することを検討することにしました。
信頼
知らないうちにコードが実行されうる様々な方法についてご理解いただけた今、なぜ私たちがこの質問を最初に投げかけるのか、よりよくお分かりいただけたかと思います。
私たちが特に、このワークスペースの作成者を信頼するかどうかを尋ねるのは、VS Code がコードが悪意のあるものかどうか（ほら、私たちは 1 と 0 しか分かりませんから）、それがどこから来たのか、あなたがプロジェクトに貢献するつもりがあるのかどうかなどを判断できないからです。
一方、あなたは賢く、そのコードがどこから来たのかを知っています。あなた自身（OK）、あなたの会社（たぶん OK）、あなたの友人カイ（場合による）、あるいはインターネット上の見知らぬ誰か（絶対にダメ）。
その知識が、ツールをより賢くするのに役立ちます。もし作成者を信頼するなら、素晴らしい！ツールや拡張機能は自由にその役割を果たし、魔法のような体験を提供することができます。そして私たちは二度とあなたを煩わせることはありません。
もし信頼しないなら、あなたは私たちに「気を付けて VS Code、どんなコードも実行しないで」と伝えていることになります。これが私たちが制限付きモードと呼ぶもので、潜在的に有害な機能が無効化されるため、あなたはより安全にコードを閲覧し、最終的に情報に基づいた決定を下すことができます。
でもあのダイアログが！
お気持ちは分かります。あのモーダルダイアログはかなり大きく、設定するアクションを取らない限り、新しいフォルダーを開くたびに表示され続けます。
私たちはこのデザインから始めたわけではありません。ESLint のモーダルダイアログ騒動を振り返り、視覚的な手がかりと、できるだけ遅延させた単一の通知プロンプトを使って、ブロックしない体験を提供できないか自問しました。私たちは、目立たないように、制限付きモードで（あなたがほとんど気づかないうちに）開始し、最後の瞬間に信頼を尋ねるプロンプトを表示したかったのです。
私たちは、ワークスペースを信頼するかどうかを伝えることができる「パッシブな」信頼通知を導入しました。ワークスペースが信頼されていないことを示すために、設定の歯車アイコンを拡張したり、新しいセキュリティ アイコンを導入したりするなど、様々な UI 処理を試しました。
Insiders ビルドを使用すると、Workspace Trust で話しているような、VS Code の新しい体験の最新のイテレーションを得ることができます。Insiders は毎日出荷され、私たちは VS Code をビルドするためにそれを使用しています。
そのアイデアは、ユーザー（あなた！）が自分のタイミングで、ワークスペースの信頼を許可または拒否するかを決定できるというものでした。ツールや拡張機能が本当にアクセスを必要とするときにのみ、ワークスペースを信頼するかどうかを尋ねる通知を表示するのです。
さて、皆さんの多くが同意してくださると思いますが、VS Code は私たちが「通知疲れ」と呼ぶものに少し悩まされています（約束します、私たちはこれに取り組んでいます 😊）。私たちのテストでは、人々は単に通知を無視することが分かりました。ユーザーは歯車アイコンの通知や、新しいセキュリティ アイコンにさえ気づきませんでした。利用データは、パッシブな通知を通じて信頼が許可される率が非常に低いことを示していました。ユーザー調査では、人々が何かを壊してしまったと思い込み、期待通りの状態に戻そうとトラブルシューティングに時間を費やすのを見ました。
私たちは目立たず、できるだけ遅らせるつもりでしたが、現実には、制限付きモードの間、製品は壊れているように感じられ、人々はそれを自分のせいだと考えました。これは私たち双方にとって良い状況ではありません。
あなたにコントロールを
フォルダーを信頼するという決定は、VS Code の機能に根本的な影響を与えるため、すべての調査の結果、フォルダーを開こうとしたときにすぐに信頼の質問をすることが正しいと判断しました。モーダルダイアログは邪魔になるため、いくつかの質問に答えるだけで、最終的には日々の作業でプロンプトを見る頻度がはるかに少なくなるように、ダイアログを強力にすることでバランスを取ろうとしました。
私たち自身のドッグフーディングや他の開発者へのインタビューを通じて、人々は一般的に、すべてのソースを置き、信頼できると考える主要なフォルダーを持っていることが分かりました。そこで、ダイアログから直接親フォルダーを信頼する機能を追加しました。ワンクリックでそのフォルダーとすべてのサブフォルダーを信頼でき、その後は信頼プロンプトが再び表示されることはありません。
ワークスペースの信頼エディター
ワークスペースの信頼エディターは、何を信頼するかについて追加の制御を提供し、1.58 リリースで更新され、あなたのニーズに合わせて機能を簡単に設定できるようになります。
そして、動作をカスタマイズできるため、信頼エディターにアクセスする方法はたくさんあります 😊。制限付きモードのステータス バー メッセージ、制限付きモード バナーの管理リンク、歯車メニューをクリックするか、コマンド パレット（F1）を開いてWorkspaces: Manage Workspace Trust (ワークスペース: ワークスペースの信頼を管理) コマンドを使用します。
ワークスペースの信頼エディターから、現在のフォルダー、親フォルダー（およびすべてのサブフォルダー）、そしてマシン上の任意のフォルダーを信頼できます。
また、すべてのワークスペースの信頼設定にすばやくジャンプして、体験を微調整することもできます。
私たちがWorkspace Trustをどう使っているか
歯のフロスを好む人はいませんが、それが正しいことだと知っているから私たちはそれを行います。セキュリティについて考えたい人はいませんが、それが正しいことだと知っています。体験をカスタマイズすることで、開発体験を楽しいものに保ちつつ、開発に内在する脅威から自分自身を守ることができます（楽しいフロス？！）。
VS Code チームのほとんどのメンバーは、信頼するソースで作業するトップレベルのフォルダーから始めます。例えば、私の Mac では、GitHub の Microsoft 組織から取得したすべてのソースを ~/src フォルダーに入れています。私は ~/src を信頼できるフォルダーとして指定し、その下のすべては本質的に信頼されます。~/src/vscode や ~src/vscode-docker などを開くと、私の組織が書いたり利用したりするコードを信頼しているため、完全な信頼状態で開かれます。
私は ~/scratch (「scratchpad (メモ帳)」の略で、もちろん好きな名前にできます) という別のフォルダーを持っており、そこには他のすべてを入れ、デフォルトで信頼されていないものと仮定しています。そして、フォルダーごとに信頼の決定を下します。
ワークフローをスムーズにするために、私は "security.workspace.trust.startupPrompt" 設定を "never" にしています。
この設定により、モーダルダイアログは表示されず、ワークスペースは直接制限付きモードで開きます。私はすでに ~src/scratch フォルダーを信頼しないと決めているので、サブフォルダーを開くたびにプロンプトを表示する必要はありません。読んだり書いたりしているコードを信頼すると決めた場合は、2回のクイッククリックでそのフォルダーで信頼を有効にできます（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 チームと協力して、検証済みパブリッシャー、署名、プラットフォーム固有の拡張機能など、拡張機能エコシステムにさらなるセキュリティをもたらすための作業が記されています（私たちはこれを「信頼できる拡張機能」と呼んでいます）。要するに、Workspace Trust は良い拡張機能が良い決定を下すのを助けるものだと考えることができ、信頼できる拡張機能は悪い拡張機能からあなたを守るのに役立ちます。
VS Code をオープンに開発する利点の1つは、コミュニティが最高の体験を創造する手助けをしてくれることです。ですので、可能な限り邪魔にならないようにしつつ、安全を保つ手助けをするために、このフローをどのように改善できるか、ぜひお知らせください。既存の issue に（丁重に！）コメントしたり、新しい issue を提出したり、@code にツイートしてください。私たちは耳を傾けています！
よろしくお願いいたします。
Chris と VS Code チームより
ハッピーコーディング（安全に）！