Here's the "airtight hatch" article folks are referring to: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldn

Here's the "airtight hatch" article folks are referring to: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31... Phishing does involve an insider being confused and letting someone in, though. The question is what a vscode user could be tricked into doing. That part of the explanation could be fleshed out more? I'm also reminded of how browsers do defense in depth. The "airtight hatch" argument implies that second-level security is worthless because the first level is secure. Having a useful binary already there on the system might be useful for chaining with another exploit? But that assumes a developer environment can be made into a low-privilege container, sort of like a browser's render process. I don't think many people work that way? Perhaps someday we will work in containers and code editors will be locked down like browsers. The most straightforward path to that would probably be for the code editor to run in the browser. That's something VS Code can do, so a policy that says you must use a browser-based version of VS Code might actually work for some organizations?