Smolt and software information

[Andrew Bartlett]

On Fri, 2007-11-09 at 11:29 -0500, Yaakov Nemoy wrote:
> Hey list,
> 
> There's been a bit of conversation lately in #smolt about collecting
> information about partitioning, hard drive sizes, and most
> importantly, file system types.  I feel it might be just a touch out
> of scope for smolt, since so far our policy has been hardware only.
> The reason this appeals to me the most is if there is any interest in
> file system type used, this would be a good place to collect those
> statistics.  

> 2) Are there any privacy concerns?  Remember smolt is voluntary, and
> so far we don't link any information to machines other than a single
> UUID that is privately stored.  Mainly, the implementation will
> probably be just simply parsing through /etc/fstab.
> 
> Thanks in advance for any input you all are willing to share.

The more we move into tracking software, the more I'm concerned about
smolt.  I've chosen to participate so far, because I would like my
hardware supported better, but for software you risk disclosing things
people perhaps didn't want public like:

 - Do I run patented codecs?
 - Do I run a proprietary kernel module?
 - Do I run software I would rather not let others know I run?

Part of the problem is that the data isn't just sent in terms of a UUID.
Even if not stored, the transmission of the smolt info contains a lot of
personally identifiable information, such as IP addresses, which can be
back-analysed to an identity, and tracked as the UUID remains constant,
but a reported IP moves around the globe...

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20071110/79d5843e/attachment-0002.bin