[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Phoning home



Steve Langasek writes ("Re: Phoning home"):
> On Mon, Feb 25, 2008 at 10:16:29AM +0100, Giacomo A. Catenazzi wrote:
> > No, I prefer the SHOULD form, because it permit the
> > right thing to be done, giving the debian developer
> > the freedom (and burden) to check what it is bad, and
> > what it is acceptable.
> 
> "should" here would only mean that we've failed to correctly define "phoning
> home".  There's no legitimate reason for Debian packages to phone home, and
> it's always a bug if they do; if this is to be referenced in policy at all,
> this should be made plain.

I think you're twisting the definition here.  `Phoning home' means
connecting to some central server defined by the software developers.
It's value neutral.

If you use `phoning home' to mean only bad things, then we need a new
value-neutral phrase.


But taking your usage on board for the sake of the rest of your
message:

> > Think about:
> > apt
> 
> Not "phoning home":
> 
> - the requests don't contain identifying information about the client, with
>   the exception of the source IP address.

That is often enough to identify an individual user.

> - with the exception of security.d.o, there's no calling back to a central
>   server.

The mirrors are central servers.  I don't think it makes that much
difference whether it's one or more.

> - the requests are central to the functionality of the package, not
>   gratuitous calls for purposes of statistics-gathering.

That's the critical justification.

> - the requests must be initiated by the user.

Ubuntu prompts desktop users with admin ability when updates are
available.  I think this is a very good thing and we should do it too.

> > ntpdate
> 
> Not phoning home, for the same reasons as above (minus the last point).

Of course we don't run these NTP servers.  But we trust pool.ntp.org's
DNS servers (which can discover that our users are Debian users) and
the packages to the actual NTP servers are difficult to identify and
track.

> > clamav-freshclam
> 
> - central to the functionality of the package; if you don't want to be
>   trackable you don't install the package.
> - statistics gathering is a side-effect of the main purpose of the package,
>   and there's no way around this short of anonymizing your client access
>   through tor or similar.

Isn't this just an update downloader ?  What statistics are
collected ?  Do we direct our users to our servers, or to ones run by
upstream ?  If the latter, what privacy assurances do we have and why
do we believe them ?

> > Some of such project collects statistics.
> 
> The issue is not whether packages communicate with projects that collect
> statistics; the issue is whether the packages do so for the *purpose* of
> allowing statistics-gathering.

One of the key principles of data protection is that information
gathered for one purpose should not be used for another.

So information necessarily exposed to make the program work should not
be collected and statistically analysed by our servers even if that is
technically possible to do.

Ian.


Reply to: