Re: [RFC PATCH v1] telemetry design overview (part 1)
- Date: Sat, 9 Jun 2018 08:56:00 +0200
- From: Johannes Sixt <j6t@xxxxxxxx>
- Subject: Re: [RFC PATCH v1] telemetry design overview (part 1)
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