[dijit]

Why is it, when people have legitimate complaints about something on hacker news (in this case the fact that what is delivered as a binary is not what you see as source code), people are so quick to side with the tool for being trustable?

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.

[delta_p_delta_x]

It is very interesting how everyone rants about trust, but they are perfectly happy running their 'open-source' code on closed-source CPUs (Intel, AMD x86-64, Apple M1, etc) with closed-source firmware, and raves over how they 'don't know what a flag does', and how they want or even have 'full control' of their computers and the code that runs on them, which is not remotely true.

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.

[dijit]

To be perfectly fair, people are extremely displeased with x86 hardware back doors. So it’s not exactly the same as the way you present it.

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).

[kuschku]

> perfectly happy

That’s an assumption you made, and it’s a wrong one.

[jterrys]

I'll be straightforward and say that as a whole, I do not trust an operating system in which one of the first configurable options it presents me are whether I want to toggle my 'advertising ID' on or off.

As a result, quite honestly, I wouldn't trust any product produced by that company.

[bmitc]

On the other hand, why are so many so quick to jump on the distrusting side? For example, people on here lost their minds with the Warp terminal having telemetry, but none of it includes any of the terminal input or output, which makes it harmless. But telemetry apparently equals some horrific deed. These exact same software developers likely lace the hell out of their apps and systems with telemetry, a mention of which that is probably buried in some user agreement somewhere.

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.

[Barrin92]

>How do you know that flag does anything except attempt to hide sending of telemetry?

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.

[3np]

I'm sure we're in a minority but some of us do actually build things like this from source (common for Gentoo, Arch, Guix, and NixOS) and do a quick cursory glance of source changes on every upgrade/rebuild. For a flag like this I may dive into the code of the version I'm running and take a look what's going on.

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.

[epicide]

> 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.

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.

[dijit]

Maybe you. Maybe others.

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.

[glogla]

> Why is it, when people have legitimate complaints about something on hacker news (in this case the fact that what is delivered as a binary is not what you see as source code), people are so quick to side with the tool for being trustable?

Corporate bootlicking.