Re: Metrics and your privacy

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

 



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.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux