First of all, Dr. Cerf, thank you for your opinion. I will now proceed to formulate my own. It may not be as confident, as sweeping, or as eloquent as yours, but I think I'd still rather use it to represent myself, and not borrow yours.:-)
Let's look at an analog. The Government *loves* cryptography. They love it so much because it's very, very good stuff. Good crypto is damn hard to break; in a good (and well-used) implementation of a cryptograhic system, you're better off hiring somebody to go beat the snot out of one of the communicating parties. The trouble is, cryptography is *too* good. As far as the public domain goes (I have no idea what J. Random Spook has up his sleeve) ElGamal or RSA (at sufficient key size of course) is unbeakable. Cryptosystems can, in all likelihood, stop content analysis of your traffic.
Unless a government has figured out how to break these cryptosystems, encrypting your data will keep it relatively well hidden--from Carnivore or anything else like it.
The problem, of course, is Gov't trying to discourage people from using crypto. There are no 'standards bodies' for crypto software... ever wonder why? I can't imagine Big B. is exactly pushing for a public crypto commission.... either way, we have means of protecting our content from simple random sieving.
Personally, I still want to see Carnivore open-sourced (or at least made fully available for public scrutiny) The reason is this: *traffic* analysis.
"Them" reading your mail is about as dangerous as "them" infringing my privacy *and that of my friends and family* by mapping out my sphere of correspondence. Especially if the Feds decide to reduce the national debt by selling out to some junk-mail co's....;-)
Even if I break out my copy of GPG and gin up 3 40Kb keys and triple-encrypt everything I send out, it's still trivial for Big Bother to map out who we talk to, and when. This is traffic analysis. You've probably all heard the stories about how you can tell when something big is going on in (fav. spook group here) by watching the pizza deliveries; this is the same concept.
I haven't browsed through all the Carni comments and Q + A's out there, but I don't recall seeing anything saying they can't do traffic analysis with it.... or indeed what the restrictions are on exactly what data they can legally collect. (not just legally use) Can anyone confirm / deny this, with supporting docs?
The point is, we have technology (of probably high but technically uncertain worth) for content protection. Now we need technology for traffic-pattern protection. See FreeNet for an interesting spin on this.
OK, rant's done. To summarize:
Form your OWN opinion from the facts at hand
Use strong crypto on *all* your messages, even innocuous ones; this is a necessary step in avoiding the "it's encrypted so it must be evil" view
Research new ways of avoiding, spoofing, or otherwise fouling traffic analysis
Engage your brains, and be outspoken to the people that matter (read: not us/.-ers, but your Congresscritters. Tell them you want to see your protection against this sort of tyranny, and that this is a voting issue for you. No vote == no concern to too many of these people:-)
This will be a powerful step towards 'unifying' (and I mean that in a positive sense, not the negative, 'homogenize' sense) the BSD family. I'm a security freak, and I'd love to run OpenBSD... but I *need* SMP support and applications to run on top of it. My primary concern (aside from the SMP) is OpenBSD's 'borrowing' of FreeBSD's ports system. It's (IMHO) infinitely cooler than RedHat's RPMs, and I've heard it's similar to Debian's system (though I haven't used their stuff) The question is, how smooth is the transition from FreeBSD ports to OpenBSD ports?
If this could become a reality (meaning that a package is a package is a package, on all BSDs) it would also make life much easier for those admins who need to work heterogenous environments.
The concept of bringing OpenBSD's security scrutiny to the BSD community at large appeals to me. In fact, this could concievably be a rather powerful tool in the battle for Open Source:
Basically the idea is to create some sort of standards body / code review group, operating independently of any one (free) OS but ideally with input (at least a person or two) from each OS community. This group would check code against portability criteria, stylistic standards, security checks, etc. Heck, you could even have submitted code ranked in these areas.
Once examined, the (formally, legally) Open Sourced code could be put into this central repository (hint: here's the connection to the UniPort thing the post is talking about) and packaged in such a way for standards bodies (maybe an interoperability group, for example) to examine them, ports groups to package them, yada, yada.
This is a rather rough-hewn idea; got any suggestions for it?
1) Deliver the already-promised goods. The original plan said nothing of an ISP contract, or a mysterious 6-8 week Circuit City delay. Some people in my area have postulated that the delay is part of an attempt to get people to call NP about their orders, at which time the new-"upgraded"-model-and-terms-of-service are fed to them. Others think it's merely to give NP time to get all the new gooped-and-maimed IOpeners built and shipped. Either way, NP's not making any friends out there. Give 'em the info straight, guv'nor!
2) If NP *must* pander to the stockholders, then so be it, but have the honor to deal fairly with the people that bought IOs with the understanding that they can be noodled, without an ISP contract. I'd guess NetPliance will easily recoup their losses on all the media coverage and brand-awareness this...erm...situation will give them. What they need to do is turn the situation around, make it positive PR.
3) On that note, opening the IO (no pun intended) is a good idea, as are the new pricing options for no-ISP and extra-hackable gadgetry, but it is not enough. The fair treatment of all customers is a big thing with the Geek Community (witness our love of MS business practices), and the perceived shafting of the Mar 16-20th customers will be a burr in NPs saddle until resolved.
4) The new mods. The Engineer's Motto is: if you can build it, you can deconstruct it. Just as the software industry found with copy protection, any safeguard can be circumvented. How many customers is NP losing while they retool their production lines to goop-n-maim the IOs? Signing an ISP contract at purchase would probably be quite sufficient to legally enforce continued cash inflow (IANAL). What does NP care if their customers tool their IO to run BeOS, so long as NP gets their $$? It's even better if the hackers *don't* dial-in: they don't use NP's ISP bandwidth and phone lines, but NP collects the cash anyway. The only way I could see NP not liking this idea (in my admittedly limited vision) is that they're hoping that ppl will be too lazy/forgetful to cancel if they truly don't want the service.
Slashdot Mirror
Let's look at an analog. The Government *loves* cryptography. They love it so much because it's very, very good stuff. Good crypto is damn hard to break; in a good (and well-used) implementation of a cryptograhic system, you're better off hiring somebody to go beat the snot out of one of the communicating parties. The trouble is, cryptography is *too* good. As far as the public domain goes (I have no idea what J. Random Spook has up his sleeve) ElGamal or RSA (at sufficient key size of course) is unbeakable. Cryptosystems can, in all likelihood, stop content analysis of your traffic.
Unless a government has figured out how to break these cryptosystems, encrypting your data will keep it relatively well hidden--from Carnivore or anything else like it.
The problem, of course, is Gov't trying to discourage people from using crypto. There are no 'standards bodies' for crypto software... ever wonder why? I can't imagine Big B. is exactly pushing for a public crypto commission.... either way, we have means of protecting our content from simple random sieving.
Personally, I still want to see Carnivore open-sourced (or at least made fully available for public scrutiny) The reason is this: *traffic* analysis.
"Them" reading your mail is about as dangerous as "them" infringing my privacy *and that of my friends and family* by mapping out my sphere of correspondence. Especially if the Feds decide to reduce the national debt by selling out to some junk-mail co's.... ;-)
Even if I break out my copy of GPG and gin up 3 40Kb keys and triple-encrypt everything I send out, it's still trivial for Big Bother to map out who we talk to, and when. This is traffic analysis. You've probably all heard the stories about how you can tell when something big is going on in (fav. spook group here) by watching the pizza deliveries; this is the same concept.
I haven't browsed through all the Carni comments and Q + A's out there, but I don't recall seeing anything saying they can't do traffic analysis with it.... or indeed what the restrictions are on exactly what data they can legally collect. (not just legally use) Can anyone confirm / deny this, with supporting docs?
The point is, we have technology (of probably high but technically uncertain worth) for content protection. Now we need technology for traffic-pattern protection. See FreeNet for an interesting spin on this.
OK, rant's done. To summarize:
If this could become a reality (meaning that a package is a package is a package, on all BSDs) it would also make life much easier for those admins who need to work heterogenous environments.
The concept of bringing OpenBSD's security scrutiny to the BSD community at large appeals to me. In fact, this could concievably be a rather powerful tool in the battle for Open Source:
Basically the idea is to create some sort of standards body / code review group, operating independently of any one (free) OS but ideally with input (at least a person or two) from each OS community. This group would check code against portability criteria, stylistic standards, security checks, etc. Heck, you could even have submitted code ranked in these areas.
Once examined, the (formally, legally) Open Sourced code could be put into this central repository (hint: here's the connection to the UniPort thing the post is talking about) and packaged in such a way for standards bodies (maybe an interoperability group, for example) to examine them, ports groups to package them, yada, yada.
This is a rather rough-hewn idea; got any suggestions for it?
Oh yah, to mail me.... sed -e 's/sp.*am\.//g'
1) Deliver the already-promised goods. The original plan said nothing of an ISP contract, or a mysterious 6-8 week Circuit City delay. Some people in my area have postulated that the delay is part of an attempt to get people to call NP about their orders, at which time the new-"upgraded"-model-and-terms-of-service are fed to them. Others think it's merely to give NP time to get all the new gooped-and-maimed IOpeners built and shipped. Either way, NP's not making any friends out there. Give 'em the info straight, guv'nor!
2) If NP *must* pander to the stockholders, then so be it, but have the honor to deal fairly with the people that bought IOs with the understanding that they can be noodled, without an ISP contract. I'd guess NetPliance will easily recoup their losses on all the media coverage and brand-awareness this...erm...situation will give them. What they need to do is turn the situation around, make it positive PR.
3) On that note, opening the IO (no pun intended) is a good idea, as are the new pricing options for no-ISP and extra-hackable gadgetry, but it is not enough. The fair treatment of all customers is a big thing with the Geek Community (witness our love of MS business practices), and the perceived shafting of the Mar 16-20th customers will be a burr in NPs saddle until resolved.
4) The new mods. The Engineer's Motto is: if you can build it, you can deconstruct it. Just as the software industry found with copy protection, any safeguard can be circumvented. How many customers is NP losing while they retool their production lines to goop-n-maim the IOs? Signing an ISP contract at purchase would probably be quite sufficient to legally enforce continued cash inflow (IANAL). What does NP care if their customers tool their IO to run BeOS, so long as NP gets their $$? It's even better if the hackers *don't* dial-in: they don't use NP's ISP bandwidth and phone lines, but NP collects the cash anyway. The only way I could see NP not liking this idea (in my admittedly limited vision) is that they're hoping that ppl will be too lazy/forgetful to cancel if they truly don't want the service.
Just a few thoughts.