Submits a message to a remote server even when "No, don't send any info" is selected

Bug #1761739 reported by Iain Lane
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-initial-setup (Ubuntu)
Triaged
High
Unassigned

Bug Description

I tried out the new Ubuntu mode of gnome-initial setup. I went through the steps, and picked "No, don't send any info". Then on the last page the application froze for several seconds (a separate bug), and I saw this message in the console.

** (gnome-initial-setup:30381): WARNING **: 12:52:10.585: Failed to send decline: data were not delivered successfully to metrics server: couldn't send post http request: Post https://metrics.ubuntu.com/ubuntu/desktop/18.04: dial tcp 92.242.132.16:443: i/o timeout

We tried to send to a remote server even though I picked an option that I intended to not report to you.

I think either we should not send this 'decline' message (this is my preferred option), or we should make it reasonably clear that picking "No" is going to ping home.

Iain Lane (laney)
tags: added: rls-bb-incoming
description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

Right, note that it was described on the list topic
https://lists.ubuntu.com/archives/ubuntu-devel/2018-February/040139.html

"Any user can simply opt out by unchecking the box, which triggers one simple POST stating, “diagnostics=false”."

there was some questions/replies about that in the discussion

Agreed that we should be explicit about the behaviour and inform the users, unsure what options they have though if they disagree since you can't override/close the wizard

Revision history for this message
Robert Ancell (robert-ancell) wrote :

We should definitely make a design call ASAP on this.

Changed in gnome-initial-setup (Ubuntu):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Will Cooke (willcooke) wrote :

I've confirmed with Jamie B that the ping still needs to be sent, so we need to work with design on improving the wording and making it clear than something will still be sent, perhaps showing the contents.

I'll email mpt and ask for info and CC the relevant parties.

tags: added: rls-bb-wontfix
removed: rls-bb-incoming
Revision history for this message
Jeremy Bícha (jbicha) wrote :

Current screenshot for reference

Revision history for this message
Jeremy Bícha (jbicha) wrote :

Wording for this feels like it's going to be awkward. Here's one suggestion

"No, tell Canonical I don't want to send this information."

Revision history for this message
Jeremy Bícha (jbicha) wrote :

or slightly better:

"No, tell Canonical I don't want to send my system info."

Revision history for this message
Iain Lane (laney) wrote :

Can we use this bug as a release bug to track that request then maybe?

One additional reason I'm a bit concerned is that there's (sensibly since otherwise you can end up with an incompletely configured machine) no way to quit gnome-initial-setup, so any wording will need to say that we're sending a ping regardless.

tags: added: rls-bb-notfixing
removed: rls-bb-wontfix
Revision history for this message
Iain Lane (laney) wrote :

mpt's going to come up with something better, but it probably shouldn't be a yes/no question - rather a radio something like

 - Send full report containing system information (view)
 - Send basic report which only reveals your internet address and that you installed Ubuntu flavour version

Revision history for this message
Will Cooke (willcooke) wrote :

To be clear - IP address are not being saved to the database. The data will of course have to come from an IP address, but we're not recording the data submitted against and IP address.

Revision history for this message
Iain Lane (laney) wrote :

(This is probably being tracked elsewhere, but the linked privacy policy might need updating for this. Currently, it mentions *storing* IP addresses in relation to dash searches, and there's not really any other mention apart from

  Canonical may collect non-personally-identifying information of the sort that web browsers and servers typically make available, such as the browser type, referring site, and the date and time of each visitor’s request […]

which to me implies that it is going to be stored.)

I used "reveal" because it's not *in* the report but is metadata associated *with* the report. I think this is interesting to a submitter - although we're not giving them a choice to not submit so maybe it isn't.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

I was looking at updating the "Show First Report" button to show the empty report content if you select "No" but I think that might be misleading. If you select "No", then "Show First Report" then "Yes" you might not notice the text has changed.

Perhaps we should change the design to show the text to be sent below the Yes/No selection, and we can update it automatically as you change your mind. You could hide the text below a GtkExpander or similar by default.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The wording has been changing to "No, don't send system info" which is less misleading since it's indeed not sending any system info, unsure if that's good enough to consider the issue as resolved?

Revision history for this message
Iain Lane (laney) wrote :

My personal opinion is that saying "don't send" when we do send something is the misleading part. OK, maybe no system info is being sent - but something else is and we haven't said that.

If others disagree with me then they are free to close the bug, this is just my 2.

Revision history for this message
Iain Lane (laney) wrote :

cents

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

> I've confirmed with Jamie B that the ping still needs to be sent

> mpt's going to come up with something better

I’m happy to come up with something better, if there’s a reason that I can explain. As I understand it, we let you decline data collection in case you are concerned about privacy. Given that, transmitting data either way is a strange thing to do, so we’d need a solid reason. A choice between “send system info” vs. “send … {something else}”, without a reason, would just make people angry.

I can’t say that it’s for counting users, since a one-time submission is no good for that, not tracking when machines are lost or destroyed or the user goes back to their Windows partition permanently. Weekly Active Device counts for default desktop snaps (currently within 0.9% of each other) would be more accurate for that, unless we have reason to believe that tens of thousands of users uninstall every snap after installation, or that hundreds of Snap Store Proxy users are wildly misreporting their deployments on setup.

And I can’t say it’s to ensure the validity of the sample, because at the magnitude we’re dealing with, the population size is irrelevant for that. (As I’ve calculated before, to get a 2% margin of error with 95% confidence from 500,000 Ubuntu users would require 2390 submissions, while from 100 million Ubuntu users it would require 2401 submissions. Hardly any difference, and we’ve already received massively more submissions than that.)

Revision history for this message
Petter Reinholdtsen (pere-hungry) wrote :

Note, with the current privacy regulations, if Canonical uses consent as the base for submitting this information for collection, I am quite sure it would be against the law to send IP address to a Canonical server when consent is missing. Sending IP address provides time, location and the fact that a given version of Ubuntu is being installed to Ubuntu, and every network sniffing entity on the way like NSA and GCHQ. This set of information is by definition personal information, and by combining the IP address with other sources it is often possible to identify the individual uniquely (for example if the user uses Facebook, log into her email etc). As consent is obviously missing if the user declined to submit the information about his machine, Canonical would have to come up with another basis for the collection. It would be hard to argue it is vital for the operation of the service provided, one of the other options for data collection. It is probably a good idea to check out the GDPR provisions available, to reduce the chance of a large fine.

Revision history for this message
Sebastien Bacher (seb128) wrote :

There is no IP info being sent

Revision history for this message
Petter Reinholdtsen (pere-hungry) wrote :

Of course IP information is sent. Any HTTP connection will pass on the IP address of the other end during establishment of its TCP/IP connection. The fact that HTTP is used over TCP is enough to send the IP address. It could be avoided by enforcing the use of Tor or similar, but that is purely academic given that most people are not using a service to hide their IP address.

Revision history for this message
Will Cooke (willcooke) wrote :

IP addresses are not logged or stored.

Revision history for this message
Petter Reinholdtsen (pere-hungry) wrote :

The fact that you claim to not log or store the IP address is beside my point, which is that the IP address is _transferred_ out of the machine even when the user said no to submitting any information. If consent is your legal basis for submitting information to Ubuntu, it is not valid for transferring the 'I do not want information to be submitted' message over HTTP, independent of what story you provide on what you do with the personal information once it arrive.

Revision history for this message
Henry Coggill (henrycoggill) wrote :

I've observed the same behaviour with Noble installer, and it does appear to be very counter-intuitive for a user to select "Don't send" and then be told that their send request failed.

On a related point, the UI appears to block on this network request - which is probably not necessary - and when the server is not responding in a timely manner it leads to a UI that looks like it's hung.

Changed in gnome-initial-setup (Ubuntu):
status: Triaged → Fix Released
status: Fix Released → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.