Hacker News Reader

Comment by Tyriar | Hacker News Reader

Hi all, I work on the VS Code team. This came up the other day in stand up and the initial plan was to deprecate and eventually remove the old setting. Several of us pushed back and said while we may deprecate the setting in favor of something else, the old setting should always be respected due to the sensitivity around telemetry.

If there's any confusion around this messaging it's because this discussion literally happened 2 days ago. I'll reopen https://github.com/microsoft/vscode/issues/134660 to make sure we clear up confusion.

View on HN

Just some feedback from the field: I work with some high-security networks, and the perception from those Microsoft customers is that whatever "good" that has come from Microsoft improving security in general has been completely undermined by the pervasive telemetry.

Windows 10 alone has something like 200 individual settings for disabling its various forms of telemetry. Office adds several dozen more. Dotnet itself has telemetry, then PowerShell on top of that. VS Code and Visual Studio both send telemetry.

On and on, and on... and then some more, and on... and ON and ON and...

There's just no end to it.

As administrators, it's like playing whack-a-mole against a thousand moles that are breeding exponentially.

We don't want to play this game any more.

Noted. I can't speak for anything other than VS Code but we have the toggle in product which is all you need to change to turn it off for the core, extensions may have their own setting or share the core toggle, but we often can't control that.

There's also the very detailed page on the website detailing this as well as how to see all telemetry events that are sent in real time in the output panel and even how to print out a report of all events that get sent with their classification (code --telemetry).

I'd like to express the same sentiment against all-pervasive telemetry in a far less civil way but dont want this comment deleted.

I really wish I could use stronger language though....

This

If you're interested in collecting feedback and passing it on, the other criticism I have in this area is that Microsoft's privacy policies are incomprehensible. Everything seems to refer to the same huge document in the first instance and that document seems to depend by reference on numerous supporting documents. Even figuring out which supporting documents might be relevant seems to require understanding ambiguous terminology about whether any given application or service fits into various categories.

Personally, I'm not interested in messing around with that kind of nonsense. I don't want to engage a lawyer just to find out if I can safely run some software and in the modern world where we're dealing with things like personal data and sensitive business information (including code and clients' proprietary information used to write it) an organisation with Microsoft's recent track record on privacy isn't going to get the benefit of the doubt.

With all this backlash on telemetry, is it worth it? What are you actually getting from it beside ruining the progress MS has made with the dev community? Trust is hard to earn and takes seconds to lose.

Remove it. Then champion removing it from the rest of MS’s products. If you must spy to learn your market, you should not be in that market.

I still hold onto a Sublime Text license waiting for the day MS shows it’s true purpose of making VS code free. Has this day come?

Telemetry is like bureaucracy. Once you have one it's extremely difficult to get rid of it.

No, but they're selling remote wipe to large enterprise customers on worker's device's, spying on workers privacy and selling that info to management, adding DRM to excel spreadsheets - but they just can't figure out how to have multiple customers editing the same document without losing data.

I've worked on a place where somehow Teams managed to f@ck double clicking on an excel spreadsheet. Across organizations. On a sensitive critical infrastructure planning document.

"we sell you 4 different communications and productivity enhancement software products, none of those are really any good but guess what, we managed to upsell your organization into purchasing this crap "

"and look, your competitors purchased this and they're using it (they weren't), so you need it too for compatibility reasons"

Like what I heard from a colleague:

"If I've been called here, I can safely assume whatever's been done's been done wrong, otherwise I would not've been called here, cause I'm definitely not the cheapest option"

It's high time OSs try and implement something akin to what DoNotTrack was intended to do in web browsers. Of course it will have the same adoption issues faced by DNT, but if first-party apps (like VSCode, DotNet, and PowerShell under Windows) honored a centralized setting it would make life so much easier.

Well, for Windows there is https://www.oo-software.com/en/shutup10 to help manage telemetry and other settings, though the OS resets certain user choices after updates.

Though, if possible, consider using GNU/Linux whenever possible - distros like Debian have historically had little controversies around them, even package popularity metrics are presented as a choice to you during install time: https://popcon.debian.org/

Certain other distros like Ubuntu have a bit more controversy surrounding them, for example, the snaps package mechanism which takes away the user's control over updates by default, though that's more of a security hole and a stability risk, rather than aggressive telemetry related (unless it's introduced by the package creators, a la Audacity's plans that were later rolled back https://github.com/audacity/audacity/pull/835).

Of course, if you truly care about your privacy and open software, you might as well use a fully GNU distribution, such as Trisquel, though there are factors like hardware compatibility and software availability which could pose challenges in such cases: https://trisquel.info/

This almost exists.

Windows comes in many flavours. The most "just stop it, okay?" version is the Long Term Servicing Channel (LTSC).

It's like the Windows you used to like, back in the XP days. No Xbox gaming bar or Minecraft. Minimal (no?) telemetry. No forced updates every 6 months that break things randomly.

In my line of work we used it a lot for things like virtual desktop fleets with thousands or even tens of thousands of instances Why? Because the "normal" builds would every now and then just 'decide' to force update themselves despite our best efforts to stop that. All at once. On an ephemeral environment, where the machines would reset on boot, and then try to apply the forced update again. And again, over and over...

Some Microsoft manager wanted their KPIs met, so they just.. rammed something through. Fuck everyone running a VDI fleet, a billboard, a kiosk, a test environment, or anything that needs any kind of stability at all. Big man at Microsoft needs a bonus for that new Tesla!

This was common practice in our line of business. LTSC or failure, those are the options.

Meanwhile, Microsoft, whenever they turned up to a customer site, would just keep harping on about how LTSC is not intended for users, how it's "bad", and how the six-monthly releases provide Enhanced Experiences(tm) or whatever. They would stop just short of calling us unprofessional in front of our customers. Just.

It was the most absurd thing to watch happen. The disconnect between Microsoft and their customers is almost comical now...

LTSC as of 2019 also includes telemetry now. You get the same choice as on regular Windows: all telemetry or just the basics

The reason is that Microsoft as a company is all-in on "data-driven" everything. They're trying to get their customers to adopt this approach too (and mostly succeeding, our company execs are constantly going on about it). Disabling telemetry breaks this so they make it as difficult as possible. Because that's where they're planning to have their major value-add.

I really hate it too. But it seems so be so heavily anchored in their strategy that I don't expect them to lighten up about it.

It makes sense as selling cloud and data analytics solution is the new hottie for today's corporation world.

As devs dont often hear feedback - you guys are doing a great job on VSCode. There are some key issues that Code overcame compared to other IDEs, which is why so many teams use it. One of those is forced telemetry (others are pricing, integration, and memory / resources footprint).

Please continue to push back against moves towards forced telemetry. Some of us work in sensitive environments, others wish for privacy. For those of us that work in sensitive environments we could simply firewall the program to stop talk back, but that will likely break many other things. Currently we have a level of trust that strikes a good balance between over the top strict security and permissive security where there are few issues because Code is trusted from a trusted domain. Forcing telemetry is likely to have Cybersecurity teams flag the app at an enterprise level and start to introduce headaches as they start to try and curb information leak.

Really appreciate the open responsiveness. I think most people on this site know the position you are in. Dont be put off by irritated people, it's easy to underestimate how much of waking life some people spend dealing with frustrations with specific bits of software.

So we should keep a copy of the old installer around?

Why would you need to do that given what I said?

Presumably so someone installing for the first time can install an older version where they can set the toggle before upgrading to when the toggle is removed?

Maybe there's a misunderstanding. The old toggle is deprecated, but the plan is that you will always be able to use it. The new toggle is just a different setting and can still be used there on newer versions ("telemetry.telemetryLevel": "off").

And how do both toggles combine? Is this the implemented truth table?

  telemetryLevel  newTelemetryLevel  result
  off             off                no telemetry sent
  on              off                telemetry sent
  off             on                 telemetry sent
  on              on                 telemetry sent

https://github.com/microsoft/vscode/blob/be75065e817ebd7b625...

If either are 'off', it's sending no data. The new one also allows you to only send error logs, so the truth table would be more complex.

It used the most restrictive setting. [1]

> @john-aws It does respect your prior settings. If you disabled telemetry before it will still be disabled even though telemetryLevel is set to "on" by default. We always take the most restrictive of the two settings. You can confirm this by setting Log level to trace and seeing no telemetry is flowing in the output channel. The old setting will never be completely removed to prevent enablement of people who previously disabled telemetry but it is deprecated so we recommend setting this new setting to "off" and removing the older settings from your settings.json

So the truth table would look like this :

  telemetryLevel  newTelemetryLevel  result
  off             off                no telemetry sent
  on              off                no telemetry sent
  off             on                 no telemetry sent
  on              on                 telemetry sent

The new telemetry level can be set to Off, Error, On.

The actual code is on github[2] and looks like this :

   const newConfig = configurationService.getValue<TelemetryConfiguration>(TELEMETRY_SETTING_ID);
   const oldConfig = configurationService.getValue(TELEMETRY_OLD_SETTING_ID);
  
   // Check old config for disablement
   if (oldConfig !== undefined && oldConfig === false) {
    return TelemetryLevel.NONE;
   }
  
   switch (newConfig ?? TelemetryConfiguration.ON) {
    case TelemetryConfiguration.ON:
     return TelemetryLevel.USAGE;
    case TelemetryConfiguration.ERROR:
     return TelemetryLevel.ERROR;
    case TelemetryConfiguration.OFF:
     return TelemetryLevel.NONE;
   }

[1] https://github.com/microsoft/vscode/issues/134660#issuecomme...

[2] https://github.com/microsoft/vscode/blob/be75065e817ebd7b625...

Yes. Those get harder to find every day unless you know exactly where to look. I also wouldn't put it past them retroactively patching builds to cover them up.

Reply on news.ycombinator.com