10:29 a.m.
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. Personally, when we go make changes to the 'smolt
protocol', we'll leave out the mount point used, so no one knows how
big any given partition is on a particular machine. I have two
questions for everyone.
1) Is this useful? Is this something that we feel the community would
like to see, and that it isn't something that is deserving of a second
statistics aggregator (like a popularity contest for packages would
be)
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.
Cheers,
Yaakov
10:53 a.m.
Am Freitag, den 09.11.2007, 11:29 -0500 schrieb Yaakov Nemoy:
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. Personally, when we go make changes to the 'smolt
protocol', we'll leave out the mount point used, so no one knows how
big any given partition is on a particular machine. I have two
questions for everyone.
1) Is this useful? Is this something that we feel the community would
like to see, and that it isn't something that is deserving of a second
statistics aggregator (like a popularity contest for packages would
be)
2) Are there any privacy concerns? Remember smolt is voluntary, and
A loaded question!
so far we don't link any information to machines other than a
single
UUID that is privately stored.
Privately stored, but not under any form of access control. Smolt lets
the non-admin of a box submit a smolt profile.
Besides, didn't RHN do this? Wasn't one of the reasons for Satellite
server being invented because people don't want their own servers giving
out this kind of information? If yes, then the same reasons apply to
smolt.
Sometimes it *is* useful to give out a smolt UUID to let someone (e.g. a
kernel developer) get at hardware information for a bug report. That's
okay. If you then "extended" smolt to give out more information (it
won't stop here btw), then some of those people won't provide that
information any more, unless they can choose which information they
send.
Mainly, the implementation will
probably be just simply parsing through /etc/fstab.
Thanks in advance for any input you all are willing to share.
Cheers,
Yaakov
11:18 a.m.
On Nov 9, 2007 11:53 AM, nodata <lsof(a)nodata.co.uk> wrote:
> 2) Are there any privacy concerns? Remember smolt is voluntary,
and
A loaded question!
> so far we don't link any information to machines other than a single
> UUID that is privately stored.
Sometimes it *is* useful to give out a smolt UUID to let someone (e.g. a
kernel developer) get at hardware information for a bug report. That's
okay. If you then "extended" smolt to give out more information (it
won't stop here btw), then some of those people won't provide that
information any more, unless they can choose which information they
send.
We do know about some of the standing privacy concerns, but
implementing the solutions is more a time issue. I have winter break
from school in about six weeks, so I'll have a month of cold weather
to inspire some good smolt hacking. Until then, I'm just going over
an idea brought up.
Access controls on the UUID script - Probably a trivial patch to make
it root readable only. I should probably file a bug on it.
Selective information submission - Probably also a good idea, though
the implementation is less than trivial.
Giving out a secondary UUID that has access controls applied - In our
bug reports, the solution is far from trivial, and the number one
thing to do as soon as the semester is over.
We're always listening for ideas about security and privacy, of
course, if you have more good points. :)
Cheers,
Yaakov
11:29 a.m.
Am Freitag, den 09.11.2007, 12:18 -0500 schrieb Yaakov Nemoy:
On Nov 9, 2007 11:53 AM, nodata <lsof(a)nodata.co.uk> wrote:
> > 2) Are there any privacy concerns? Remember smolt is voluntary, and
>
> A loaded question!
>
> > so far we don't link any information to machines other than a single
> > UUID that is privately stored.
>
> Sometimes it *is* useful to give out a smolt UUID to let someone (e.g. a
> kernel developer) get at hardware information for a bug report. That's
> okay. If you then "extended" smolt to give out more information (it
> won't stop here btw), then some of those people won't provide that
> information any more, unless they can choose which information they
> send.
We do know about some of the standing privacy concerns, but
implementing the solutions is more a time issue. I have winter break
from school in about six weeks, so I'll have a month of cold weather
to inspire some good smolt hacking. Until then, I'm just going over
an idea brought up.
Access controls on the UUID script - Probably a trivial patch to make
it root readable only. I should probably file a bug on it.
Done: https://bugzilla.redhat.com/show_bug.cgi?id=373211
Selective information submission - Probably also a good idea, though
the implementation is less than trivial.
Giving out a secondary UUID that has access controls applied - In our
bug reports, the solution is far from trivial, and the number one
thing to do as soon as the semester is over.
We're always listening for ideas about security and privacy, of
course, if you have more good points. :)
Cheers,
Yaakov
1:54 p.m.
nodata wrote:
> 2) Are there any privacy concerns? Remember smolt is voluntary,
and
A loaded question!
:) While I understand the privacy concerns, I don't think that choice
of filesystem is particularly more private than, say, choice to run
selinux, or default runlevel. Do you have any privacy concerns directly
related to collecting this new (filesystem) information, aside from the
bigger picture that affects all data collected?
Thanks,
-Eric
1:58 p.m.
On Nov 9, 2007 2:54 PM, Eric Sandeen <sandeen(a)redhat.com> wrote:
:) While I understand the privacy concerns, I don't think that
choice
of filesystem is particularly more private than, say, choice to run
selinux, or default runlevel. Do you have any privacy concerns directly
related to collecting this new (filesystem) information, aside from the
bigger picture that affects all data collected?
nope, that's why I asked if anyone else has.
-Yaakov
7:53 p.m.
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.
8:35 p.m.
On Nov 9, 2007 8:53 PM, Andrew Bartlett <abartlet(a)samba.org> wrote:
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?
The client isn't set up to do so yet, but if you wanted, it's possible
to exclude a certain hardware item, because you don't want it revealed
that you use a proprietary driver. We don't record the other bits of
information. This has also been heavily discussed. I hate to think
that every time I ask honest questions about privacy, people suddenly
think smolt is some evil thing because it has inherent privacy
questions. This is why I post questions all the time.
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...
This I think is the number one concern. Smolt does not store any IP
related information in it's database. The source code is available as
it is open source. The server that accepts the incoming data does
receive an IP address, and that is infact unavoidable. We encourage
you to use Tor or other privacy tools if you have a *real* problem.
Our privacy policy states that we don't collect any IP information,
and any identifying information aside from the UUID is entirely
voluntary.
smolts.org AFAIK is hosted in the US. Personally I'm worried that the
Patriot Act and friends will require us to maintain IP logs on the
caching server that is the part that most people interact with when
they actually interact with Smolt. When that happens, we are, and
pardon my french here, screwed. Since IANAL, there is really little I
can say about the privacy issues, although I would personally look at
international hosting.
So when you don't mention any objections to storage of filesystem type
used, that means I have your +0 vote on that issue? ;-P
-Yaakov
9:38 p.m.
On Fri, 2007-11-09 at 21:35 -0500, Yaakov Nemoy wrote:
On Nov 9, 2007 8:53 PM, Andrew Bartlett <abartlet(a)samba.org>
wrote:
> 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?
The client isn't set up to do so yet, but if you wanted, it's possible
to exclude a certain hardware item, because you don't want it revealed
that you use a proprietary driver. We don't record the other bits of
information. This has also been heavily discussed. I hate to think
that every time I ask honest questions about privacy, people suddenly
think smolt is some evil thing because it has inherent privacy
questions. This is why I post questions all the time.
Thankyou for taking so much time and effort to consider the issues, and
for your thoughtful reply.
This I think is the number one concern. Smolt does not store any IP
related information in it's database. The source code is available as
it is open source. The server that accepts the incoming data does
receive an IP address, and that is infact unavoidable.
So when you don't mention any objections to storage of filesystem
type
used, that means I have your +0 vote on that issue? ;-P
It seems harmless enough, but most things do :-)
Perhaps just list it if the filesystems are in the standard set supplied
with Fedora?
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
9:46 p.m.
Andrew Bartlett wrote:
Perhaps just list it if the filesystems are in the standard set
supplied
with Fedora?
So if someone were using "mynewsecretfs" don't report it? I guess I
could see that. Although keeping up the "acceptable to report" list
might be a trick.
-Eric
Andrew Bartlett
9:56 p.m.
On Nov 9, 2007 10:46 PM, Eric Sandeen <sandeen(a)redhat.com> wrote:
Andrew Bartlett wrote:
> Perhaps just list it if the filesystems are in the standard set supplied
> with Fedora?
Nope, the issue was brought up because we already know what Fedora
users use. What Red Hat tell them is good for them. (Actually, ext3
is the default for historical and stability reasons.)
Some users use other OSes shockingly enough; more suprising is that
they don't always like ext3. (You might say they are impatient, and
want their files faster. They call this 'performance', which confuses
me.) It's been mentioned that statistics on that (Just like with
SELinux) would be interesting.
So if someone were using "mynewsecretfs" don't report it? I guess I
could see that. Although keeping up the "acceptable to report" list
might be a trick.
I think we just need a 'modify what we send link' and then a list of
checkboxes to disclude information. This way it's there,
configurable, etc....
Anything else would be tricky.
-Yaakov
6050
days inactive
6051
days old
10 comments
4 participants
participants (4)
-
Andrew Bartlett -
Eric Sandeen -
nodata -
Yaakov Nemoy