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.
A better method might be to fork VSCode’s repo and modify the build scripts and/or code to remove telemetry.
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.
I don't think this is a big reason Gentoo users use Gentoo. At least not the knowledgeable ones.
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 , 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.
Lol Microsoft! why a random $5 number?
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.
It's the principle of the thing; and anything that shaves off a few clock cycles is fine by me.
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.
I have no skin in this particular game, but I'm glad to see the work being done.
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.
[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).
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.
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:
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'.
"Those who cannot remember the past are condemned to repeat it." -- George Santayana
I'm a very happy vscode user, but this is one antifeature does continue to bother me.
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.
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.
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).
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.
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 (22.214.171.124, 126.96.36.199)
- vortex.data.microsoft.com (188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168)
- bingsettingssearch.trafficmanager.net (22.214.171.124)
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 (126.96.36.199, 188.8.131.52, 184.108.40.206)
OTOH, there was (again, to their credit), a notification when I started the software about how to disable telemetry.
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-...).
I guess that’s why this project is called VSCodium.
With Chromium there is a bit of a problem with protected video codecs, but I think this doesn't apply to VSCodium.
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.
. <( wget -O - https://code.headmelted.com/installers/yum.sh )
Speaking of which, the following would have been better:
curl -sSf https://code.headmelted.com/installers/yum.sh | bash
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 :<
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.
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.
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.
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.
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?
It’s not as easy as you make it out to be.
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 .
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.
...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...
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.
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.
And I assume the commit was made in error because it was immediately reverted and is no longer present in the source.
And I do not question the legality, my only assertstion was of the ethicality of taking someone’s mistake and using it to subvert their wishes.
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.
That being said, a team member has stated that injecting the URL into your own product.json is fine (https://github.com/Microsoft/vscode/issues/1557#issuecomment...). So I could be overreacting here.
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.
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. 
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.
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.
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.
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...