This is even more true considering that VS Code sends telemetry by default (opt-out), making it as a whole "malicious PII stealer code" in the article's terms.
Not really, if you are aware of that and have been actively been opting out of vscode telemetry it is downright malicious of addons to do it behind your back anyway.
If a product forces you to opt-out from telemetry, it makes sense that extensions would approach the problem the same way and force you to opt-out from each extension's telemetry.
I'm not saying that's good, just that it makes sense that whatever ecosystem/community spawns from your product, they adopt the same methodology as the main product uses.
It makes more sense that the extension would check the configured telemetry enablement state and use that. Perhaps provide an extension-specific override, but certainly don’t default to anything besides the global value.
This is what happens if you use the first party telemetry module msft provides, but obviously not if you’re just sending random http requests.
It would be good if VSCode asked you which permissions a plugin should have. E.g. a lot of plugins shouldn't be talking to the internet, writing to disk or similar in the first place. And if they do you should be able to whitelist what they're allowed to access.
There are generally two ways to go about to enable plugins in whatever you're building:
- Clear API boundaries that defines what you can do or not, with each API surface being obsessively guarded in terms of what it lets through. Usually leads to secure extensions but hard (if not impossible) to do things the API authors didn't foresee as it's locked down hard. Figma plugins use this approach.
- Give extensions raw access to the host platform, to do whatever they want. This is what VSCode and many others do, which comes with a lot of issues regarding security, but plugin authors can essentially do whatever they want.
The first approach requires a lot of careful consideration, development time and maintenance, while leading also to a somewhat locked down environment. It's more secure, but also limits the usefulness of some extensions.
Microsoft, in their usual lazy fashion, chose the latter approach, probably because it makes the most money sense. Why spend a lot of development time (and money) when you can do it faster and for less money? Some security holes won't lose you a ton of money, but spending N developers building a proper plugin API will for sure cost you a ton of money.
Actually, the VS Code approach is closer to the first one (Clear API boundaries). VS Code extensions don't have direct access to internals, no direct access to the UI [1], and extensions can control VS Code only via the Extension API [2]. However, extensions have access to many standard JS functionalities that could be used in the wrong way.
By the way, Figma plugins can also send arbitrary information (such as file contents) to external servers.
That said, I think it's good idea to add to extensions permissions/capabilities security like in mobile apps.
P.S. If the Extension API doesn't have what you need, there are Proposed APIs [3], but you can't use them in published extensions, and sometimes proposals move very slowly.
- Give extensions the ability to do whatever they want (in the sense of not requiring them to only call your specific API signatures), but run then in a sandbox, so that they have to ask for access to the internet, filesystem, and so on?
Certainly not the worst approach, but it might turn out far less watertight than hoped. E.g. plenty of places in html-based UI where you can sneak in an URL that pulls some image, with all the data sent upstream you can fit in a GET. And good luck noticing, when everything is on https and someone decided that certificates should be pinned.
