Freedom from telemetry/tracking and license on released binary.
"telemetry.telemetryLevel": "off"How do you know that flag does anything except attempt to hide sending of telemetry? Or not even that, simply logging that you would prefer not to have telemetry taken.
The EULA explicitly forbids you from attempting to reverse engineer the binary, so you’re literally taking this on blind faith.
Don’t you find that troubling?
Even if Microsoft didn’t have a murky track record with telemetry in their operating system (being randomly turned back on or never being completely turned off): the default position should never be to trust.
Trust is earned.
Corporate bootlicking.
As a result, quite honestly, I wouldn't trust any product produced by that company.
I don't but neither does anyone who runs VSCodium because they also run a random binary from the internet without having any idea whether that binary is in fact compiled with the source code provided, and I have the suspicion nobody who runs it has read that code either.
This is classical security theater where people will run binaries from basically anonymous people on the internet and claim this is more trustworthy than running something provided by Microsoft.
So with a sample size of one I can tell you that "nobody" is false.
Even not doing that, just the fact that I can know that it's built from a known tag from master on a public high-interaction git repo makes it a completely different story than downloading some arbitrary binary.
I don’t though; so this effort is somewhat beneficial. Despite the fact that it’s really lacking in some features.
Though: that is quite telling to be perfectly honest. Some components can’t be replicated without proprietary elements- which indicates that there’s a lot more binary blobs than normal.
I’ll admit to not looking at the code, as I do not currently use vscode.
With a large enough group of "anonymous people" [0] inspecting the code, the chance for a security hole, intentional or otherwise, lowers [1]. Notice that this is NOT a guarantee by any means -- it's a chance. [2]
Contrast that to a blob of binary code with a EULA stating you aren't allowed to inspect it. There are obviously non-malicious reasons for doing that, but it doesn't (and shouldn't) sow trust. So some people don't trust it. They are not irrational for doing so.
In terms of probability, I would put my money that Microsoft is overall better than the median set of developers at writing code with fewer technical bugs. However, I would also bet that they are more likely to intentionally add in more telemetric data than they let on, and/or misrepresent what toggles and settings actually change.
Whether I actually (can) read even a single line of code does not change any of that. Just the fact that someone can view your code has a large effect on how you write it [3].
We can talk all day about whether specifically VSCodium meets some threshold of actual reviewers/auditors, but that's not the point.
[0]: There are established lines of trust via things like: comment history, other projects, and even other commits. FOSS devs aren't (always) just purely anonymous.
[1]: "Many eyes make all bugs shallow"
[2] This also says nothing like "all FOSS is created equal" or that "projects with thousands of contributors are magically more secure".
[3]: And yes, of course that could mean they just obfuscate it more. But that still takes more time and effort, reducing the chances/number of cases, and increases the chance of detection.
Microsoft publishes a detailed article on what Visual Studio Code telemetry is, how to disable it, and even how to view the telemetry events going out.
https://code.visualstudio.com/docs/getstarted/telemetry
I'm not really sure jumping through hoops and developing and maintaining a crippled open-source app is the sane, default response here. It's likely a waste of time and a very, very, very small percentage of Visual Studio Code users will use it.
At the risk of running into a slippery slope, unless one single-handedly:
- audits the entire codebase for some open-source OS;
- audits the entire specification for an open-source ISA, and an open-source implementation of said ISA, such as RISC-V BOOM;
- locally compiles the audited codebase on the audited CPU, targetting the audited ISA;
one cannot claim to say 'I want to know what that flag does'.
For all we know, Intel might have NSA backdoors and might 'phone home' to some server. I understand the idealism behind 'trust is earned', but at some point, trust has to be given, because unless we are willing to make some serious compromises, we will never be in full control of the complete hardware-software stack.
That’s an assumption you made, and it’s a wrong one.
Though I agree overall, I’ve read the code (and compiled) the operating system I use day to day, but that seems to be uncommon apparently, and I’m not above just trusting some package maintainer.
That said: trust is still earned, and easily lost.
There’s a lot to indicate lost trust in Microsoft (despite the fact that I did say in my parent comment that it’s separate from the point).