Add telemetry consent setting #12281
Conversation
|
Does this change make it so that people who are currently opted in to metrics will see the welcome page again? If not, how will users who would like to share metrics know to change this setting? I fear we would lose a lot of metrics from people who genuinely don't mind providing them if they aren't notified that metrics are now opt-in, and where to change the setting. |
|
All users both new and existing will be presented with the dialog and asked to make a choice. |
|
Final screenshot of telemetry opt-in;
|
|
Shipped in 1.11.0-beta0 |
| type: 'string' | ||
| default: 'undecided' | ||
| enum: [ | ||
| {value: 'limited', description: 'Allow limited anonymous usage stats, exception and crash reporting'} |
There was a problem hiding this comment.
@damieng why is there no option like: unlimited ? I want to make Atom better and I mean business.
There was a problem hiding this comment.
There is no higher level of telemetry collection in Atom. The value is
called limited to make it clear in the future that consent was only given
for limited telemetry.
On Mon, Sep 5, 2016, 6:41 AM Jiri Spac notifications@github.com wrote:
In src/config-schema.coffee
#12281 (comment):@@ -112,7 +112,16 @@ module.exports =
description: 'Allow items to be previewed without adding them to a pane permanently, such as when single clicking files in the tree view.'
type: 'boolean'default: true
telemetryConsent:description: 'Allow usage statistics and exception reports to be sent to the Atom team to help improve the product.'title: 'Send Telemetry to the Atom Team'type: 'string'default: 'undecided'enum: [{value: 'limited', description: 'Allow limited anonymous usage stats, exception and crash reporting'}@damieng https://github.com/damieng why is there no option like:
unlimited ? I want to make Atom better and I mean business.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/pull/12281/files/369bd12faaf656b94d01affa8b3d63d4796e4107#r77523588,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHQp65yMhVVspLxaKwhKbnUw8XF_RCxks5qnBwWgaJpZM4JaPnm
.
|
This doesn't seem to mention that the data is sent to Google Analytics, rather than to infrastructure that is maintained by the Atom team. Is there a particular reason for that? I was personally quite (unpleasantly) surprised to find that Google was involved in the data collection, without that being clearly mentioned anywhere. This wasn't stated on the Welcome page either. |
|
I'd also be interested to hear how the opt-out selection is 'registered'. Is the information sent to Google? That would defeat the purpose of having opted out. |
|
I'd also like to mention that some packages (like atom-beautify @ 1.65M users) seems to do GA independently? Shouldn't that be controlled by atom, or at least be stopped by an inclusion-gate to the package store? |
As far as I'm aware (I don't have access to the GA data, so this comment could be wrong), if you decide to opt-out, that selection is sent to Google Analytics. This is so the telemetry data from the opt-in users can be (somewhat) extrapolated to the entire user base. Can you elaborate on what you mean by "this would defeat the purpose of having opted out"? @xenithorb: As atom-beautify is a package, they would have to supply their own opt-out method. This opt-out screen is only for the data that Atom and its core packages collect, not for any of the community packages. (For example, just because you opted out of Windows telemetry reporting doesn't mean that any Windows apps automatically opt you out as well.) @joepie91 Not that I know of. Again, I'm not a GitHub employee, nor do I have access to the data in question, so please don't refer to this comment as the source of truth. |
This is a pretty bad metaphor for Atom, because you're comparing it directly to an OS. I don't believe you should be taking such a hands-off approach to community packages, because they integrate into your software. It's not the same as running two discrete apps on any given OS, the relationship isn't the same. If anything, it's more like any given package manager. I understand that the project probably doesn't have the manpower to moderate community packages, but if we're going to use the OS metaphor, let's take Ubuntu, or in my case, Fedora for example, those packages are carefully curated by the maintainers of the project. And why is that? because you use the distribution's tools to install those packages, and they're tailored to work with the distribution, and they affect the reputation of the project. That's the closest analogy I can come up with, and in any one of those circumstances, I don't have to worry about Google Analytics sneaking in. So I'll ask it differently?
I understand that you're all web-devs and talking about privacy and analytics is boring because you've all accepted it but I don't see why such a nice piece of software - that runs locally - really needs it. (i.e. users have to download it to use it, so there's your metric) |
If people have said they don't wanna be tracked, would they consent to their having said they don't wanna be tracked, to be tracked? |
|
If there is no particular reason for Google Analytics not being mentioned, then I would strongly recommend adding that to the opt-in screen in clear language, so that people actually know what they are opting into.
That still leaks the fact that the user is using Atom, which is a bad idea. Just keep it from sending any data to Google at all, and look at the amount of clients that have reported in to determine how many tracked clients you have. That's the only data that really matters here anyway.
This can probably be implemented relatively easily by exposing a global configuration option that indicates whether telemetry is enabled, and forbidding extension developers from collecting analytics if that option is disabled. |
Yes precisely what I'm asking for |
@xenithorb You've already been warned once about harassment in violation of Atom's Code of Conduct, severely enough that I had to delete your post. Your comment quoted above is in violation of the trolling and personal attacks sections of the code. Because of this, I'm banning you from participation in the Atom and Electron projects. If you wish to be reinstated, you may contact me at the Atom support email address and we can discuss it. |
|
So a few points. We don't specifically call out Google Analytics because we also use BugSnag for exceptions and have in the past used a VM server to capture Chromium crash reporting. We may need to add, remove and switch services out if the need arises. The opt-out is a one time minimal ping to GA today. It doesn't defeat the purpose because it's one ping and that's it. No heap sizes, no package or command info, no startup times. A single "kthxbye" ping at the time you choose 'no'. The Atom package system has no sandbox and authors can do anything. There is no way we could enforce any kind of http/https access policy to lock down how they record analytics. While they could theoretically read the flag we use for telemetry I would advise against it. The permission granted in this dialog is for specific information to the Atom team and not a broad opt-in to anything and everything. |
It doesn't leak the user is using Atom, it tells us specifically that they installed it and didn't want to collect any further telemetry. It is a very important metric as without it we can't know even how many users have installed the product (download counts are always inflated because of partially-complete downloads, multiple-clicks to a download and people who download but don't then install) |
|
@joepie91 A configuration option has been added as part of this change, |
The problem here is that you are sending data to an organization that has both the means and the reasons to use the data for purposes other than your own analytics. BugSnag is a service that sells subscriptions to developers for tracking errors - they don't have a reason to use the data for other unspecified purposes, and likely not the means either. This applies doubly so for self-hosted analytics. Google Analytics plays a special role here because it is from Google. The same would apply for any other company that has the means and/or reasons to use data for other purposes, in particular those companies that are known for running their entire business on data collection and marketing/profiling of users. Further, I consider it completely inappropriate to send this kind of data to a third party without explicitly asking the user for their consent in doing so. As it stands, all the text in the application other than the package description (which is easily missed) suggests that the analytics infrastructure is self-hosted. That is a problem.
That is the same thing. I said "that the user is using Atom", not "when the user is using Atom".
Why do you need this kind of metric? What purpose does it serve? How do users benefit from this? It sounds like a needless vanity metric to me, with potentially serious privacy tradeoffs by not respecting the user's choice to opt out of tracking. If you are trying to track usage trends over time, then you don't need this metric either - it's very likely that the proportion of users that has opted into tracking is sufficiently representative to track trends, even if not exact user counts.
This seems to contradict what @damieng is saying. Could you clarify? If the opt-out really is kept locally and not reported to Google Analytics, then that is fine with me, and the only issue remaining is that it's not clear who are processing the data (which might actually have legal implications as well, now that I think of it).
Thanks. I do still think that the Atom package registry needs a better policy on this, though - ideally, extensions that track the user without consent just shouldn't be allowed (at least, when they do so in an Atom version that supports the |
Knowing how many users are using your software is an essential part of considering what resources to commit to it. This is especially important when your software is a free-open source application and you are a business with paid employees working on it. A larger active user base can justify a larger team to work on it which will result in a better product. That's how users benefit. Lee's comment about the nothing-sent metric is actually incorrect. I believe he was on vacation when I wrapped up the telemetry work so may not have been aware. Users who absolutely don't want to share even a single ping can still go in and disable the metric package as before but with the benefit now that if you do it before clicking yes or no on the telemetry consent screen then nothing at all should ever be sent. With regards to what packages can do I personally agree that we should come up with some policies for authors around this as well as some disclaimers in the install section and I'll take these thoughts back to the team to discuss. |
This absolutely does not require reporting every single user to a (third-party) analytics service. Things like community activity and amount of opened issues provide sufficient insight into this. It's also not a "user benefit" - it's an arbitrary requirement that you set as maintainers, that does not need to exist for the users to gain this benefit.
How would they even know? This is completely counterintuitive (the user just indicated they don't want to be tracked!) and unnecessarily complex. Somebody who is using Atom for the first time will likely not even be aware that parts of Atom core are distributed as packages that can be disabled. It would be much more reasonable to just not send this 'single ping' by default at all, and work out a different way of determining popularity of the application, some of which I've already mentioned above. Software development has worked just fine for decades without this phoning home about the exact usercount. I don't see why it's now suddenly a hard requirement - there are so many other ways to obtain this kind of information.
Thanks :) |
|
Software development relied on gut feelings and best guesses for decades. Now we can add some data to our toolkit and like many companies can use that in the decision making process. It may not be how you would personally do it but it's what we have chosen. That single ping has a significant importance as well as providing overall install numbers. "Do a significant portion not want to share telemetry data?" I suspect most users will not mind you may suspect they do. Soon we can put suspicions aside and know for sure. Without that ping all we'd know is X installations of version Y reported telemetry. Is that a significant portion of our user base? Are we up or down? Is that because of an installation issue or because of opt-out? As to whether disabling the metrics package is particularly discoverable - it has actually been the only way to disable telemetry for some time so I would users who care enough have already disabled it. Nothing in this change will undo the choice they have already made. |
And I am criticizing that choice. This is disrespectful towards your users, and saying "that's what we've chosen" is not a good way to remedy that issue. As I've said, there are many ways to obtain the kind of information you actually need.
This, again, fails to answer the most important question: why does any of this matter? You seem to be collecting metrics because you can, not because you have a clear purpose for them that users can benefit from. This is an extremely disturbing trend, and I am not happy at all to see this appear in stand-alone applications as well. It is absolutely none of your business as a developer to know what I am doing with the software or whether I am even using it, unless I have explicitly consented to sharing that information. This "single ping" violates that. As a user, choosing not to share that information has the consequence that their performance issues will not be logged, that their errors are not known to the core developers, and so on. That is completely fine, and a choice you make as a user, with the consequences of that choice. I cannot see a single valid usecase where you, as the core development team, need to know that I am using Atom but have chosen to disable its tracking. The reality is that you don't need to know how many people have disabled tracking. You don't need to know whether it's a significant part of your userbase. The only thing that matters is the metrics that you do get from consenting users, and the experiences and problems of those users.
That is irrelevant to what I am talking about. I am talking about the consent screen being misleading, in that a new user picks that they do not want analytics collected about them, yet that very choice itself is sent to an analytics collector. "It's always been undiscoverable" is also not a valid reason to leave it undiscoverable. It doesn't address my concern at all. |
|
This is hardly better than what we had before. Users who'd like to keep their data private aren't presented with the option; or worse, they're presented with an option that could have them inadvertently leak their PII. If (new) users don't pick up on the fine print - which they won't 'cause they just wanna finish the setup and get to using the app - they aren't gonna look for ways to cleanly disable telemetry. This is textbook deceptive design, be it unintentional. |
|
@wfdd All users will be presented with the option. If you already had the metrics package disabled we don't send anything at all not even the opt-out ping. What piece of PII do you think is being leaked? If you compare the contents of the opt-out ping to a https request to download Atom itself there is practically no difference - basically what OS and what version of Atom. At our end it just means we can work with the data more easily rather than spending time and effort combining server logs that would be better spent working on Atom. @joepie91 The No option says "We will only register you have opted out." |
There are more ways to obtain Atom than by downloading it from the site. It's also a conscious action that can be carried out in whatever way the downloader desires, including using privacy tools.
The problems with that:
The entire UI is deceptive. Consequences are squirreled away in faded text, the buttons only speak of "helping Atom" rather than of the actual decision people are making. The "no" button makes an appeal to emotion, to try and make people feel bad about picking "no". The "yes" button is strongly highlighted. These are all the typical dark patterns, and they really have no place in this kind of dialog. |
|
I agree w/ @joepie91 that if there's going to be an option to disable tracking, it should be all-inclusive, clear, and final, but the current approach fails to meet all of those. |
The request metadata, which, crucially, include my IP. Put another way, I do want to help the Atom team collect usage information; I do not want to aid the intermediary. Therefore, when prompted to share my data, I will select the emotion-laden 'no' option. But despite of that, my IP will have now been transmitted to Google. This is all assumes I've knowledge that you use Google Analytics, which is only by accident. |
|
We set the AIP flag on all requests to Google Analytics. When Google receive the analytics request they immediately set the last octet in the IP address to zero before it is ever written to disk. |
|
Just a comment from the other side of the fence. I'm not on the atom team. I also don't understand the feelings that are motivating this discussion. Certainly, I don't want the atom team knowing the exact file names (or worse file contents) of the proprietary software I work on at work. That never has (and I presume never will) be sent. However, I feel like there is some expectation that any software which is free (as in beer) and open source must behave a certain way. I think that's wrong. These developers get paid specifically because they can show their management that people are using the software. They literally can do their job better when you give them more information to work with. If you have some problem sending that information, that's fine. They're making it easier than ever to opt out of sending your startup time and crashes. There is even an option, if you truly don't want any data at all sent, to do that. I would argue that not making that option face-up is the right move. If they're nudging you towards helping out, I say that's a laudable move, not a dark pattern. I don't have the data to back it up, but I suspect a lot of people genuinely do want to help out in any way possible. See for example the comment above about "unlimited" as an option. |
That's good to hear, though I shouldn't have to find out about it twenty or thirty comments into an issue here on GitHub - and that is exactly the point I am making.
I find guilt-tripping users into sharing their usage data, and not disclosing exactly what [1] information is transmitted and to whom questionable. For my part, I don't think there's absolutely gotta be an opt-out; what I do expect is frankness. I just don't want me or other people to be taken by surprise. Would disambiguating what it means for the selection to be 'registered' be such a bad thing, for instance? [1] +1 for adding a link to the 'metrics' package, but what about 'exception-reporting'? |
This still assumes that Google behaves as claimed, and is not sufficient reason to ignore a user's preference concerning tracking. The data should just not be sent to Google or anywhere else in the first place if the user has not explicitly consented to this.
It has nothing to do with it being open-source software. It has to do with the application being misleading and disrespectful in its handling of user privacy.
I have already addressed this issue, with several examples of how that kind of information can be obtained without violating user privacy (none of which have really been responded to at all). This is a non-argument.
Why? It's misleading at best. How is this "the right move"? What do users stand to gain from it? |
No, this is a bad take. It's absolutely not okay because it's only once. It's still transmitting the user's IP address (which is a street address in the right hands, such as Google), a timestamp, and the fact that the user just launched Atom to thousands of people. It's compounded by the fact that you have explicit withdrawal of consent to such tracking, and yet you're still spying. This is really, really bad. When the user opts out of tracking, you don't get to make any more web requests using their computer. Doing so makes the opt-out button fraudulent. As others have pointed out, the text below it does not even plainly indicate that it's going to be transmitting this information to thousands of other people, instead opting for the weasel word "register". You're so close, with the consent dialog. You're like 99% of the way there. Now all you have to do is, you know, make the opt-out button actually stop tracking. |
|
Actually, revisiting this: this is probably a GDPR violation, as it stands. |
I guess as long as they don't get sued they don't care. Business as usual... |
Is this a joke? You are literally describing spyware and you are fine with it. If this is important for you, just ask the user before pinging google?
This must also be some kind of filthy joke. |
New telemetry consent setting that will be used by metrics and exception-reporter to determine whether to collect anonymous usage statistics, exception reports etc.
All parts are required for this to work correctly;