Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> a good example of the benefit of telemetry

For what it's worth, I have no issues with telemetry as long as they are opt-in and there is transparency on exactly what is collected.

It's having to opt-out (or not being to opt-out at all) and vague explanation on what and why there is telemetry that I take issues with.



And when they abuse their telemetry system for marketing.


... for marketing and monetization.


Opt-in telemetry is nearly worthless for most uses as it's a very biased sample from the get-go.

Crash logs are a different beast.


That hardly makes them worthless.

And very biased towards what? People not triggering bugs?


biased against most users.

opt-in telemetry is effectively the same as no telemetry.

if you have (or anyone has) a problem with crash statistics being tracked via telemetry then I have absolutely zero idea how to convince you that it's a good idea that this blog post doesn't already clearly state.

it's the same with OS updates; people (generally) simply will not perform system or security updates unless they are forced, because everyone thinks they are smarter than the "script kiddies" who would use an attack against them. the user thinks they would see an attack coming and avoid it. in short, they don't. viruses spread, the US Congress calls Microsoft in and asks why the systems weren't patched, and Microsoft says "the users are responsible for patching" and Congress doesn't like it.

so now we are where we are. OS updates are forced after a time, and telemetry is not only the norm, but a very good idea for applications in use by millions of people, like Firefox.


> everyone thinks they are smarter than the "script kiddies"

No. People do not perform system updates because a) it's a chore and b) it get's in the way or even breaks things. To do an update I need to agree to give up control over my device for some time (often undetermined) and then risk that updated code causes issues (it's not uncommon). We need to design apps and operating systems with seamless and reliable updates in mind, not force people to suffer.


Agreed. Telemetry does not solve this problem - and we need to design updates to be smarter, seamless


Or maybe Microsoft finds it's a cheaper and easier to leverage their monopoly position if they operate in "perpetual beta" by rushing out new features before competition can get a foothold, then using their (paying) users as their testers. Rather than, say, testing and hardening their products sufficiently before launch.


The tone you employ - "users" having "a problem", needing to be "convinced" and "forced" - doesn't help. It's reminiscent of PEBKAC [1].

[1] https://www.cio.com/article/274775/it-organization-luser-peb...


> The tone you employ - "users" having "a problem", needing to be "convinced" and "forced" - doesn't help.

My tone here is borne out of users shooting themselves in the foot and then complaining about the pain and inability to walk. At every opportunity that I have taken to give computer users the choice to do the thing that is good for them, the overwhelming majority have failed to make that choice. The people who visit this site are mostly not that kind of person, though there are plenty here who are.

We have shown Microsoft that we simply will not update our operating system or even reboot unless forced. Many, many times we have made this clear, even though patching is overwhelmingly a net positive for both MS and its users, generally speaking, users simply won't do it. They just won't. History bears this out.

Updating is a short-term inconvenience in exchange for long-term security and stability, and people do not think about those things logically. The importance of the immediate future is amplified by a large factor, and the importance of the future is attenuated by a large factor, in most people, especially when it comes to people who view their computer as a tool. Sitting in front of a computer is indicative of a user wanting to complete a task, and manual updates impede the ability to perform that task. That makes installing updates and stopping work to reboot a non-starter for those people. They just won't do it.

I don't know how else to say it. It's not a matter of tone so much as it is a matter of fact.


Thanks for your thoughtful reply, I hope my additional remarks are taken as sincere and not in any way personal, except in a good way.

> My tone here is borne out of users shooting themselves in the foot

Frustration. I hear you. Sure, it's frustrating that they exercise choice (however misguided you see that) and then "complain". It's very nice if you've written code, and even nicer that you care for your customers. But, as developers, they aren't our children. I've been there and it's galling, and feels like a rejection, but to accept what is unrequited is sometimes harder than giving it.

> the choice to do the thing that is good for them,

This is the elitists' dilemma. Please don't be insulted by that word, I'm using it literally and appropriately without value judgement (I am foremost an elitist, and secondarily a peoples' champion, and it is a position that can only ride on a measure of arrogance - which must be tempered)

The fact is, it's not your computer. And that really is the long and short. One must respect that if "users" do not wish to take advantage of bug fixes more speedily available through telemetry, then it's their choice to have suboptimal, buggy programs.

In other news, our children will listen to shit music and get into drugs and relationships we disapprove of etc.

> We have shown Microsoft that we simply will not update our operating system or even reboot unless forced.

For very good reasons. Microsoft have shown themselves to be utterly untrustworthy. I really don't think that's even debatable. And it's a shitshow because I do not believe trust can ever be repaired. It leaves the reality that one of the biggest vendors on the planet is in the position of forcing users because it has squandered the reputation necessary to do good-faith business, to propagate its updates. That's tragic because they probably see no way out except doubling down on abuse, authoritarianism and beating users to their will - and ultimately that confrontation will be the end of so much we have built.

What makes this worse is that security is about more than personal choice (think vaccinations). In other words the damage that Microsoft (and other big-tech abusers) have done goes far beyond simply destroying the individual trust relations with their customers. They've corroded the social fabric of trust in computer security at a more general level - a cost that is incalculable.

> people do not think about those things logically.

You are right. And we should not assume that they should. Emotion is a powerful reasoning tool, and only a fool ignores that force of psychology. Once burned twice shy - and we as developers have been burning a lot of peoples' fingers these past 30 years.

> I don't know how else to say it. It's not a matter of tone so much as it is a matter of fact.

I see it means a lot to you. That is a good thing in itself. You care, which is x10 above the norm.

But we cannot force them to be what we wish them to be. Especially not "for their own good" which is where all tyranny begins. We cannot force people to adopt products, customs, behaviours, sing the party line, or any of that hegemonic nonsense without invoking an age of "consumer communism".

It saddens me that in 2022 we still need to address the patrician attitude. It's not the way forward. It's sad to see such a deterioration. But so long as companies like Microsoft persist a culture of smug superiority, cavalier conceit and intransigent disrespect to the dignity of their users we will have to accept "fuck you" decision making. And frankly, more power to those courageous enough to say it.


> it's the same with OS updates; people (generally) simply will not perform system or security updates unless they are forced, because everyone thinks they are smarter than the "script kiddies

Updates were not the default. And when they became almost mandatory Microsoft started bundling "features" with security updates. That's when people started to disable this "feature".

> so now we are where we are. OS updates are forced after a time, and telemetry is not only the norm, but a very good idea for applications in use by millions of people, like Firefox.

And this doesn't change anything. Ransomware attacks are still the norm.


> opt-in telemetry is effectively the same as no telemetry.

That's an indication that people don't want this.


> That's an indication that people don't want this.

It's an indication that optional steps which do not immediately benefit the users of the software will not be taken.

The benefits to telemetry are longer-term, and because opting in is not required for the software to function, the vast majority of users simply will not do it. The thought to turn it on will likely not even enter their mind. Why would it? The software works fine.

Opt-in telemetry was tried by just about everyone that collects telemetry today. Lots of people say they will turn it on, and then never do. Telemetry is used to make better software. I'm sure there are companies that use it for [insert activity that any person might perceive as bad] and I would argue that those companies would likely not allow you to opt out.

If people understood the kinds of things that are collected, at least the things I collect in the software I write for work, I can't imagine anyone having a problem with it, but there's a lot of things that people do which make no sense to me at all, so I'm not really in a position to be authoritative.

I do know what happened in the late 1990s and the early 2000s though, and I know those things are a large part of why telemetry and forced updates are things which exist today.


Opt-out telemetry opens the door to abuse and is invasive. We can see this happening today already, and that the current trend for opt-out telemetry + forced update is not a reaction to "opt-in is useless".

Regardless of how strongly you feel about telemetry and its perceived "benefits", the choice should always rest in the hands of the individuals using the software first and foremost. Your customers should always be informed of their choice and if they feel like they are willing to participate, they can opt-in.

How would you feel if building architects decided to install a camera in your bathroom in order to analyze how you use your toilet and the shower to assist in improving future constructions?

> Lots of people say they will turn it on, and then never do.

Because most of the time, there is no benefit. The software is already made, and further development is rarely informed by telemetry data. Furthermore, customers are rarely informed exactly what data is being collected - and not given the opportunity or benefit to inspect the contents of any telemetry or crash logs that need to be sent.

> If people understood the kinds of things that are collected, at least the things I collect in the software I write for work

But they don't. And no one takes the time to educate or inform them or give them the choice to opt-in with a detailed disclosure of what is being shared, rather than having to opt-out. As people become more aware of these telemetry practices, you're going to see a wider backlash at the kind of unnecessary data that are being collected. Maybe you're not doing it - but others are.


> Telemetry is used to make better software.

I believe that absolute vast majority of telemetry is simply ignored. And I also believe it is very common that there are several individuals in most companies that couldn't care less about what is included in the telemetry.

A lot has changed since the late 90s, it really isn't good argument for telemetry nor forced updates that things were bad then. Things would have been absolutely awful in the late 90s even if you had perfect telemetry and instant updates that somehow didn't even need internet.

I don't see any real arguments for either in your posts.


A lot of baseless claims, I disagree.


Agreed. There is a pop-up asking if you want to help at install(FF & TB). Big data has earned a reputation for just cause. If the Mozillas want to differentiate themselves to get that trust, aka opt-in, I encourage them. So far, "No, thanks".


There might be a correlation between people who push their memory consumption to the limit and people who never opt into anything they don't directly benefit from, thinking that such optional stuff would hinder them from using all of their memory for personal benefit. OTOH, those people might realize that telemetry will eventually increase efficiency, allowing them to do more with their available memory...


The only telemetry you get will be from users that are experiencing a severe problem who also have the technical know-how to turn it on. You will have no idea how prevalent the problem is amongst the general user base. There would be no way to prioritize debugging the issues.


The technical know-how required to check a checkbox during install or something? Maybe that is a good filter...

There are other ways to test software... Especially the use-cases mostly used by users not well versed in the tech world.


> Crash logs are a different beast.

I was under the impression that Firefox was written in Rust. Doesn't this eliminate crashes? Rust is a safe language after all. There should not be any crash logs with Rust.


Is this satire? Rust eliminates memory errors such as use-after-free. Unlike C and C++, `myVec[usize::MAX]` will `panic!` if `myVec` isn't actually that large.


It depends a bit on your definition of "crash".

Rust has a `panic!()` macro which will hard-terminate the program and log a stack trace in what is functionally equivalent to a crash. It can be called in various scenarios... including out-of-memory situations (like the ones being addressed in the fine article and this thread).


Very small (but important) parts of firefox are written in Rust


It is 9.5% of the total code base, that’s even counting things like tests. I wouldn’t personally call that “very small” but ymmv.

That also said your parent equating memory safety to “no crashes” is also not correct. A process can exit early while never violating memory safety.


And even if Firefox was written in 100% Rust, Rust can still panic for logic errors. And system libraries have their own bugs and crashes that can bring down Firefox.


I would like Linux distributions to ship a system wide telemetry service that can be enabled / disabled at the installation time or anytime later on.

This service would be guaranteed to be unidirectional, would store data publicly on non-profit-run servers and domains and fully comply with GDPR (by not storing any PII and ano/pseudonymising everything).

Developers would connect to this service over dbus and consume the uploaded data in daily batches.

Hosting and hardware fees would come from donations by distributions and other organizations distributing money to the FLOSS ecosystem.


> I would like Linux distributions to ship a system wide telemetry service that can be enabled / disabled at the installation time or anytime later on.

There's nothing stopping a person from creating that. You'd package it up and get it added to the Debian, Ubuntu, RedHat, etc. repos and people would be able to install and use it. That's about as close as you'll get to having it generally available for all Linux distros.

Personally I don't see the value, and think it's invasive, so I would never install it, but people who wanted it would be able to use it.


I think what they meant is to configure proxying all possible telemetry via this service, and enforce anonymisation. Sounds good imho. I'm trying to disable telemetry but it's always a losing game, each version adds something new to each app.


I don't think that changes my answer.

The telemetry proxy service would need packages for each distro, including scripts to work with systemd and init, and maybe a "libtelemetry" package to make using the service easier.

The way I see it working is that if the system service isn't installed, isn't running, or has remote telemetry turned off then the commands for sending telemetry will succeed but send the data to /dev/null. Otherwise the data gets anonymized and uploaded to the user's configured telemetry host.

It could almost be built on syslog, now that I think about it more, but that would be terrible.


They kind of do. Pop-con (popularity contest) is in Debian to track package usage. https://popcon.debian.org/


The thing I like about popcon is it's opt-in, and disabled by default.

I enable it on my personal production systems and disable on everything else, both on privacy grounds (work), and not providing wrong data (disposable VMs).


> it's opt-in, and disabled by default

This is the right approach.


LVFS also has some: https://lvfs.readthedocs.io/en/latest/telemetry.html

This page from Debian Wiki may be interesting to see what all is out there: https://wiki.debian.org/PrivacyIssues


I do not think a centralized "system wide telemetry" service is a good idea. This has a huge potential for abuse and can be extended to collect other things.

Privacy should be privacy by default, and if you want users to send you crash/usage logs then you need to show them all of the dirty details, let them review it and chose whether or not to send.


Or they could just charge some nominal fee (/amount of computing resources?) from the consuming entities.

Love the idea!


Data also needs to not be shipped to a third-party (e.g. Google) to be correlated with other activity outside the app sending the telemetry. There's likely lots of data going to Google Analytics that the software/service owner never looks at, but Google uses for their own purposes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: