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