On 15/02/18 10:05, Will Cooke wrote: > On 14 February 2018 at 18:37, Alistair Buxton <a.j.bux...@gmail.com > <mailto:a.j.bux...@gmail.com>> wrote: > > > * Information from the installation would be sent over HTTPS to a > service > > run by Canonical’s IS team. This would be saved to disk and sent on > first > > boot once there is a network connection. The file containing this data > > would be available for the user to inspect. > > So you ask the user during install. Then the data is sent on first > boot. At what point can the user inspect the data, given that some of > it can't be collected until after installation is finished? It seems > like the first opportunity will be after it has been sent, unless you > ask the user a second time. So why not just ask them on first boot, > when you have already gathered all the data? That way user can inspect > the data there and then before deciding how to answer. > > > Yes, I think the first opportunity would be after it has been sent. I'm > generally against asking more questions on login though, I think it > would be clunky.
Am I reading it correctly that you will allow the user to see what data had been gathered from the system only _after_ it has been sent? That comes across as needlessly sneaky. Surely it could be deferred until the after the user has had the opportunity to agree properly? As an existing implementation, the Steam client has a perfectly good way of doing this - it pops up a dialogue box, asks whether it can send system data, shows the data that would be sent, and explains why it is useful and why you should consider allowing it. On 14/02/18 15:22, Will Cooke wrote: > Any user can simply opt out by unchecking the box, which triggers one > simple POST stating, “diagnostics=false”. This doesn't scan right either - you're collecting data about someone opting out of data collection? I can see the reasons behind collecting data but let's not make the collection process needlessly aggressive. That's just going to make people defensive and find ways of disabling/avoiding it entirely (e.g. network blocks) instead of considering how it can help Ubuntu in the long-run. An overly-aggressive approach also makes it much more difficult for other projects to implement statistics collection without users equating it with user tracking/telemetry/spying/etc. and complaining vociferously (even without any real understanding of what the process means - just the presence of the words "data collection" is enough to generate an awful lot of noise). J
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel