Hacker News Reader

Comment by oliwarner | Hacker News Reader

You're saying that as if the point of the software is to support the software, or report good numbers. It's not. The user should be the focus.

Opt-out and hard-coded systems immediately put you no the back foot. You make people question why? and is it worth it? If all you've got it reporting numbers of users, you can go do one. The risk of genuine private data leaking out is not worth your marketing numbers to me.

The Amazon link was much more egregious though. You were sending all Dash searches through to Amazon. This was unacceptable and poorly explained. I'm sure some people liked it, and they honestly could have made the integration a better trade for the user (play videos off Prime Video, etc), but only as an opt-in feature where you can see the ramifications.

View on HN

> The Amazon link was much more egregious though. You were sending all Dash searches through to Amazon. This was unacceptable and poorly explained. I'm sure some people liked it, and they honestly could have made the integration a better trade for the user (play videos off Prime Video, etc), but only as an opt-in feature where you can see the ramifications.

You do realize that no version of Ubuntu was ever released with that feature? Sure, the Amazon scope was available for a while but you had to opt in in all shipped versions. Even if you had, Canonical turned their servers off in 2017 so it wouldn't have done much except time out.

It's easy to get upset about stuff people have made up in echo chamber "news" sites.

The feature article is about the link to open Amazon in the browser, not the Amazon scope in the Dash.

> You do realize that no version of Ubuntu was ever released with that feature?

Not sure that is true - I seem to remember that it was enabled by default in a couple of releases (I think somewhere around 12.04?).

> you had to opt in > It's easy to get upset about stuff people have made up

I raised this issue early in the Lens development phase. The response from the mailing list was (paraphrasing) "well, people can always uninstall the package if they don't want the feature" (at which point I then opted out entirely).

Opt-in came much, _much_ later.

People need to understand that large scale software not having telemetry borders on malpractice if it interacts with the internet. If your software is crashing on a large scale - or worse, causing problems for other people's servers or taking out users' computers - you need to know, and you need to fix it fast. You can't just wait days or weeks to get enough complaints about it from people savvy enough to file bug reports.

Look no further than how a recent Chrome update almost completely broke the software for Citrix users. Their telemetry (somehow) was not tracking this so it took days to get a fix because IT/ops people had to figure out that a Chrome update caused the bug and then escalate through chromium bug reports. Now imagine that happening any time a crash or major bug makes it into connected software...

For stuff that just runs offline, like Excel or whatever, it's super justified to not want telemetry in it if that's the tradeoff users want.

Incidentally this is basically the reason why all the major browsers are on rapid forced (unless you're in the enterprise) updates - the risk of having users stay on older versions with security holes is just too high because it ends up leading to massive botnets. I hate it, but hundreds of millions of people use those apps.

Finally, a sensible argument _for_ telemetry.

What's wrong with the little popup that asks you if you want to report a problem every time a crash happens? Is there really any problem with letting the user choose on a case-by-case basis?

If it's happening so frequently that the popup becomes annoying, you've got bigger problems.

Because people rarely click Yes, even if it's rare.

Plus it means little to the end user, and outside of HN, Slashdot, or other tech forums, most folks don't even know what telemetry means in an OS context. They click No, and move on.

Are you saying all of those users whose browsers are crashing on a large scale are going to say no?

Also, are you implying software should send telemetry to the mothership regardless of users' will?

There used to be a time software was tested and released finished.

> Because people rarely click Yes, even if it's rare.

In my observation the precise opposite is true; your average user will immediately click "Yes" without reading in the hopes of making the error go away.

So you're arguing that because people will decline to share the data, they should be forced to share the data?

So the solution is to deprive them of their privacy for your own benefit? I don't blame them for clicking "no" if they don't know what it will be used for.

Providing the choice is always OK and often appropriate. The problem is when people argue that software shouldn't have telemetry or automated updates at all, because then what you get is software that respects the user's desire at a surface level - no telemetry, no automated updates - while failing to respect deeper aspects of their intent, like "I don't want to get added to a botnet", "I don't want this software to crash", and "I don't want features I like removed in future updates".

You can always decide to go elsewhere of course, and software developers have the right to decide personally not to put that stuff into their apps - none of my personal projects have telemetry and most of them don't have updaters.

> You can always decide to go elsewhere of course

The problem with web browsers is that you really can't. There are really only 2 options now, and the web has become so ridiculously complicated that creating a reasonable alternative browser is nearly impossible.

That's fine, if it is opt-in and clearly spelled out. Some of us do confidential work and leaking URLs visited and field contents to parties not subject to NDA is absolutely not acceptable in any context.

Yeah, a coherent privacy model, disclosure etc are all super important. It's just irritating to see people act like software of this type can rationally be shipped without any telemetry to a big group of users who aren't compiling it from source.

Naturally a ton of work has to go into properly designing telemetry for something like Firefox or Chrome - not only is disclosing URLs a no-go, but you need to make sure your telemetry isn't unintentionally exposing details that are identifying in some other fashion, like on-stack data from a crash report or that sort of thing.

> People need to understand that large scale software not having telemetry borders on malpractice if it interacts with the internet.

If that's true (and I don't really agree that it is), that's an excellent argument for avoiding large-scale software.

This is one of the strongest arguments against an Internet monoculture. Shame about all those alternative browsers dying to the point that now if you're working on one, CloudFlare/Google/etc are likely to just block your browser entirely.

Everyone's using the same massive-scale app and now that it's a central point of failure it's wildly irresponsible to not load it down with telemetry. It sucks. If it were instead a healthy market of like 4-8 different browsers people were using, a major issue in one of them wouldn't necessarily be a crisis because people could just boot up a different browser and the bug would only impact say 5-25% of a website's visitors at most instead of The Majority Of Them.

>The user should be the focus.

I agree and this is why I said good implementation can exists. I never implemented telemtry but I implemented once crash reporting. Before I added this feature the users had to contact support and tall us what is wrong, then we would send email back and forward asking about OS , application version. asking for screenshots, asking to enable debug mode and try again and then screenshot the error and send it to us. Because i was the one doing the customer support too I noticed this is very repetitive and very demanding for users (even explaing a user to find a log file in %appdata% in windows is a complex process) so I simplified it as much as possible, a crash or the user could open the report a bug popup, you would see exactly the data that is sent to me, it was plain text info like OS and app versions and a stack trace and other logging data and you had the option not to send it to me but if you sent it then I have the stack trace I have the info and I could put an update to fix teh bug in a day rather then we spend time emailing each other questions.

Reply on news.ycombinator.com