[creepycrawler]

The world was already there, your bubble just burst. In recent decades tech companies and their programmers have done everything they can to collect data about users. Are you now surprised that the same companies apply the same practices for technical users of their software?

The solution, at least for me, is to remove that software from my life. Personally I vowed a long time ago to never work for a company whose business is to track people. It's no big deal for me, but I understand at least some may have hard decisions to make.

[alkonaut]

Being able to monitor the system is one of the big reasons to move to web based applications (another being e.g. ease of deployment).

If monitoring of the application isn't possible (And by possible I mean reliably statistically so opt-out not opt in) then that will drive the shift to centralized/web based applications even faster.

Ironically, those who are most wary of telemetry tend to be the same people who also appreciate being able to run local software over web based.

[creepycrawler]

Not sure what your point is. With regards to the last sentence, I don't see the irony. People who don't like being tracked like local software, yes.

[alkonaut]

The irony I mean that the tracking will be there regardless, the suppliers of software will use "we can't monitor the app sufficiently at end users unless we centralize it" as the argument of not making client side software at all.

[nishs]

That's an overarching claim.

I write some paid local-only software, and I have no trouble not tracking users or usage. For example, here's the entire privacy policy for one of them:

> App does not collect any data.

> App works completely on-device. Messages do not leave your iPhone and are not shared with other apps.

> The essence of this privacy policy will not change.

--

For another software, the privacy policy includes details such as:

> App never uses the Internet, except to check for updates.

> Automatic update checks can be turned off in the application's preferences. Requests to check for and to download updates happen only through the domain domain.example. The updates server does not store or forward potentially identifying information, such as request IP addresses or user agent strings.

> License keys, obtained upon purchasing App, do not contain personal information, such as names or email addresses of license holders. License keys are validated locally; App does not use the Internet to validate license keys.

[NoGravitas]

Well, we'll just have to make our own then, won't we?

[tom-thistime]

Genuine question: How is that ironic? I'm simply not following, which happens to me a lot.

[alkonaut]

I mean that as a group, people who crusade against monitoring of client software on end users' machines, will in the long run be accelerating the shift towards more software being web based.

If I'm deciding between a desktop and a web client for my software, monitoring is a concern. If I suspect I'll either a) not get enough opt-ins for montoring or b) end up in a publicity shitstorm if I use opt-out, then I'll just opt to run the software on my server instead.

The amount of monitoring and tracking that is done on server side software is obivoulsy going to be a LOT more than what "anonymous usage data" would be for the client version. And that's a bit ironic (that it might have the opposite effect).

Obviously scenario isn't about this software specifically. A compiler isn't going to be "web based" tomorrow. It was more a comment about the software landscape and the privacy debate in general.

[mindslight]

Microsoft has been pumping out proprietary crapware for decades, while those of us who cared about freedom and security have continued to ignore it, despite it even being pop culture at times.

The lack of basic ethics on this topic is a great example of what people mean when they assert that software engineering isn't real engineering. Software should represent the interests of its prospective users, period. Inserting anti-features that directly go against the interest of the user to benefit the author is a violation of trust, and is blatantly unethical.

But sure, keep convincing yourself that if users don't like you violating them a bit, it's just naturally pragmatic to abuse them even worse. Either way whatever you create can't be considered trustworthy.

As for the original topic, the real problem is that it would be a rug pull - classic Google. If this were a new language built with surveillance in the compiler, nobody would use it. But if the maintainers decide to add in hostile features after the language has gained wide adoption, it will take a lot of churn to sort out, fork, sandbox, etc.