News for hackers. Stuff that matters.
Re:Visual Studio Code is designed to fracture by philonoist on Wednesday August 31, 2022 @01:39AM (#32658781)
Even developers are taken for a ride. Just like WhatsApp and Chrome, it all comes down to ripple effects of "If others didn't use it, I can't". I have given a number of examples of this stubborn sticky monopoly below.

Every newbie while learning to code: scared of reviews on internet like "I couldn't get help with this editor online or with colleagues and I can't risk being stuck on this project so I switched to VS Code"

Every newbie while interviewing: impress interviewers even by a little chance that they use the "industry standard" tool to code.

Every experienced developer, even on this HN post, says "It doesn't have excellent support like VS CODE, in remote development, centralized marketplace, etc."

I have pieced together and my conclusion comes from the observation below. There is a reason enterprise, rather than startup world use M$ products. The power and money to fight for fairness.

Their C#/.NET compiler is open source and excellently designed but with a secret tunnel to nefarious practices to use when needed[ like closed source]

VSCODE is open source but with a secret tunnel to nefarious practices to use when needed[ like telemetry and extensions where the real power lies, being closed source]

Phone and App market but to with a secret tunnel to nefarious practices to use when needed[ it is going to be based on android like Edge on Chromium]

VStudio is best IDE but to with a secret tunnel to nefarious practices to use when needed[ like telemetry + closed source extensions + Heavy + slow + whatnot!]

MAUI is Wowza! tool with a secret tunnel to nefarious practices to use when needed[ like repackage old Xamarin in new branding]

OneNote is the best note taking app ever but with a secret tunnel to nefarious practices to use when needed[ like lock in using obscure format and closed source]

Every company they acquire but with a secret tunnel to nefarious practices to use when needed[ Embraaace Exteeend Extin...]

Re:Visual Studio Code is designed to fracture by nindalf on Wednesday August 31, 2022 @02:44AM (#32659144)
> VStudio is best IDE but to with a secret tunnel to nefarious practices to use when needed[ like telemetry + closed source extensions + Heavy + slow + whatnot!]

It’s telling that you needed help from “whatnot” to pad out this list.

In what world is “Heavy + slow” a nefarious practice? Even assuming this is true, all of us have written software that was far from perfect. There wasn’t anything nefarious about either situation, it was only people trying to ship software under time constraints. That you ascribe evil intentions to some software being slow says more about you than them.

Telemetry - so much digital ink has been spilled on this. Not one person I’ve asked can actually explain what’s wrong with this. What would actually go wrong if performance and usage metrics are sent to their server. “But they can be deanonymized!” Ok, let’s assume they can. Now we know it takes your computer 40ms to load the side bar, 20ms to create a new in-built terminal, and the version control screen crashes every time you open it. What now? How does this actually change anything?

You folks complaining about telemetry think your job is done when you say “telemetry is nefarious”. But I can’t see a path for exploitation of this data in any way. No doubt you’ll tell us how. When doing so, please let’s assume that Microsoft is compliant with GDPR.

Lastly closed source extensions - OP makes a compelling case that this is how we’ll end up with just one online editor. Yeah, I definitely see it. That’s the one thing I’ve been convinced of.

Re:Visual Studio Code is designed to fracture by barrysteve on Wednesday August 31, 2022 @04:55AM (#32659906)
I appreciate your good nature around telemetry, but as we have seen meta-data is trivial to abuse. The military kills people with metadata. Performance and usage metrics can tell the server when the client is being used and for how long. Combined with a license tied to a real name (or a billion other ways of IDing a person and computer), telemetry is just another way to die by metadata.

Nevermind the face-value argument of performance and usage data turns into "give me a debuglog that includes every program you have open, a whole bunch of personal computing hardware information which can be trivially tied to PII".

The argument that telemetry and server-side knowledge is safe entirely depends on reducing the argument down to an idealized metaphor that doesn't exist in practical reality, and then rejecting all forms of evidence that don't fit the mould.

Unfortunately in this scenario, telling the truth about what needs to be kept private, is in itself, a clue to what is being kept private. So no communication can happen back up the chain if the client wants to keep something private. When the server becomes untrustworthy, so must the client.

Re:Visual Studio Code is designed to fracture by nindalf on Wednesday August 31, 2022 @05:11AM (#32659998)
Thank you for your response.

> telemetry is just another way to die by metadata.

If your threat model is a cruise missile from the military, then I actually agree - don’t use VSCode. For the rest of us who don’t live in fear of being murdered by a violent government at any moment, it’s a reasonable trade-off.

I don’t see how I could be de-anonymised by these logs but I’m happy to be proven wrong. If you could cite which metrics are being collected and how you would de-anonymise someone with that data, that would be great.

Re:Visual Studio Code is designed to fracture by barrysteve on Wednesday August 31, 2022 @05:33AM (#32660101)
I agree I have nothing to fear from the military. I would have hoped that example would show not that I am afraid of cruise missiles, but instead that very serious decisions at the highest level of government are being made from this information. You can bet your bottom dollar that all other high-levels of management, government, religious groups, ect have the same mindset towards the "privacy of metadata". I'm sure you'll plead ignorance of direct evidence of offenses right now and not historical, as reason enough to ignore practical truth..

Being de-anommed from logs is ez pz. https://www.youtube.com/watch?v=Fj6wfGcKFlI https://www.youtube.com/watch?v=7EaCnhC0mc0 https://www.youtube.com/watch?v=MQL1jrm7Vzk

There was another talk by a german lady where they de-anommed everybody in their data set, including a german judge who was looking at porn during his chambers sessions, almost like he was addicted. They brought this information to him and it was kept under wraps.

Nobody is safe from this stuff, it only takes 3-4 peices of unique information (not matter how tiny) to statistically add up a probable identity with a high degree of confidence.

Re:Visual Studio Code is designed to fracture by nindalf on Wednesday August 31, 2022 @06:23AM (#32660378)
I’m not saying de-anonymisation is impossible. Obviously it is.

I’m asking you to

1. Tell us what VSCode collects that’s so sensitive

2. Show us how you’d de-anonymise a person with that information (but I’m willing to concede that this is possible)

3. Demonstrate harm from knowing that a specific person is tied to a set of VSCode logs.

Don’t hand wave #3 away. Don’t assume that it’s self-evident that the harm is high. You’re talking in such vague terms that it’s impossible to respond. So be clear and concrete. What specific harm comes from the specific data that VSCode collects, assuming that it’s de-anonymised? Don’t talk about a random German judge. Talk about me, a developer using VSCode.

Re:Visual Studio Code is designed to fracture by barrysteve on Wednesday August 31, 2022 @07:32AM (#32660831)
I rewrote this comment a couple times before posting, as getting through to your perspective rules out what I consider logical common sense. You're still asking the wrong questions because you don't get the process.

VSCode could collect anything at all, but let's be hypothetical, yet specific so you understand the process. I'm going to use these two pages as reference [0]This RoboLeary blog post describes what VSCode collects (more than just performance, but we'll leave that for now) and [1]This Github repo shows an example log file of just the telemetry data you can voluntarily opt out of.

[0]https://www.roboleary.net/tools/2022/04/20/vscode-telemetry....

[1]https://gist.github.com/robole/97f6e1c4dc888ae0a49a7683e5494...

In the github example log file, there's 9k lines of code, with thousands of xml style entries with properties. Those properties can be any value you want for the purposes of de-anom. It doesn't matter what it is.

Your database back at Microsoft HQ (or wherever this stuff goes) will have a huge ocean of telemetry logs, so how do we find out which one is yours? See below.

In those thousands-of-entries, some of them will differ statistically from the average of all log reports. It could be the time it takes for a menu to load in milliseconds, it could be the filepath of an extension, it could be a specific hardware report, it could be a collection of exceptions that keep throwing. It doesn't matter what it is, it matters that it differs from everyone else.

Some of those reports that differ from the herd (statistical average) can be collected together to make a fingerprint of an individual machine. Maybe your machine always takes slightly longer than average to open a menu, or has a different extension set, whatever. The tiniest difference is still a difference.

This fingerprint of your machine can be correlated statistically to be likely the same machine again and again across telemetry logs, across time. Your fingerprint keeps showing up across multiple logs, across multiple days, we know a time of computer usage. The fingerprint does not need to be perfectly separated from every other fingerprint in the bell curve, but we can solve that later on. As long as it's narrow enough (only so many conflicting fingerprint reports) we can narrow it down with added metadata.

How do we know who is running VSCode and doing this work on this fingerprinted machine? All the other 'harmless' metadata like IP address, VS licenses, Microsoft accounts, linked email addresses, and most importantly all the data harvesting Microsoft will not let you turn off.

So this isn't a problem right? Who cares if Microsoft can trivially (and likely automatically) de-anonymize me. No junior engineers have access to the data, only Edward Snowden et al. can see it, so who cares?.

Management can easily take access to the database of fingerprints and build analysis tools and programs the end user and the junior engineer alike, cannot see or understand what decisions are being made from it. So if you and I (assuming we're both grunts in software) can implement a perfect telemetry system that collects "no useful category of information" and the database is kept from public eyes, we can both still lose out on what management does with that information, as there is more to be revealed in it than we want.

So if military is happy to kill people based on metadata and our advertising data is being sold left-right and centre and insurance and health data is going haywire, what assurance does any computer user on a windows machine, or VSCode user have, that their data is not going to be used to make decisions arbitrarily (from the end user perspective) against their will?

If I don't want VSCode to know that I'm working on a project at 3am, that's my business and revealing what Harm that causes and why I might want to keep that private, reveals a clue about what is being kept private, and thus cannot be shared. Steve Jobs would have completely removed the collection of meta-data from secret product development teams and no-one would have batted an eye. When a random joe does it, there's all these questions about what Harm does it do, as if someone had no reason to keep a secret after Steve died.

If you want transparency from the rank-and-file, get it from what decisions management is making with metadata too and tell me what Harm Does It Cause Microsoft Management To Reveal Their Truth. Heaven forbid I suggest reality is a two-way street.

Re:Visual Studio Code is designed to fracture by crazyjustin on Friday September 02, 2022 @08:50AM (#32690023)
Thank you for taking the time to type this out. I've been uncomfortable about telemetry data for a while but this makes it clear to me that it can be used to do a lot more than just drive ui changes. Google has been fingerprinting in this way for decades. Of course Microsoft can do the same.

I've been thinking about trying VSCode. I'm the only dev I know at my org that doesn't use it and I guess it's going to stay that way.

I really don't understand the mindset of some folks. In this dynamic Microsoft has all the power and therefore the burden of transparency and proof of good will should be on them. Why would you give away information about yourself freely to an entity with no oversight. There is no reason to trust a corporation with your personal data.

Re:Visual Studio Code is designed to fracture by nindalf on Wednesday August 31, 2022 @10:53AM (#32662813)
Ok so what I’m getting from your comment is that since this data could be linked to you … bad things could happen. Unclear what those bad things are, but it could be anything, even a cruise missile. Unclear why someone would do this thing, but sure.

I get that this seems common sense and logical to you, but it doesn’t to me. Just because it’s possible doesn’t mean it’s going to happen. And arguably, 60%+ of all developers dont seem convinced either.

If you’re concerned about this and want industry level change, you need to work on this pitch. It’s not very convincing.

Re:Visual Studio Code is designed to fracture by philonoist on Wednesday August 31, 2022 @03:33AM (#32659403)
>In what world is “Heavy + slow” a nefarious practice?

In M$ world and Apple's world( XCode). 2022's version was the first one to do a 64-bit release and became news titled - "awesome!", "Woah!", "amazing!", etc. [0]

VStudio had nothing unique to it that the Rider din't have, but corporates and developers loved it because they could compensate by throwing some costly hardware and I must point out that it is usually from Intel that M$ is in monopoly in consumer and enterprise market. Apple is just the same, but it gets away being close to the *nix world.

"performance improvements and bug smashes" are just fodder for despair that masquerades as hope, which could have been done away with long ago. Users report them and even showed what exactly could be done down to bits and bytes, but these thigs sleep there for a decade. All you need to do is create a developer account and search "for 10 years" or "since a decade" in their forums. Frustrations pour out and in galore.

"Don't be evil" - Google

"Be devil and also pull your greatest trick" - M$

[0]https://stackoverflow.com/questions/2516436/visual-studio-64...

Re:Visual Studio Code is designed to fracture by nindalf on Wednesday August 31, 2022 @04:04AM (#32659592)
> because they could compensate by throwing some costly hardware and I must point out that it is usually from Intel that M$ is in monopoly in consumer and enterprise market.

It’s unclear what you mean by this sentence. Are you saying Microsoft somehow benefits if we buy more Intel? So there’s a developer at Microsoft who wrote in their performance review “yes, I’m proud to say that I worsened the experience for Microsoft users, but it’s ok because that leads to sales for Intel”.

Leaving aside that Intel is playing catch up in the processor market now, do you actually believe this?

Anyone else reading this comment - this is why it’s impossible for me to take these folks seriously. They concoct these conspiracy theories that are only slightly more logical than flat earth.

Re:Visual Studio Code is designed to fracture by oaiey on Wednesday August 31, 2022 @01:56AM (#32658881)
That is not EEE. But monopolistic behavior.
Re:Visual Studio Code is designed to fracture by philonoist on Wednesday August 31, 2022 @02:00AM (#32658900)
Yeah, I mean it keeps on adding to the list of complaints and M$ won't budge.