Re: Metrics and your privacy
- From: Bruno Wolff III <bruno@xxxxxxxx>
- Date: Thu, 23 Nov 2006 08:04:34 -0600
On Thu, Nov 23, 2006 at 09:44:36 +0000,
Andy Green <andy@xxxxxxxxxxx> wrote:
Bruno Wolff III wrote:
Hi Bruno -
However, when I do an install on a machine there isn't a good reason that
I should need to provide a public IP address for that machine in order to
do the install. I might for instance do downloads at one machine and then
use them on several machines in different physical locations.
Yes, this is a fair enough complaint, it would be wrong to link the
install action with a *requirement* to touch anything external. But it
should be okay to propose to the user on firstboot to check for updates,
which he probably wants to do anyway, is in his interests and he can
deny it.
I like Alan's suggestion. I think the real issues here is that the information
being gathered needs to be transparent and providing it needs to be optional
with the user actively consenting.
I consider any software that makes network connections back to the supplier
for reasons not part of the function the software is providing to me to
be spyware since it is supplying my IP address to the provider.
It's not a bad definition. The yum traffic generated by a user is
legitimate to use under that definition.
Just to be clear in general given some of the things said by others on
this thread, if I was running a mirror so people could choose to connect
to it and get the benefit of their free updates, for sure I will keep
logs and process then how I like without asking anyone's permission, for
abuse monitoring or anything else I felt like. This is the implicit TOS
of contacting ANY server on the Internet. Anyone here running a public
server NOT keeping logs, to be consistent with any deeply held feelings
about privacy?
I think that is expected practice and people will expect at least that
level of use of IP addresses. It would be nice to state retention times
(and some juristictions may require long retention times of logs) and
any other intended use of the log data that people might not expect.
employees, I think it would be unlikely that a TLA could convince Red Hat
to
secretly put back doors into their products. I don't believe that is true
of most software companies. While the odds of me being affected by this
are very low, I want to support companies that I feel are supporting
freedom.
(I'm probably more at risk of marketting getting my data and annoying me
with
sales propositions.)
This is a different issue, but it wouldn't be RHAT but an upstream
project that got perverted, like that attack on the kernel a while back
where someone changed an if(uid==0) to an if(uid=0) to get root powers
almost invisibly just by going down that code path. Given the way the
OS is composed assuming there are no backdoors already is a matter of
faith (but I agree it is unlikely there are remote backdoors, or we
might have seen the resulting traffic floating by).
That wasn't the direction I was going with this. That's one way to get
back doors into the software. The other is to have someone from the NSA
(or other TLA) have a talk with very high level management and come to
an understanding. The understanding may include favorable consideration
when awarding contracts or approving mergers (for example see the recent
Alcatel - Lucent merger). In return a company may be asked to limit
something it produces to approved people or to limit the functionallity.
For example it is hard to purchase telephones that do end to end encryption.
It is a lot easier for goverments to do this than to have to pass laws
openly that require companies to do these things.
Red Hat could certainly do things like the above. A hypothetical example
would be encryption of the root (/) partition. There is a bugzilla ticket
requesting this feature going back to, I think, the FC3 days. It hints
that this feature might finally be available in FC7. This looks like (and
I believe it to be) ordinary delays for something that is tricky to do
right and which is competing for developer resources with lots of other
projects. However, maybe someone had a talk with a RH exec and said if
you delay this root encryption feature (say by starving it of resources,
which wouldn't necessarily be visible to RH engineers) we will give you
a chance to compete for some miltary contracts and will guaranty that you
get a minimum of X million dollars of business. If you don't play ball,
we will find reasons to not use your services. Since you have competitors
that aren't using open source software, this (finding objections) will be
easy to do.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
- Follow-Ups:
- Re: Metrics and your privacy
- From: Andy Green
- Re: Metrics and your privacy
- References:
- Metrics and your privacy
- From: Mike McGrath
- Re: Metrics and your privacy
- From: AragonX
- Re: Metrics and your privacy
- From: Andy Green
- Re: Metrics and your privacy
- From: Bruno Wolff III
- Re: Metrics and your privacy
- From: Andy Green
- Re: Metrics and your privacy
- From: Bruno Wolff III
- Re: Metrics and your privacy
- From: Andy Green
- Metrics and your privacy
- Prev by Date: Re: Image convertor : raster to vector
- Next by Date: Re: parallel DNS lookups
- Previous by thread: Re: Metrics and your privacy
- Next by thread: Re: Metrics and your privacy
- Index(es):
Relevant Pages
|