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.
