Re: [Monotone-devel] [RFC] M.T. phone home

[Timothy Brownawell]

On Thu, 2006-06-08 at 01:45 -0700, Nathaniel Smith wrote:
> It would be useful to record the time each command is run at, so we
> can look at histories of use as well as simple frequencies (e.g., for
> the "which commands are run in sequence?" question mentioned above).

This would really only need, say, the time of day, rather than a full
timestamp. In case full timestamps would worry (some) people.

> To make this data even more effective, it would be useful to include a
> persistent random "cookie" with each bundle of data, so that multiple
> bundles from the same person could be knitted together into a single
> history.  This may be controversial, though, even though it does not
> involve personally identifiable data!  What do people think?

Ask them when asking permission to send it?

> The next question is how this is presented to the user.  Obviously,
> there would be some way to disable the functionality entirely.  (This

This would have to be available as both a compile-time option, and a
run-time (db var, or item in $CONFDIR?) option. I'm sure we have some
users who wouldn't want this functionality anywhere near their code.

> is needed for technical reasons as well, see the NTP kiss-of-death
> packet for comparison.)  The UI for if it is not disabled is not
> entirely clear -- the most conservative option would be for it to ship
> disabled, and only be enabled by people who came across a description
> of it hidden in the manual somewhere, and then took action to turn it
> on.  If we make it _this_ obscure, though, then most people are not
> going to even bother, which could make the whole exercise pointless.
> An intermediate version would be something like:
>   -- by default, records data but doesn't do anything with it
>   -- after recording X bytes, starts (occasionally or always?) giving
>      the user a little hint "hey, I have some data, maybe decide if I
>      should send it"

Some anonymous usage statistics have been collected in $CONFDIR/stats.
Run "mtn usage-stats send" to send this to the developers. The database
    of collected statistics is publicly available at
    http://venge.net/monotone/usage-stats/
Run "mtn usage-stats autosend" to send this to the developers, and
    automatically send further stats as they are collected.
Run "mtn usage-stats disable" to disable statistics collection.
Run "mtn usage-stats show" to show what would be sent.

>   -- after recording, say, 2X bytes without any response, disable the
>      functionality and delete the log file (so as not to waste their
>      hard-drive space).
> If someone _does_ decide to enable the functionality, then we could,
> how about, whenever they run push/pull/sync, if we have X bytes of
> data, post them back to us.  The biggest problem here is making sure
> that this doesn't interfere with use otherwise -- like, if they're not
> actually connected to the network, we don't want to freeze trying to
> resolve venge.net!  Perhaps the answer is to perform the actual

Async dns libraries are nice, we could start resolving when the command
was run, and cancel if there's no reply by the time were done...

> operation first, and then print a message saying what we're trying to

And stating that we're only doing it because we beleive they
specifically enabled it.

> do, and that if it freezes or they're just feeling ornery that they
> can just hit C-c to skip it (and "mtn <whatever>" to disable it in the
> future).
> 
> Obviously, we would never send in any data without the user having
> explicitly taken some action to allow it.

And we should mention what we're doing, and that they specifically
allowed it, and how to disable it, every time we send anything.

> Finally, once we have the data... I would very much like to make all
> the data simply available publically; keeping track of who exactly was
> allowed to access it would be a big pain, reduce the usefulness, and
> would mean that e.g. people working on other VCSes or studying FOSS
> generally couldn't use it.  So that's one of the reasons that the list
> above is so careful about not gathering personally identifiable
> information.  This is yet another thing I'd like feedback on, though.

Publicly available is good. It also means we don't have to worry about
security compromises and resulting annoyed users.


Tim