[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: [RFC] M.T. phone home
From: |
Daniel Carosone |
Subject: |
Re: [Monotone-devel] Re: [RFC] M.T. phone home |
Date: |
Wed, 14 Jun 2006 12:20:02 +1000 |
User-agent: |
Mutt/1.5.11 |
On Tue, Jun 13, 2006 at 06:55:03PM -0700, Nathaniel Smith wrote:
> Here are some options on how one could gather usage data from users:
> [..]
> We all definitely agree that (0) is fine, and that (6) is not.
> (Dan Carosone: I'd love to hear your answer here too, since you've
> also come down strongly against this general approach on IRC.)
1 isn't much use because noone will have the code in their installed
program. 2 is about as far as i'd like to go, but i recognise that 3
(and a couple beyond) tend to split pretty fine differences on top of
this.
Within that difference, I think I like that the act of sending the
data *isn't* part of monotone, even for the sake of convenience. It
makes it that much clearer as an explicit voluntary opt-in step - no
real grounds for accusations that we might be sending stuff behind the
users back, or even when a naive user runs the command to see what it
does.
There are also practical/pragmatic aspects here: people behind
firewalls, proxies that require authentication, and any other kind of
network obstruction that will add configuration and complexity to any
internal "send info" command.
And of course there's still the question of what information we can
reasonably collect to still make this all useful enough to be worth
the effort.
Here's another idea that might be applicable regardless of stats
collection:
- come up with a series of classifications for various snippets of
info we might log that could have privacy implications: branch names,
file names, IP addresses, etc etc.
- include annotations in a regular consistent format for each
instance of this info that we log, both to crash logs and to
potential activity/stats logs.
- provide some simple regexy tools (even grep -v?) to let users
sanitise or filter out such info up to their own comfort level from
stats *and* crash reports, before sending.
--
Dan.
pgptXKjp_Xy2C.pgp
Description: PGP signature