Re: [RFC PATCH v1] telemetry design overview (part 1)

[Johannes Sixt <j6t@kdbg.org>]

Am 09.06.2018 um 00:20 schrieb Ævar Arnfjörð Bjarmason:
> 
> On Fri, Jun 08 2018, Johannes Sixt wrote:
> 
>> Am 08.06.2018 um 18:00 schrieb Thomas Braun:
>>> I for my part would much rather prefer that to be a compile time
>>> option so that I don't need to check on every git update on windows
>>> if  this is now enabled or not.
>>
>> This exactly my concern, too! A compile-time option may make it a good
>> deal less worrisome.
> 
> Can you elaborate on how someone who can maintain inject malicious code
> into your git package + config would be thwarted by this being some
> compile-time option, wouldn't they just compile it in?

Of course they can. But would we, the Git community do that?

 From the design document:

 > The goal of the telemetry feature is to be able to gather usage data
 > across a group of production users to identify real-world performance
 > problems in production.  Additionally, it might help identify common
 > user errors and guide future user training.

The goal to gather usage data may be valid for a small subset of Git 
installations. But it is wrong to put this into the software itself, in 
particular when the implementations includes scary things like loading 
unspecified dynamic libraries:

 > If the config setting "telemetry.plugin" contains the pathname to a
 > shared library, the library will be dynamically loaded during start up
 > and events will be sent to it using the plugin API.

When you want usage data, ask your users for feedback. Look over their 
shoulders. But do not ask the software itself to gather usage data. It 
will be abused.

Do not offer open source software that has a "call-home" method built-in.

If you want to peek into the workplaces of YOUR users, then monkey-patch 
survaillance into YOUR version of Git. But please do not burden the rest 
of us.

-- Hannes