If I needed a one-time “use it and lose it” attack vector, this would be an excellent way to provide one. Imagine how many thousands of code repositories I could _successfully_ inject a backdoor into, using only a repackaged “without the telemetry” version of Microsoft’s code. Y’all are far too trusting.
Edit: The point is that we all have a blind spot around risk assessment and threat evaluation when it comes to certain software topics, such as code editors and terminal software.
> I don't think this is a big reason Gentoo users use Gentoo.
Exactly. The two most compelling reasons to use Gentoo are/were: 1) It's a rolling-release distribution and 2) it offers customization by virtue of building from source. I don't think I've seen the argument that it's more secure--not seriously anyway. I used it back then because I wasn't a huge fan of Linux and Gentoo seemed more familiar to me with its ports analog.
Perhaps part of the OP's confusion is the hardened profile (or similar)? I'm not sure considering their wiki currently advertises it as risk mitigation [1], but I haven't used Gentoo in probably 6-7 years (at least not consistently outside a VM) so my memory on this is likely wrong.
To clarify: Gentoo did no harm. Many Gentoo users cited the risks of prebuilt binaries in their evangelism of Gentoo. That perceived risk remains an undercurrent in people’s thinking today, even though we’ve generally since realized that prebuilt binaries aren’t the risk we were led to believe they were back then. I blame the Gentoo evangelists of yesterdecade for this persistent “anti-binary” mindset, not Gentoo itself.
Thanks for doing this. This will be the canary that tells us whether Microsoft is really changed like they claim. Since they call themselves "in love with open source" [1] and letting Github "remain an open platform" [2], I expect them to not remove this project from Github. If they do remove it, whatever reason they give about wanting to provide the best possible VSCode experience is bullshit and Github will no longer be a home for open-source projects.
No way would they risk the backlash of taking this down. It wouldn't come close to taking 1% of VS Code non-libre downloads, and as the source code is free software, there is zero legal reason for MS to take it down.
"You can recover from Microsoft and its suppliers only direct damages up to U.S. $5.00. You cannot recover any other damages, including consequential, lost profits, special, indirect or incidental damages."
I don’t personally see the need, but the fact that someone can do this should at least once and for all settle how “real” the open-sourceyness of VSCode is.
https://code.headmelted.com/ Has already done this but without extension support. Support for extensions requires adding content to the product.json beyond what the MIT licenses version contains. This content is traditionally proprietary, but the author of this repo managed to find an instance where it was mistakenly committed and is using that to justify it being MIT licensed now. Whether you agree with this is up to you I guess. I personally would object to using someone’s mistake to subvert their teams wishes.
And for either of these projects, I wouldn’t use their products without first verifying they are what they say they are. I’d do this by downloading the vscode repo and building directly from source then comparing. But at that point I have two of the same thing (hopefully), so not sure why this is needed in the first place.
Microsoft is heavy into data-backed development right now. They're making decisions about were to put resources, and even what buttons to keep in toolbars, based on how many users are clicking them.
This seems to have lead to development of products and features that get a lot of excitement here on HN so maybe it's not all bad.
Data Collection. The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, as described in the product documentation.
I appreciate this effort and am not suggesting it's not necessary. Just curious: are there any known ill-desired effects of the MS binaries? My understanding is that it's just branding and telemetry that can be turned off.
The MS binaries are licensed in such a way that you're not allowed to redistribute them, if I'm interpreting https://code.visualstudio.com/license correctly. There are some other legal restrictions. So those binaries are technically not FOSS, which means a lot of people won't use them out of principle, and it may even be a bad idea to mirror them.
I don't see the beneficial element to this project. Visual Studio Code is opensource, free of charge and used by millions at this point, why would anyone want another license just because of the license alone?
The source license and binary distribution license are different. The source code is MIT licensed; nothing wrong with that. Great license for this. The binaries are provided with a different license that also covers components from third parties that may not be in the vs code repo as well as telemetry and other data gathered.
If for whatever reason you don't like this license, you can build from source. This project seems to do that and remove all of the MS branding and telemetry. There are only a handful of commits on the project so it does not look like it is massive change. The big question is whether that adds enough value and whether this project will make enough effort to keep it's fork up to date.
I agree that for the vast majority of users, using the official binaries should be perfectly fine. MS did a fine job with this product. But nothing wrong with having the choice.
Looking around, this repo is just a few ~10 line shell scripts. Very simple, and it isn't a fork of vscode. It clones the Microsoft repo directly and builds it from that.
For use in FLOSS distributions like Ubunutu or Debian. Like how Firefox got rebranded as [Iceweasel/Icecat](https://en.wikipedia.org/wiki/GNU_IceCat) so their logo/branding didn't have to be distributed by FLOSS distributions.
Actually I think this would be rather useful to have.
I don't use VS personally, but if I understand correctly their binaries are not free even though users can build their own from a free source code. If this "VSCodium" simplifies the building process, and also removes some anti-features in the process such as telemetry, I think it has value.
Some users do not want any outgoing network requests from VS Code unless they specifically invoke features that require online access. To support this offline mode, we have added new settings to turn off features such as automatic extension update checking, querying settings for A/B experiments, and fetching of online data for auto-completions.
Below is the complete list of settings to control VS Code features that make network requests:
They are different products, different teams, different target markets - I've been using VSCode since it was first released, and they haven't done any anything scummy in that time, or given me any reason to distrust them or their motives. All they've done is provide a great product that I love.
The VSCode team is responsive on GitHub, and are driving development based on the feedback and telemetry they receive. I really am a staunch privacy advocate, but I'm not dogmatic about it - telemetry has it's place.
It can also easily be disabled if you don't want to send it.
This doesn't suffice unfortunately. That setting has worked inconsistently, or not at all, and add far as I've seen in my own testing it never disables all telemetry. There have been issues open on GitHub about this for a long time, though it's a few months since I checked there for updates (I stopped bothering and just put it in my firewall rules; I still see blocked connections in thy log today).
I'm a very happy vscode user, but this is one antifeature does continue to bother me.
> @bunderbunder I bet it's still nothing compared to the level of data collection that a typical website does these days.
I'd say the opposite. Consider that (a) you typically visit websites briefly and periodically while most vscode users have it open as long as their computer is on, and (b) Electron provides access to lot more device data than the browser sandbox. The reason websites tend to have such far-reaching and devious user-tracking methods is because they're working in such a restricted environment and have to innovate; native desktop apps have far less restrictions.
Another big difference, though, is that VSCode's telemetry is publicly documented.
So, regardless of what they're able to collect, I know what they are collecting, and how personally identifiable it is, and I know that it's pretty tame compared to what I've seen elsewhere.
Are you sure the additional telemetry isn’t from extensions? Our extensions (Salesforce) have our own telemetry setting, but we do also respect the global VSCode setting due to this exact possibility of confusion. However, I know that there are other extensions that dont respect the global setting.
I tested without extensions back when I was following the open GH issues, so that wasn't the case then.
It could be that MS fixed the issue since, and the connections I see in logs now are from extensions, but I also presume this isn't the case as my firewall rules are IP-based rather than purely app based (since the latter would kill the market browsing functionality).
It really is annoying that they don't make it opt-in instead. They've got plenty of users; I can't imagine they need to be collecting usage statistics from everyone.
I'm curious what would happen if a moderate-size country (say, Belgium) were to pass a law saying that telemetry must be opt-in. I bet it would convince everyone to just be universal opt-in for simplicity's sake.
That said, I bet it's still nothing compared to the level of data collection that a typical website does these days.
There's a lot of traffic that comes from VSCode, so it's sometimes hard to tell which is which—e.g. the autoupdate checker, and the "Code Helper" queries to schemastore to get JSON validation configs for the JSON files in your project, and the NPM queries for package.json
I block most of it anyway, with a couple of individual exceptions, but other than those examples mentioned above, there's also:
It is only without express user consent for those who enter into contracts without reading them. Assuming you aren't one of those people then you consented.
What do you mean? Just to see what you were talking about, I downloaded VSCode from their official website, installed and started it. At no point was I (to their credit) presented with a "contract".
OTOH, there was (again, to their credit), a notification when I started the software about how to disable telemetry.
No. GDPR requires that users must be able to use the service after opting out of data collection (except if the data collection is required for rendering the service to the user). A EULA, in contrast, must be accepted, otherwise the service may not be used.
The VSCode binary release is not open source and not redistributable but rather "source available", and "free of charge" doesn't confer "freedom to tinker". VSCode does have costs associated with it's use, specifically its users' privacy, which they give up by agreeing to Microsoft's data collection terms. You may not value your freedom to tinker or your right to privacy, but the people who run and use this project do.
F the EULA license. That's what VS Code is licensed under when you download from their site, _not_ the MIT license. That's the heart of why this is excellent.
Exactly. I like the idea of having VSCodium as an option but I don’t have an urging need to use this fork since just removing a license and telemetry endpoints doesn’t really add any value compared to the official package.
It would add value if VSCode didn't allow you to disable it and didn't document what data was sent - but it is documented, and it's trivial to disable it if you choose to do so. I don't see the point of this.
Well, with Firefox people were complaining about the removal of ALSA support, with the reasoning that people who liked that were also likely to have telemetry turned off. So a downside might be that your usage patterns are not taken into account when using this or turning off telemetry in regular VSCode - though I'd claim that that is to be expected and completely reasonable.
With these parameters, curl should wait for the whole script to be successfully downloaded, and if it isn't it won't write any of it to stdout. Especially important because the authors of the above mentioned script have NOT wrapped the whole script in a function which is then called at the end of the script.
If the download fails midway and you are using wget -O - or curl without -f then you execute an incomplete script.
Also, executing the script by using the source builtin is annoying because if you answer "no" to the first question asked by this script then it closes your terminal window :<
Disclaimer: general comment. Not affiliated with project, etc.
I don’t know about you, but I don’t typically feel like shelling out $1000 to buy a machine specifically for an OS I don’t use, just to build a binary to non-paying users of free software.
If Apple would provide easily installable ISOs for VBox/VMWare installations (or something equivalent), I might bother setting up a build for it.
> but I don’t typically feel like shelling out $1000 to buy a machine specifically for an OS I don’t use
I keep seeing this argument and it honestly just sounds rather lazy when a few seconds of Googling will point you towards build services you can use without having to purchase a Macbook (for instance, TravisCI has an OS X build environment). Or if you're opposed to cloud-hosted build tools for some reason you could ask users/the user requesting a macOS binary would mind working with you to test your build script(s) for compatibility and mention that Mac users will have to build from source in your README. This whole "well I would if Macs weren't so expensive" sounds like "I just don't want to support macOS" because you have options if you actually were interested.
> This whole "well I would if Macs weren't so expensive" sounds like "I just don't want to support macOS" because you have options if you actually were interested.
Mac development is a bit more complicated than running MacOS on a CI, especially with GUI apps.
And of course code authors prefer compiling programs themselves on their infrastructure. If you want to volunteer and provide a Mac Build then get the source do it and distribute it. But don't accuse people of being somehow lazy for not supporting mac, that's preposterous.
Apple is responsible for the situation. Don't shift the blame away from them.
> Mac development is a bit more complicated than running MacOS on a CI, especially with GUI apps.
And this is a cross-platform project that's not exactly Cocoa-heavy (being based on Electron). The person I responded to did not say anything about creating GUIs either, so I am not sure what your point is.
> And of course code authors prefer compiling programs themselves on their infrastructure.
Which is why Travis, Circle, Appveyor and co have zero users, as we all know.
> If you want to volunteer and provide a Mac Build then get the source do it and distribute it
It's almost as if that was one of the things I suggested - working with the requester to provide a binary
> But don't accuse people of being somehow lazy for not supporting mac, that's preposterous.
I said the argument is lazy, not the people. If for some reason (ideological or whatever) you're not interested in supporting macOS, then say so outright. Don't pretend as though the only obstacle between you and distributing your otherwise cross-platform software for macOS is not having a literal Mac in your hands because there are other easy options, like taking on a contributor or using a build service.
IMHO it's easy enough to find a way if you want to test.
I had to do it a few times in the past and it's surprising how easy it is to run macOS in VirtualBox. Insert ISO, change some configuration, and it boots and installs. Plenty of tutorials and such too.
You mean those hacked ISOs from TPB for 3 year old OSX releases?
How can I, or anyone else for that matter, be sure they are safe to use and represents runtime behavior of the latest ever-changing (read: breaking) OSX?
How can I, or anyone else for that matter, be sure they are safe to use and represents runtime behavior of the latest ever-changing (read: breaking) OSX?
The Hackintosh community has plenty of very knowledgeable individuals who know what they're doing. If someone was trying to pass malware around they would be found out and ostracised very quickly.
You can also find the direct links to Apple's servers if you search. Hint: InstallESD.dmg and swcdn.apple.com .
That’s akin to use hacked or pirated Windows ISOs to build and test Windows-software. And nobody in their right mind would suggest that, right?
Why does different rules apply to OSX?
Also: DMG-files can’t be used unless you’ve already purchased that $1000 machine you don’t really want/need. It’s completely unsupported in any meaningful sense outside OSX.
So more roadblocks.
You know how I get a Windows ISO? I download it from Microsoft. Ubuntu? Download it from canonical. Etc etc.
Can we all agree that it is Apple who put up all these roadblocks?
No other OS vendor makes it harder/more expensive to support their platform than Apple does.
And then you can’t really blame developers for not bothering. It’s all on Apple.
You'd be surprised how many developers got started in the 90s and early 2000s with a pirated copy of MSVC6...
...and if you've been around and done enough, you would know that "unsupported" doesn't always mean "can't be done". The ones who know it can will hack around, play and investigate, explore the limits, and ultimately become better developers by developing these skills of critical thinking and problem solving. Contrast this with the cookie-cutter developers who won't think beyond what they're told and give up at the slightest difficulty.
I ain't no Apple fan myself but I can sure test something in macOS if I really need to. Give this a read...
> You'd be surprised how many developers got started in the 90s and early 2000s with a pirated copy of MSVC6...
Sure, but that was the 90s. Now everyone in the world is connected to the same network, and any security flaw can have critical, global consequences.
Basically, having a "wormable" build and deployment pipeline may have been tolerated back then, but it sure isn't now.
> and if you've been around and done enough, you would know that "unsupported" doesn't always mean "can't be done"
Yes, I'm sure it can be done.
> The ones who know it can will hack around, play and investigate, explore the limits, and ultimately become better developers
That's disingenuous. You only have so much time available, and you cannot do everything which is technically possible. You have to prioritize.
My free and underfunded open-source projects are going to invest the efforts I have capacity for into making a better product for the users, not learning all the ins and outs of running a pirated OS on hardware Apple clearly doesn't want it to run on.
Basically: My point was Apple is putting up lots of roadblocks which no other OS-vendor is, and that if they stopped doing that, maybe you'd see more projects bothering to support MacOS as a build-target.
And really... As a user, would you be happy to be told that the software you are asked to install and trust was built on a hacked OSX copy downloaded from the internet which the developer has no way of verifying if is trustworthy or not? I'm going to assume not.
So why are you making the argument that developers should do just that?
> The cool thing about all of this is that you have the choice to use the Visual Studio Code branded product under our license or you can build a version of the tool straight from the vscode repository, under the MIT license.
The problem is they’ve taken a commit that was obviously made in error, and used that to justify the IP contained within that commit being MIT licensed. Sure, this might be legally sound. But it’s certainly scummy. Especially when you consider it’s acting against the wishes of the team that has been working hard over the past years to make a product loved by so many.
Why assume the commit was made in error? It looks like there has been some discussion and it was done completely on purpose.
You cannot compile the binary from arbitrary commits by yourself and release copies of the compiled work as "Microsoft's VS Code" – that's understandable, unless you work for the VS Code team, why should you be able to do that? There are trademarks. But the source code is MIT licensed and I think you are mistaken about whether that is in dispute or not.
That's a technical response to your technical question. The license is there, in the master branch. I don't see any reverted commit, the code is simply licensed as MIT as far as we can tell.
This is the revert of the mistakenly committed code. In this repository's readme there is a link to a thread where (presumably the author, I didn't check) says that the public should be able to use the proprietary URLs because a commit was made that contained them (the parent of the above), and thus they are open source. While this may be technically true, and legally sound, I still claim it is ethically ill founded. You don't need to share my ethical framework.
I do not want, for instance, see the extension gallery become encrypted as a result of third party applications breaking the EULA. This is a very distinct possibility, and it could prevent people such as myself who normally compile vscode themselves, and download and install the VSIX packages manually, from doing so.
But to me the question is purely a moral one, and a question of what kind of president this sets. I don't believe the community should be trying to find legal "gotchas" in order to get around reasonable limitations set in place by a team, else teams will begin to stop using as permissive licenses as they do.
> able to use the proprietary URLs because a commit was made that contained them (the parent of the above), and thus they are open source
You're right about one thing, I don't need to agree with your ethical framework, especially if it means that somehow a URL that I received with no access restrictions or controls, and publicly available data shared behind it, is somehow afforded copyright protections that would restrict me or anyone who received the link from then re-sharing a link to the URL. The courts in US at least have rejected that argument.
> Fortunately, courts generally agree that linking to another website does not infringe the copyrights of that site, nor does it give rise to a likelihood of confusion necessary for a federal trademark infringement claim. [1]
If I took a copy of what was at the URL and redistributed it without receiving a proper license first, then I could be in legal and ethical jeopardy. But simply putting the URL into the product.json file is akin to linking, and the courts seem to have roundly agreed that a Uniform Resource Locator or a Link is a non-infringing form of protected free speech.
At any rate, I hope you see how I may have mis-interpreted what you actually said, as something other than what you've now explained that you meant. It wasn't clear at all.
The parent of this [1] commit was referenced in a thread linked in this repo's readme. I said this in a different thread, but I'll repeat here: I don't believe the community should be trying to find legal "gotchas" such as this one in order to get around reasonable limitations set in place by a team, else teams will begin to stop using as permissive licenses as they do. This is a matter of ethics for me, as the legal nature of committing to an MIT licensed project is not up for debate. You of course don't need to share the same ethical framework as me.
If you had linked that comment in your first reply, I would have agreed with you and we probably wouldn't have had any of this to talk about :)
A license granted by accident without consideration in return is not a "no takebacks!" situation. If I paid for that license and then you said, it was granted by mistake, I may have a legal leg to stand on in terms of "no takebacks" claims. But if it's just a URL, I'm pretty sure I actually don't need any license or your permission to copy it.
(If you wanted the data that the URL serves up to be protected, then you should have implemented some kind of actual protection scheme, like a token auth system that restricts access to authorized users only, instead of serving that content up to anyone who knows where it is located on the public internet.)
I don't think that's what they've actually tried to do here, so the issue is really moot. Thanks for clearing up what you meant for me, and have an upvote.
My bad. I follow VSCode closely and incorrectly assumed everyone had gone through the same BFS of the the repository as me.
And yes I don’t mind the URL being public as much as the means by which the legal justification was achineved. Reverse engineering is, in some jurisdictions, totally legal, and it wouldn’t be hard at all to simply look at the requests being made by the application. That I’d be fine with. This sort of underhand “got you!” Is what bothers me.
If this[0] is indeed the inadvertent commit we’re talking about...how is that code? It’s three URLs in a JSON file, one of which even contains the string “public”!
There’s no proprietary algorithm being described and I’m guessing that those URLs respond with 200 OK without any authentication of where the request is coming from, which says to me the host thinks it’s okay to send me that data. (On mobile or I would check.)
Would it still be a problem if it were forked and the JSON key names were changed or some other alternative method of configuring the URLs were used?
I would understand if the entire source file for interacting with the extension gallery were taken here, but just a config setting?! That says to me that I couldn’t write my own web browser with the default homepage set to Google without permission...
This just creates more problems than it solves. If you don't like Microsoft's approach to VS Code you're better off choosing another editor to use - there are lots to choose from.
Edit: The point is that we all have a blind spot around risk assessment and threat evaluation when it comes to certain software topics, such as code editors and terminal software.