VSCodium: Binary releases of VSCode without MS branding, telemetry and licensing
github.comIf 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.
Never trust a binary more than you trust the person who built it and the channel you downloaded it through.
A better method might be to fork VSCode’s repo and modify the build scripts and/or code to remove telemetry.
The repo has the scripts that are used to compile the binaries. It's not even a fork, it just downloads the code directly from the official repo.
Gentoo’s biggest failure to me is in persuading people that building from source is somehow safer than binaries.
Never trust a source code repository more than you trust the people who commit it and the channel you downloaded it through.
Autoupdates from a source repository that you don’t review before accepting updates are no safer than autoupdates from a binary source.
> Gentoo’s biggest failure to me is in persuading people that building from source is somehow safer than binaries.
I don't think this is a big reason Gentoo users use Gentoo. At least not the knowledgeable ones.
> 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.
Shameful FUD
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.
[1] https://info.microsoft.com/rs/157-GQE-382/images/Microsoft-l... [2] https://open.microsoft.com/2018/06/07/github-acquisition-mic...
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."
Lol Microsoft! why a random $5 number?
Finally. It obviously is something that flies over the heads of most people here at least by reading the comments. This is great.
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.
Some of us want to write code without shipping a bunch of usage data / telemetry / whatever back up to the Mothership.
It's the principle of the thing; and anything that shaves off a few clock cycles is fine by me.
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.
VS Code already provides mechanisms to disable all background network activity.
Defaults matter. They matter even more given Microsoft's demonstrated history of quietly adding new telemetry and metrics which are enabled.
I have no skin in this particular game, but I'm glad to see the work being done.
Are you sure? This is what MS says about it:
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.
You may need to wait for next week’s release. But it is made easy in the current insiders.
Since apparently it’s going over a lot of heads (including mine), can you explain why this is important?
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.
They can't be distributed in distro package managers which usually require everything to be foss.
Depends on the distro. For the main Debian repos, it's true. Others like Arch are more lenient, e.g. Arch packages the Steam client.
It's worth noting that VS Code is only available in the AUR:
[visual-studio-code-bin](https://aur.archlinux.org/packages/visual-studio-code-bin/): Original binary from Microsoft
[code](https://aur.archlinux.org/packages/code/): Build from latest release source code
[code-git](https://aur.archlinux.org/packages/code-git/): Build from latest Git commit
The versions that build from source (`code` and `code-git`, AFAIK have telemetry disabled).
Are you sure arch distributes them? Like oracle jre, proprietary packages are downloaded during installation, i think debian non-free works similarly.
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.
How different is this from Chromium and Chrome?
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.
? VSCode is definitely free in the "beer" sense.
Sorry, I mean "free software" I wasn't talking about price.
Ah gotcha! Apologies, then. I probably should've read a little more closely.
For me, it's more about telemetry than licensing.
Doesn't it suffice to set the following in your User Settings?
Honestly I'm very happy to give telemetry data. Microsoft is doing so much to improve the experience, they can make it better with some data."telemetry.enableTelemetry": falseIf you want to send as little data as possible to Microsoft there are other settings to consider:
"telemetry.enableCrashReporter": false, "code-runner.enableAppInsights": false, "update.channel": "none", "extensions.autoUpdate": false, "extensions.ignoreRecommendations": true, "workbench.settings.enableNaturalLanguageSearch": falseYour list is incomplete. From the most recent VSCode changelog @ https://code.visualstudio.com/updates/v1_26#_offline-mode:
Offline mode
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:
update.channel update.showReleaseNotes extensions.autoupdate extensions.autocheckUpdates extensions.showRecommendationsOnlyOnDemand workbench.settings.enableNaturalLanguageSearch workbench.enableExperiments telemetry.enableTelemetry telemetry.enableCrashReporter git.autofetch npm.fetchOnlinePackageInfoWhat stops Microsoft from adding new settings tomorrow?
Or from re-enabling disabled settings with an update, like they've done with Windows 10.
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.
Honestly, I don't see the point of this 'fork'.
>> ... Honestly, I don't see the point of this 'fork'.
"Those who cannot remember the past are condemned to repeat it." -- George Santayana
https://bigthink.com/the-proverbial-skeptic/those-who-do-not...
I'm actually old enough to remember Microsoft's past. But I'm not so old I'm cynical enough to think ill of their ongoing OSS efforts.
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.
Ah, that is a fair point. I hadn't looked at what they collect, I was just speculating about what they could collect if desired.
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 used to be at least one issue about this, and of course it has been fixed by now: https://github.com/Microsoft/vscode/issues/16131
Can you share the firewall rules/domains to block to disable telemetry for VSCode?
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:
- dc.services.visualstudio.com (40.114.241.141, 52.169.64.244)
- vortex.data.microsoft.com (40.77.226.250, 65.55.44.109, 51.141.13.164, 51.140.40.236)
- bingsettingssearch.trafficmanager.net (13.95.93.152)
I actually have no clue what the last one there is (Bing)—I must have known at some point, but have long forgotten.
Notable exceptions allowed: marketplace.visualstudio.com (13.107.6.175, 191.238.172.191, 13.85.19.92)
> I actually have no clue what the last one there is (Bing)
workbench.settings.enableNaturalLanguageSearch
Telemetry should not be on by default without express user consent.
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.
AFAIK telemetry can be disabled with "telemetry.enableTelemetry": false
isn't it agains't GDPR having it be like that?
An opt-in is required under GDPR for personally identifiable information, not "any data ever".
Anonymous/aggregated data collection is allowed under the GDPR, though this data collection should still be made clear to the user (and it is on https://code.visualstudio.com/docs/supporting/FAQ#_gdpr-and-...).
wouldn't downloading and agreeing to the eula suffice for purposes of this?
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.
If there's people that use Chromium binary builds, there's people that will use this.
Makes sense for inclusion in package repositories.
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.
You can replace “VSCode” with “Chrome” and “Microsoft” with “Google” in your comment.
I guess that’s why this project is called VSCodium.
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.
Removing telemetry adds a lot of value. To each its own, I guess.
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.
It doesn't look like a fork to me. It only seems to be a build script for building VS (and possibly remove some anti-features).
Nice idea.
With Chromium there is a bit of a problem with protected video codecs, but I think this doesn't apply to VSCodium.
Hopefully they don't start letting plugins show video ads.
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.
To me, that's a feature.
Was a bit of a hassle to get popular video platforms running ;/
Related: https://code.headmelted.com/
Strange way of downloading and executing the installer. Most usually you see either
1. Pipe it to an instance of sh or bash, or
2. Download, mark executable, run.
Instead, what they do is they run wget in a subshell and redirect the output of the subshell as input to the source builtin command.
Don't really see why though.. <( wget -O - https://code.headmelted.com/installers/yum.sh )Speaking of which, the following would have been better:
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.curl -sSf https://code.headmelted.com/installers/yum.sh | bashIf 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 :<
Nice! I don't use VSCode, but I know a few people who do and I’ll gladly point them to this build.
Doesn't have the latest build for macOS. :(
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.
Right now it’s out of the question.
> 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.
What ISO? And where?
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?
It’s not as easy as you make it out to be.
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...
https://www.insanelymac.com/forum/topic/329828-making-a-boot...
> 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?
All Hackintoshs violate MacOS license. You cannot run MacOS on anything else than a Mac or it's just pirating the software.
Enforceability of EULAs depends on where you are.
Thankfully you don't have to do any of that (for any platform), thanks to Travis! https://travis-ci.org/
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.