Hi Isidor, excited for this! At Open VSX, we'd love to take a look and potentially flag the extension as malicious on our side as well. Are you aware of the version range that the malicious code was included in? I'm asking because https://open-vsx.org does not have any version published since the extension went closed-source.
Obfuscating Javascript is entirely unnecessary: it signals that the author thinks that they have something to hide.
At the very least, the author has delusional notions about the greatness of their source code and they worry about piracy, meaning that there is a high probability of stupid bugs and that they would be difficult to notice because of the obfuscation.
Of course in this case the default assumption should be that there is something malicious to hide.
For sure legal. Technically, it's extremely simple to change the Marketplace in VS Codium, but it is against the ToS of Microsoft's Marketplace to change it to theirs (see https://github.com/microsoft/vscode/issues/31168#issuecommen... for more details). As the linked comment also states, this is a big part of the reason why Open VSX was created and is widely used by VS Code forks.
Why would this be an issue? The code itself can't agree to the ToS, so only people using it could possibly do so, and depending on how the connection is set up, they might be able to skip agreeing to the ToS since that's just a client-side construction in MS VS (I hope).
So then the user can make the change, and then it's the user's ToS violation.
If the publisher makes this change in public then it's their ToS violation with receipts. I don't think you're really arguing that the VSCodium folks should make this change in violation of the ToS, sign it, and package it up...
They have built this whole alternative ecosystem so they can be in compliance.
It is a bit puzzling to me that this would be an issue, since extensions generally do not call any VS Code binaries, they should ideally access everything through the VS Code Extension API (https://code.visualstudio.com/api) and never call any VS Code-related binaries, since VS Code can run on a portable mode as well. If issues like this arise, it is most likely a fault of the extension itself, so reporting should be done on a repository or an issue tracker of that extension. I have never seen an extension call the `code` binary, so I would guess it could realistically only be helpful for some kind of a workaround for an API limitation.
If you have any of these extensions that break on VS Codium, could you please share them with me? I would love to dig for more and help towards fixing said extensions there.
The discrepancies you mentioned come down to the extension Marketplace used - in VS Code, it is the Microsoft VS Code Marketplace, but in VS Codium it is by default https://open-vsx.org/ (basically a FOSS alternative to the Microsoft one).
The names don’t match up, because on Microsoft’s Marketplace the author handle (display name) is used, but Open VSX returns the username as the author name. The username of the author 周鹏 is bung87 on both the Microsoft Marketplace and OpenVSX. I think this is a good thing to reconsider though and thanks a lot for sharing!
> with only 3.9K downloads
The difference in the download numbers is as simple as the Microsoft Marketplace having their own install counter; Open VSX has less users and therefore less downloads for the extension.
It is true that Open VSX’s approach can be potentially dangerous, since an extension A on the VS Code Marketplace does not have to be the same extension A , it is built on the belief that people will be taking only their namespaces. The verification check mark can help on Open VSX extension pages with this, but it is not available on the VS Code side (yet anyway :)). The Rails extension you mentioned has the checkmark, so it means that it is published by someone who is a part of the project. You can take a look at how it looks like on the extension page: https://open-vsx.org/extension/bung87/rails.
Open VSX (and perhaps VS Code Marketplace) might consider adding support for identity verification through Keyoxide[0]. This would allow interested parties to easily determine whether the user bung87 on Open VSX and the user bung87 on VS Code Marketplace are really the same person and not just someone claiming the same username. There is already support for linking Keyoxide to one's GitHub account and even Hacker News, among other service providers.
Main Keyoxide dev here. That's an interesting suggestion, could be very useful! I don't have much experience with Open VSX or VS Code Marketplace. Do they have APIs for accounts?
I'm not affiliated with either, but from looking at some of the extension pages on Open VSX it appears they use GitHub accounts exclusively for publishers—so that part is already handled by the existing GitHub/Keyoxide integration. For VS Code Marketplace, the publisher pages do include a description section which could be used for the identity proof but there doesn't seem to be a (documented) REST API.
Hi there, I took a look at your site home page and docs, and still can't figure out what it is, or why someone would want to use it. Do you have a link to a 10,000 foot overview / simple use-case explanation, for a short-bus person such as myself?
"Keyoxide allows you to prove "ownership" of accounts on websites, domain names, IM, etc., regardless of your username.
That last part is important: you could, for example, be 'alice' on Lobste.rs, but '@alice24' on Twitter. And if your website is 'thatcoder.tld', how are people supposed to know that all that online property is yours?
Of course, one could opt for full anonymity! In which case, keep these properties as separated as possible.
But if you'd like these properties to be linked and, by doing so, establish an online identity, you'll need a clever solution.
Enter Keyoxide.
When you visit someone's Keyoxide profile and see a green tick next to an account on some website, it was proven beyond doubt that the same person who set up this profile also holds that account."
Thank you. That's easy enough to understand, even for me ;-) The only piece that might use a bit more illumination, is what kind of people are likely to use Keyoxide to check on your proof of ownership once you've set it up, and why they would do so.
"The names don’t match up, because on Microsoft’s Marketplace the author handle (display name) is used, but Open VSX returns the username as the author name."
I know it's insignificant, but that seems like a relatively easy and (marginally?) useful thing to change ;)
It also speaks to a fundamentally broken development process. This sort of thing shouldn't make it through wireframe review because it breaks the core tenet of building a competitor: not fucking with your users' expectations. Something as minor as changing what user handle is displayed was probably hand waved away, if it was even considered, yet here in this thread we have a demonstrable case of a user losing trust and confidence in the project simply as a result of this decision. If you want to convince people to use your software instead of what they're already using, you have to be as close to seamless as possible in all areas that aren't a benefit. In a case like this, the transition from the proprietary marketplace to the FOSS marketplace should be entirely seamless, and every UX change (even if it's an objective improvement, which this is clearly not) from what MS is currently doing represents lost users; the value comes from ethics, not software, so don't fix what isn't broken.
This isn't a huge issue, but it's one of the larger issues why FOSS alternatives are not often as well received as their proprietary counterparts (see: unix). Consumers/users should be the first/only consideration when designing user-facing software, but it's a rare sight to see in FOSS. I wish more FOSS developers cared about the software instead of the code, because the difference manifests in decisions like this.
> Something as minor as changing what user handle is displayed was probably hand waved away, if it was even considered, yet here in this thread we have a demonstrable case of a user losing trust and confidence in the project simply as a result of this decision.
If displaying the same "author" data resulted in users assuming that a given username on the Open VSX site should be trusted just because it happened to match a username on the VS Code Marketplace, it's probably a good thing that Open VSX displays the name differently. These are two different sites, and two different accounts; trust in one should not imply trust in the other. It would be even better if Open VSX could somehow ensure that the displayed author names never match the corresponding projects on VS Code Marketplace, for example by integrating a domain name or other globally-unique component into the author field.
Hmmmm. What about swapping `display_name` + `account_is_verified` for `display_name` + `display_name_is_verified` or alternatively `display_name` / `verified_display_name`? The idea being to tie the verification mark to the display name, not just the account.
Such a scheme could then enforce policy in the verification process that imposes restrictions on what the display name would be allowed to be.
Hi Isidor, excited for this! At Open VSX, we'd love to take a look and potentially flag the extension as malicious on our side as well. Are you aware of the version range that the malicious code was included in? I'm asking because https://open-vsx.org does not have any version published since the extension went closed-source.