I don't know about Ubuntu, but while installing Debian it makes it very clear what popularity-contest does and asks the user for explicit consent.
The default option is "I do not wish to participate", so if someone isn't paying attention during the install process and just hits 'Enter', their privacy remains intact.
On Ubuntu you still have to explicitly enable it - and unless I missed something in my last couple of Ubuntu installs you are never prompted to enable it during installation. If you want to opt in, you have to do a dpkg-reconfigure and even then the default is still "No".
This is not privacy-hostile in any meaningful way.
The default in Ubuntu is to ask you at install time if you want it installed / enabled or not, for about as long as I remember, and I've been using Ubuntu for since ~5.04ish days.
Really? I thought it was common knowledge that UK are brutal about surveillance. James Bond and Kingsman, CCTV on every corner, Canonical CEO dismissing privacy concerns in new products “because you already trust us when we sign the packages” ...
> How do people building these things become convinced this is ok?
Because they have the data proving that opt-in telemetry means no telemetry. Every time this topic comes up, HN sticks its fingers in its ears and refuses to accept this, but it's the truth. 99% of users, even for a developer-focused application like VSCode, just click through and accept the defaults. So if you want telemetry that isn't useless for any practical purposes, it has to be opt-out.
If you want, you can have a separate argument about whether having the telemetry is worth it, but if you've had that discussion and decided the answer is yes, then opt-out follows immediately from that.
Indeed, I wouldn't try to find a case for "good telemetry", it basically means snooping, as far as I'm concerned.
And this is not even something that can't be replaced : if you want to know about your users habits, ask them. I would have no problem with seeing once in a while a broadcast message after syncing packages showing me an url of a poll. But automatic data collection is never ok.
I've heard the same data as you. But I haven't heard data on what happens if you force people to make a choice about the telemetry upon install, without offering a default.
Like, instead of having a prechecked box that people would have to notice and uncheck before proceeding or a greyed out "maybe later" button, what about two different continue buttons labeled "yes, help us improve with anonymous statistics" or "no, I'd rather not contribute"? (Either way with a link available to more details in the privacy policy before deciding.)
My guess is that it would be less useful telemetry than opt-in, more useful than opt-out, and a slight obstacle to sign-ups for consumer webapps but not much of an obstacle to enterprise webapps or anything pre-downloaded.
Maybe it's still useful and smooth enough to be the right balance vs privacy?
What are the second order effects? What's this "complex reality" you're living in? VSCode gives you a log of every telemetry event it sends, none contain PII (if they do that'd be a serious issue and should be reported) and it provides a settings page to list and opt-out of every online service (including telemetry).
It's a loss of the trust of your users. It's ever harsher data protection laws. It's the vehement reaction you get when you say to someone, "your personal space is mine for the taking, and maybe I'll take a little less of it if you beg me to stop." It's the slippery slope of dark patterns to cajole and conceal and browbeat users into avoiding the opt-out. It's the camel that starts with its nose and then quickly removes you from your own tent. It's the grab first, apologize later modern world of capitalistic exploitation all in the name of gaming the quarterly numbers. It's the next paving stone on the road to your users crying out "We're mad as hell and we aren't going to take it anymore!"
Lol... always amusing when someone asks HNers what changes they'd like to see and why, and they respond with crazy analogies that are totally unactionable... not the first time this has happened, won't be the last.
As others have pointed out, change opt-out to opt-in. Don't send a single byte until opt-in is complete.
Change your frame of mind from "my software" to "your computer". If your users don't explicitly opt in, you have no right to take what they do not freely offer.
Come again? Is there telemetry in the F# compiler I didn't know about? Or you mean that OOTB VSCode has telemetry, so you won't use it for your F# code, opting instead for a different text editor / IDE?
Nothing says there isn’t. I was shocked when I heard vscode had telemetry even though it was open source and now I’m not sure I want to use any other open source stuff that comes from that company. Especially a compiler.
> the store assigns an anonymous identifier, the device-serial, to every new snapd client it sees. This exchange usually happens when a new installation contacts the store, and the identifier persists for the lifespan of the machine.
> Systems running snapd will periodically make a refresh request to the store, checking the for the most recent release of each installed snap. At that moment, they inform the store of their device-serial along with a list of the currently installed snaps.
Lol another reason for me to hate snaps. I didn't yet know that.
PS: My other reasons:
- Much more resource wasteful
- Single store operated by canonical only
- No simple updating a library with a vulnerability and having all apps that use that library automatically fixed.
- Makes really messy virtual mountpoints everywhere.
Have you tried opening the calculator in Ubuntu? On my laptop it takes a full 3 seconds for the GUI to come up, assuming I have nothing else running. 3 full wall clock seconds. It's actually faster to pull out my phone and open the calculator on it than my laptop. Which is what I do now, every time. So, if you want people to look for alternatives to your application, only provide it as a Snap.
You can take your hands off the keyboard and mouse, dig your phone out of your pocket, unlock it, open the app drawer, scroll and find calculator, tap it and open it, under 3 seconds? I doubt that.
I just picked my iPhone up off the desk (where I keep it charging when using a computer) pulled down the shortcut screen and opened the pinned calculator app. Was roughly 2 seconds from thought to screen. Windows calculator just took me about that- press Windows button, type 'cal' press return, actual launch basically instantaneous. Mac would be analogous to Windows.
Seems more likely that you just don't notice time passing whilst active (getting your phone out) that you do notice whilst passive (waiting for app launch).
KDE/Plasma does calculations in the launcher - which comes up immediately. Or you could open your console (I use Yakuake) and use bash/python/bc -i/whatever.
You're pointing to instances where snaps aren't involved- kinda missing the point. Just because there are other ways to get the desired result, the optimal path used by most people is seriously impaired for no benefit.
The pocket and app drawer step are optional. In brief testing it took around 4 seconds to turn on the phone unlock it and open the calculator. It's likely harder to notice as this is actively engaged time vs staring at a screen.
Timing with a script with a warm cache speedcrunch, kcalc, and emacsclient full-calc all take about half a second for the window to appear and are instantly usable. The quickest app I can find xterm appears in 200-250ms.
Chromium takes about 800ms. incidentally Chromium shows a big difference after dropping caches taking almost 2.5 seconds after dropping caches while others mostly lose 20%.
Firefox is the worst taking about a second warm but taking around 6 seconds after start to become usable. Some of this may be due to addons but firefox has never started quickly its only tolerable because you start it once at login.
How is this system GDPR and cookie compliant? It's not mentioned under the data they collect, and no attempt is made to ask permission to collect this data -- at least, not the way I've used recently. (A clean Kubuntu install, then installing Intellij's Snap through the CLI.)
Years ago(I started around 2008 or 2009 I think), Ubuntu was different because it Just Worked. It came with lots of drivers, easy defaults, and guis for everything. You could easily dual-boot it with Windows(there was a windows executable that would get it done without burning a CD or dealing with an iso), and could be installed on just about any computer at the time.
Nowadays, lots of distros are just as easy(Debian, fedora, Linux mint), come with all drivers, work on basically all systems, and don't spy on you. Ubuntu isn't as easy to dual-boot windows now too. There's basically no advantage to Ubuntu now except community.
> There's basically no advantage to Ubuntu now except community.
Ding Ding Ding. This is why I still recommend Ubuntu, there's a community and a wealth of knowledge out there for working with Ubuntu.
Though if you are more experienced and deal with nuanced issues you will find often the community is outdated and this is a double edged sword -- a lot of material out there is for older Ubuntu distros and is no longer relevant.
> There's basically no advantage to Ubuntu now except community.
That's the best and worst reason to reccomend ubuntu. The best because it's community is large and somewhat stable. The worst because that community is under the thumb of a corporation that does not seem to understand it.
I've always appreciated that should I choose to I can "vote" with my system to show the packages that are important to me with a hope that it would help Ubuntu, and others, to focus resources.
popcon-largest-unused is a useful tool whether I've uploaded their data or not.
The packages I have installed hardly seems worthy of keeping secret, the opposite in fact.
Also posted this as a child comment elsewhere in the thread, but:
---
I don't know about Ubuntu, but while installing Debian the installer makes it very clear what popularity-contest does and asks the user for explicit consent.
It also makes it very clear that this setting can be changed later at any time.
The default option is "I do not wish to participate", so if someone isn't paying attention during the install process and just hits 'Enter', their privacy remains intact.
If you ask politely, I will often say yes to opting in! People don’t seem to understand this and think that somehow I’ll feel exactly the same if it’s opt-out because “it’s the same data…”
I have it turned off on a laptop I use for red teaming because you don't want to be accidentally noisy on the network, but other than that it's turned on.
I really wish popcon asked two questions right up front:
1. Is this machine primarily used as a laptop, desktop or server?
2. Is this machine owned by a business or by a person?
All sorts of popcon results are taken as being authoritative, when (I think) the overwhelming majority of responders are personal owners with laptops or desktops.
It makes sense: if a service asks politely and does not use dark patterns, it's a signal that they take your privacy seriously. So it feels good to reward them and give the permission.
Without making a value judgment about whether it is the right thing to do, it has been well established that automatic opt-in vs default opt-out numbers favors automatic opt-in ( usually discussed around organ transplant issue ). I agree with you in theory ( as in I know I almost automatically do the opposite once I find someone tries to opt me in without my say so ), but I also know inertia is a powerful force.
Yes, but with statistics you don't need everyone to opt in–just some portion. You can't really extrapolate a kidney ;)
Usually what happens with opt-in versus opt-out is that the people who are the heaviest users of your software, the ones who care about it, the ones who might know its details or care about privacy will turn it off and you'll just be getting analytics from people who are casual users–and it's really easy to end up interpreting this as "hey, nobody uses $OBSCURE_FEATURE, let's remove it!". Whereas if you make it opt-in, yes you will generally have smaller numbers, but the distribution might be more useful to you, and you're less likely to think that just because you have numbers on 70% of people you're going to make the right decision.
Unless you think they want your data at the expense of the majority, this doesn't seem relevant. The difference between opt out and opt in is massive, 80% of people don't care or don't read. Your irrational preference here doesn't even register on their charts
I don't think it's "irrational" to suggest that you shouldn't be collecting data from those people as they have clearly not given consent to you doing so.
I wasn't referring to that, thanks. I was referring to your own irrational willingness to hand over the same data based on how they ask for it. Maybe it is rational; you know they're not getting any useful data with an opt-in, so you'll play along with their incompetency by handing them a single datapoint?
It's the same reason why I would rather want someone who approaches me on the street to ask me for money (which I might give!) rather than just stealing it from me silently and and then offering the option to return it when I ask for it back–of course only if I notice the theft. I take issue with you calling consensual data collection "incompetent".
it's not the same data though. if you default to on, you get the data from people who tend to leave the defaults the way they are. if you default to off, you only get data from people who will read the text in the installer and decide to change an option away from the defaults.
Arch operates like Debian, the package is called `pkgstats` and it's an opt-in to install. The results are public: https://pkgstats.archlinux.de/ (like Debian, the results are only as good as those who choose to opt-in)
nod It's mentioned briefly on the "General Recommendations" wiki page in one sentence, not exactly easy to find. The Installation Guide wiki page is protected from edits, so an official wiki Admin would need to approve and make the change (see the History tab for recent editors you could contact).
Thanks for the reminder. I actually read about this somewhere (probably on ArchWiki), while installing Arch a few weeks ago, but I totally forgot to actually opt-in.
Really nice distribution, btw! My favorite, so far.
Fully agree. The only downside is that the data they receive is probably representative of a small segment of users (my guess is free software enthusiast desktop users, but I may be wrong).
Probably not, because of caching and mirrors. There are many, many mirrors, including global CDNs. Debian makes no attempt at controlling package distribution. Also packages are signed, but sent over HTTP to allow easy caching, and there are no-fuss caching packages in the repos. If you have a site with even a handful of debian or ubuntu machines, you would be well served to setup a cache to save bandwidth and improve update download times. This all results in making it impossible to get even remotely accurate statistics server side.
The popularity contest package is checking which packages are actually actively in use[1]. It keeps track of file access time with a 12 hour resolution and any package used in the last thirty days is considered active.
I think this might be interesting for packages that are part of the default install, server side statistics would always show those even when they are not used.
I understand @notRobot's sentiment, but do not agree with it.
If the default is "no telemetry", then very little telemetry will be collected.
This is an advantage to the user, but a strong DISadvantage to the collective, because the distro manager now cannot make informed decisions as to what packages are installed where and how often.
It really is a balance of "individuals vs the collective" and I don't think that answering both needs is simple, nor is it cut-and-dried.
Why would a collective like Debian or Ubuntu need to know what packages are the most installed? I know Ubuntu has their own App Store, is it perhaps to show which apps are the most popular?
If it’s for caching, can they not see which packages are most frequently accessed over http and implement caching that way? Or is that against their privacy policy? I’m not very knowledgeable on this subject but would love to know more!
It helps deciding on priority (bug fixes) or whether a package is worth maintaining or keeping in the distribution even if it costs time or prevent some (library) upgrades, improvements or refactorings that would break it.
As a software writer, it motivates me to know that my software is used and that putting effort in maintaining it will help people. For instance, I made a small Firefox extension that requires regular updates by design. Seeing that it was installed on a hundred browsers has motivated me to maintain it. If it was just for me, I probably wouldn't have bothered so much even though this extension scratched a personal itch.
As a user, I am a bit reluctant to being tracked so a balance must be found.
Edit: the amount of downloads from the archives is not enough. Some packages are downloaded again and again by automated systems like continuous integration systems and a downloaded package can be uninstalled immediately and this would be imperfectly detected.
But the maintainer can still make decisions based on the telemetry which is available.
It's not unreasonable to assume that the the smaller sample of uses will still be a representative sample.
Yes it is. The average user will change very few default settings, so people who opt in will have fundamentally different usage patterns because they fiddle with stuff.
Opt-out telemetry does not create informed decisions, it creates decisions based on the subset of people who don't care or don't know enough to opt out, and I have seen real instances it adds a dangerous overconfidence to the applicability of the decisions made from that data. And it's important to note that little telemetry is often enough to do a decent amount of statistical analysis–in fact, one of the first things you'd learn in a course is that you don't really need to collect data from everyone, and most sample sizes don't go above 10% of the population unless you're doing some kind of census.
"A little telemetry is often enough" -- Assuming a representative sample, right? If only a few opt in, they might climb above 10% but may not represent the population distribution.
(I'm agreeing with your first statement, but questioning your second one.)
Yes, just saying that in general if it is possible to have a representative sample (which I argue is not a thing even when you are doing opt-out, and would be willing to content is probably even less representative).
Do you really need samples from that many users? Wouldn't a sampling of a few thousand users give you more or less the same results as a sampling from a few million? And if not, is it worth the bad will you're earning from your users by treating them like this?
A random sample – sure, if you have enough traffic to still get decent sample size, but a sample obtained by users opting in is often close to worthless because it's not random and so not representative of your userbase.
That’s not what they said, they said it’s not a simple cut and dry answer and is a trade off between individual privacy and collecting data to improve the product.
Oh, I forgot, this is hackernews, where the only way to improve products is by collecting massive amounts of data on users! Pardon me! I'm gonna IMPROOOOOOOOVE.
We really need a DoNotTrack-like standard for application telemetry so that sysadmins and the privacy conscious can just set some environment variable like NO_TELEMETRY to a nonempty string and not worry about it. Packages would still have to be audited and shamed for not respecting NO_TELEMETRY but thats no worse an obstacle that has faced homedirs.
Developers can get that sweet sweet telemetry by default and those that care can just set a var in ~/.profile and be done with it.
Popcon (the software that collects such metric) has existed at least for 20 years, via Debian, just for the record for people freaking out for how long this has been a thing without them reading the installation dialogs.
This has been in Debian since forever, and the installer asks if you want it. I've always opted to not install it since it's my opinion that my package choices are weird and shouldn't -at all- influence the distro defaults.
Quite apart from the difficulty of collecting logs from the hundreds of official and unofficial mirrors, it also doesn't account for the various layers of caching.
Last I recall, they changed from collecting analytics without notifying the user to keeping it opt-out but explaining how to do so on first install. Has this changed?
This is the apt system that's losing the statistics system. Ubuntu is likely collecting data from the closed source proprietary snap system that they push users toward.
113 comments
[ 2.3 ms ] story [ 184 ms ] threadHow do people building these things become convinced this is ok?
The default option is "I do not wish to participate", so if someone isn't paying attention during the install process and just hits 'Enter', their privacy remains intact.
This, IMO, is the perfect way to do telemetry.
This is not privacy-hostile in any meaningful way.
Because they have the data proving that opt-in telemetry means no telemetry. Every time this topic comes up, HN sticks its fingers in its ears and refuses to accept this, but it's the truth. 99% of users, even for a developer-focused application like VSCode, just click through and accept the defaults. So if you want telemetry that isn't useless for any practical purposes, it has to be opt-out.
If you want, you can have a separate argument about whether having the telemetry is worth it, but if you've had that discussion and decided the answer is yes, then opt-out follows immediately from that.
If they care about their users and it's not possible to have worthwhile telemetry with opt-in, they simply can't have it.
[0]: https://insights.stackoverflow.com/survey/2019#development-e...
And this is not even something that can't be replaced : if you want to know about your users habits, ask them. I would have no problem with seeing once in a while a broadcast message after syncing packages showing me an url of a poll. But automatic data collection is never ok.
Like, instead of having a prechecked box that people would have to notice and uncheck before proceeding or a greyed out "maybe later" button, what about two different continue buttons labeled "yes, help us improve with anonymous statistics" or "no, I'd rather not contribute"? (Either way with a link available to more details in the privacy policy before deciding.)
My guess is that it would be less useful telemetry than opt-in, more useful than opt-out, and a slight obstacle to sign-ups for consumer webapps but not much of an obstacle to enterprise webapps or anything pre-downloaded.
Maybe it's still useful and smooth enough to be the right balance vs privacy?
The reasoning is simple.
The reality is complex.
Always, always think about second order effects.
Change your frame of mind from "my software" to "your computer". If your users don't explicitly opt in, you have no right to take what they do not freely offer.
Come again? Is there telemetry in the F# compiler I didn't know about? Or you mean that OOTB VSCode has telemetry, so you won't use it for your F# code, opting instead for a different text editor / IDE?
https://snapcraft.io/docs/snap-store-metrics
> the store assigns an anonymous identifier, the device-serial, to every new snapd client it sees. This exchange usually happens when a new installation contacts the store, and the identifier persists for the lifespan of the machine.
> Systems running snapd will periodically make a refresh request to the store, checking the for the most recent release of each installed snap. At that moment, they inform the store of their device-serial along with a list of the currently installed snaps.
PS: My other reasons: - Much more resource wasteful - Single store operated by canonical only - No simple updating a library with a vulnerability and having all apps that use that library automatically fixed. - Makes really messy virtual mountpoints everywhere.
KDE/Plasma does calculations in the launcher - which comes up immediately. Or you could open your console (I use Yakuake) and use bash/python/bc -i/whatever.
Timing with a script with a warm cache speedcrunch, kcalc, and emacsclient full-calc all take about half a second for the window to appear and are instantly usable. The quickest app I can find xterm appears in 200-250ms.
Chromium takes about 800ms. incidentally Chromium shows a big difference after dropping caches taking almost 2.5 seconds after dropping caches while others mostly lose 20%.
Firefox is the worst taking about a second warm but taking around 6 seconds after start to become usable. Some of this may be due to addons but firefox has never started quickly its only tolerable because you start it once at login.
https://ubuntu.com/legal/data-privacy/snap-store
I’m really grateful to Ubuntu for helping me get deeper into Linux in 2007, but I would never recommend them to anyone today.
Nowadays, lots of distros are just as easy(Debian, fedora, Linux mint), come with all drivers, work on basically all systems, and don't spy on you. Ubuntu isn't as easy to dual-boot windows now too. There's basically no advantage to Ubuntu now except community.
Ding Ding Ding. This is why I still recommend Ubuntu, there's a community and a wealth of knowledge out there for working with Ubuntu.
Though if you are more experienced and deal with nuanced issues you will find often the community is outdated and this is a double edged sword -- a lot of material out there is for older Ubuntu distros and is no longer relevant.
Wubi for anyone searching.
That's the best and worst reason to reccomend ubuntu. The best because it's community is large and somewhat stable. The worst because that community is under the thumb of a corporation that does not seem to understand it.
popcon-largest-unused is a useful tool whether I've uploaded their data or not.
The packages I have installed hardly seems worthy of keeping secret, the opposite in fact.
---
I don't know about Ubuntu, but while installing Debian the installer makes it very clear what popularity-contest does and asks the user for explicit consent.
It also makes it very clear that this setting can be changed later at any time.
The default option is "I do not wish to participate", so if someone isn't paying attention during the install process and just hits 'Enter', their privacy remains intact.
This, IMO, is the perfect way to do telemetry.
1. Is this machine primarily used as a laptop, desktop or server?
2. Is this machine owned by a business or by a person?
All sorts of popcon results are taken as being authoritative, when (I think) the overwhelming majority of responders are personal owners with laptops or desktops.
It'll quickly and destroyed, so I just keep thinking I'll pollute their stats.
Usually what happens with opt-in versus opt-out is that the people who are the heaviest users of your software, the ones who care about it, the ones who might know its details or care about privacy will turn it off and you'll just be getting analytics from people who are casual users–and it's really easy to end up interpreting this as "hey, nobody uses $OBSCURE_FEATURE, let's remove it!". Whereas if you make it opt-in, yes you will generally have smaller numbers, but the distribution might be more useful to you, and you're less likely to think that just because you have numbers on 70% of people you're going to make the right decision.
I don't think it's "irrational" to suggest that you shouldn't be collecting data from those people as they have clearly not given consent to you doing so.
Really nice distribution, btw! My favorite, so far.
Ask beforehand or it'll be denied; mandate or lie and you'll never get a single byte, ever.
I think this might be interesting for packages that are part of the default install, server side statistics would always show those even when they are not used.
[1]https://popcon.debian.org/FAQ
I understand @notRobot's sentiment, but do not agree with it.
If the default is "no telemetry", then very little telemetry will be collected.
This is an advantage to the user, but a strong DISadvantage to the collective, because the distro manager now cannot make informed decisions as to what packages are installed where and how often.
It really is a balance of "individuals vs the collective" and I don't think that answering both needs is simple, nor is it cut-and-dried.
If it’s for caching, can they not see which packages are most frequently accessed over http and implement caching that way? Or is that against their privacy policy? I’m not very knowledgeable on this subject but would love to know more!
As a software writer, it motivates me to know that my software is used and that putting effort in maintaining it will help people. For instance, I made a small Firefox extension that requires regular updates by design. Seeing that it was installed on a hundred browsers has motivated me to maintain it. If it was just for me, I probably wouldn't have bothered so much even though this extension scratched a personal itch.
As a user, I am a bit reluctant to being tracked so a balance must be found.
Edit: the amount of downloads from the archives is not enough. Some packages are downloaded again and again by automated systems like continuous integration systems and a downloaded package can be uninstalled immediately and this would be imperfectly detected.
Also using differential privacy you can gather statistics on package use while limiting knowledge about a specific user.
(I'm agreeing with your first statement, but questioning your second one.)
The average users that you want to target don't really change those settings.
Don't drive so fast bro.
Developers can get that sweet sweet telemetry by default and those that care can just set a var in ~/.profile and be done with it.
Ahh...that thing that is mostly ignored because its based on goodwill?
> Canonical’s Michael Hudson Doyle says “…the package and backend have both been broken since 18.04 LTS without being much missed.”
Maybe someday this will be the only legal way to do telemetry.
Ubuntu doesn't even run all the mirrors, so hasn't even got control of if people are collecting this data.
This seems like something trivial to solve without impacting user privacy if they're downloading all the packages from you or your mirrors.
Unless the point was to see what PPAs people are using?
In other words, the headline is false because "Will No Longer" implies the opposite, which even the author acknowledges is not true.
The other two main ones are Apport for crash reporting, and ubuntu-report, which sends system info if opted-in at install.