Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VSCodium – An Open Source Visual Studio Code Without Trackers

fossmint.com

Post reply on HN
Print view View original

211–220 of 265 posts

Re: VSCodium – An Open Source Visual Studio Code Without Trackers

#211

Post by type0 »

paavoova wrote: post #120
eridius wrote: post #113

Earlier quoted context omitted.

I just read through that issue, I see nothing wrong with the responses. First was an acknowledgement that when opted out they were still sending an unnecessary "user opted out" telemetry event and that it would be removed. Then indicating that subsequent network connections were for update checking, and extension update checking, and finally an explanation that while they can disable telemetry in the app, they can't…

I used past tense, and the parent comment I replied to writes "just disable the telemetry", linking to the same FAQ the OP of the linked issue tried to follow to disable telemetry. The VSCodium docs (linked in an above comment) mentions baked-in telemetry. Presumable this refers to the binaries rather than the source code, but then the issue is two-fold, being telemetry in the source and telemetry Microsoft may inser…

> and telemetry Microsoft may insert into the binaries.

This is the main problem as I see it and MS hasn't been transparent in question on what can actually be added to the binaries which bring us to the necessity of fork such as VSCodium.

Re: VSCodium – An Open Source Visual Studio Code Without Trackers

#212

Post by type0 »

nindalf wrote: post #155
prepend wrote: post #128

Earlier quoted context omitted.

Tracking should always be opt-in, not opt-out. I base this on expected user preference and trying to optimize for user happiness and functionality. I don’t think this is as true for non-OSS software where the purpose is likely more toward revenue generation than community and user functionality.

First, please let's draw a distinction between different kinds of tracking. We're smart enough to appreciate the naunces here. Some information is more valuable than others. * How many times you clicked Edit -> Paste vs Ctrl/Cmd + V. This is not personal information. It cannot be used in any way to identify you. * Your location/medical information. Guard this with your life if you must. Share it with literally no one…

> Fourth, products that collect this info become better. If you're ok with webapps collecting this but not native apps (like VS Code), then the consequence might be that web apps end up being much better than native apps.

So what? VScode can also be used as web app already, it's not about what others do or don't with their online services. The question is about the expectation and respect to the end user, having telemetry on by default is disingenuous to say the least.

Re: VSCodium – An Open Source Visual Studio Code Without Trackers

#213

Post by mkl »

naikrovek wrote: post #172
mkl wrote: post #125

Earlier quoted context omitted.

Where is the log stored? All I can find online are some instructions that seem out of date as they don't refer to the interface I see (or I don't understand them): "You can inspect telemetry events in the Output panel by setting the log level to Trace using Developer: Set Log Level from the Command Palette." [1] The "page" in settings consists of just two options, and the complete descriptions of the types of informa…

Windows has an overarching telemetry collection system and VSCode might use that on Windows. There is an application in the Microsoft store you can install that lets you view all telemetry collected by Microsoft, and the actual data is encrypted. The metadata (which tells you WHAT is being collected) is not. Knowing the people I have worked with in the past, this is to securely prevent modification by users before th…

Thanks. The app is called Diagnostic Data Viewer.

Re: VSCodium – An Open Source Visual Studio Code Without Trackers

#216

Post by luckylion »

jlgaddis wrote: post #202
luckylion wrote: post #142

Earlier quoted context omitted.

> They (and remember, these people are supposedly developers) either ignored it, or just didn't read the docs. Or they forgot and their stance on it changed. I vaguely remembered (or thought I did) having seen it. Just checked my settings and it's disabled. I've gotten way more privacy minded in the last 24 months, so I figured I might have said "yeah, you can collect data" back when I first installed it, but now I'd…

> A middle way would be to periodically remind people ... Almost nobody will do this because, if they do, they know people will turn it off. It's the same reason commonly given for making tracking (or "telemetry", as they call it) opt-out and on by default, instead of requiring users to opt-in -- "if we have it off by default and ask users to enable it, pretty much nobody will". They may very well be correct but, to…

Yeah, I believe you're right. It might be a matter of framing. If you show me the value of collecting telemetry data, what good decisions you've made because of it, how you got rid of that annoying thing plenty of users complained about because you saw that it affected a large group of users and wasn't just a loud dozen etc, you might sell it to me.

Most data collection for "analytics" is just about you as the product owner optimizing the product for whatever goal you want to, engagement, sales, ad clicks, retention or what have you. I as a user that provides the data gain nothing from that and, being the target of those manipulations, I might actually lose (by spending more time on your site than I wanted to etc), but if you can show that I give data = I get better product, I don't think I'd be that hard to convince.

I don't know if VS Code does something in that regard (if they do, they don't communicate it effectively enough to reach me), but I do like their approach in general - I once read through an issue where they discussed changing some component for a more advanced one and pretty much everybody agreed that the newer one was better, but they still had a few words on "how can we measure that? how can we make sure that it's not just us devs that work on this thing all day and it won't be the same for the people using it in their daily life on all kinds of experience levels". I liked that a lot (so much so that I still remember it months after reading), but apparently not quite enough to enable telemetry data ;)

Re: VSCodium – An Open Source Visual Studio Code Without Trackers

#217

Post by bpicolo »

Memosyne wrote: post #124
timdorr wrote: post #3

Is this needed? You can disable telemetry from the settings: https://code.visualstudio.com/docs/supporting/FAQ#_how-to-di...

VSCode initializes the module they use to collect telemetry (Application Insights / A.I.) even if you disable that setting [1]. 1. https://github.com/Microsoft/vscode/issues/63404

They explicitly created a tech debt issue to fix that, seem reasonable to me?

Re: VSCodium – An Open Source Visual Studio Code Without Trackers

#219

Post by bartread »

This is nice and all but, from my perspective, the biggest issue with VSCode isn't the telemetry but the battery drain. Even though I prefer VSCode to Sublime the negative effect on battery life, particularly for sizeable projects, forced me back to Sublime for most use cases.

Re: VSCodium – An Open Source Visual Studio Code Without Trackers

#220

Post by Vinnl »

Nullabillity wrote: post #176
Vinnl wrote: post #151

Earlier quoted context omitted.

One of the more flabbergasting comments I've seen is when Mozilla removed ALSA support from Firefox because nobody stepped up to maintain it, and the metrics showed that it wasn't widely used. There were people complaining about it being removed, and stating that the people who did use it were more likely to have turned off tracking, and thus did not show up. I mean, sure, it might be the case that there were indeed…

So now we need to allow surveillance, just to prevent the biased data set from ruining the software even more?

No, you don't need to do that, but if you don't, you should realise that that results in biased data, and thus influences the focus of development. If you have an alternative other than "the developers should just magically guess what would make users happy", then I'd be happy to hear it, but otherwise, that's just the way the world works, and thus that's the trade-off you will have to make.
Post reply on HN