THIS. the very concept of an "Internet killswitch" is nonsense on the face of it. Think about it: what, exactly, will the President shut off? MAE-EAST? Google datacenters? Sprint core routers? Facebook webservers? All of Comcast's residential netblocks? Undersea fiber between San Francisco and Australia? The most fundamental aspect of the Internet is its decentralization, designed specifically to PREVENT any single entity from shutting down the network. The entire discussion consists of uninformed blathering from morons and those who hope to make a truckload of money selling them nonsense solutions.
This is a logical step to secure critical infrastructure in the event of an attack. Not some paranoid bill that will allow big brother to sneak in unaware and monitor/control every aspect of the internet.
sure - there's no point in passing redundant legislation when warrantless wiretaps are already a well-established precedent.
Verizon does it (new FiOS customer; love my FiOS, but run my own DNS for this reason primarily (and because I want split-horizon). If they start intercepting port 53 outbound, we're all SOL until DNSSEC becomes ubiquitous.
so the Law of Armed Conflict applies - great. Who are you retaliating against? The IP that attacked you? o rly? I submit that the US Armed Forces cannot even reliably identify the ultimate source of a network attack, much less the identity, motivation or affiliation of an attacker (all of which are necessary in order to provide justification for a measured physical response).
It's going to take another couple of generations before we end up with people commanding the armed forces who grew up on the Internet and have at least some basic clue that you can't just prepend "cyber-" to all your standard tactics and rules of engagement and think you're prepared.
"shut down the tubes" meaning what, exactly? a router? all routers? core or edge or both? BGP sessions? exchange points? private or public?
what I'm driving at here is that the fundamental nature of the Internet, its very definition, is a number of independent networks agreeing to exchange traffic in a decentralized manner. Even shutting down a single large provider (e.g. MCI/UUNet/Verizon/AS701) is an nonsensical statement - what specifically are you shutting down? There are thousands of routers, peering connections, internal interconnects, hand-offs to smaller providers who in turn interconnect and hand off to still smaller providers... the architecture very much resembles a fractal for the larger providers.
Now multiply that complexity by a dozen and you've covered probably 90% of the carriers in the US... but wait, some of these aren't US based carriers! We have quite a few carriers with circuits or presence in the US where the organization is legally located elsewhere. What do you do then?
Telling AT&T to shut down (assuming you can even define that; let's say you mean disconnect from every other provider they peer with, and shutting down their tens of thousands of client connections) would cause damage, but would do little more than isolate AT&T from the rest of the world.
This legislation is an incredibly bad idea for a number of reasons, but the risk it poses to the availability of the Internet as a whole is not one of them.
Temporarily closing down nonessential Internet traffic isn't much different from shutting down the freeway when road conditions make driving on it unsafe. ... I would give the president authority to shut down the Internet for not more than 48 hours, anything more than that should require congressional approval.
the idea of any single entity "shutting down" the Internet is a nonsensical statement, regardless of the entity involved. If you don't understand why, spend some more time thinking about how someone might "shut down" "the Internet". Shutting down a provider or a given link or exchange point, sure. "Shutting down the Internet", not so much.
(this doesn't even touch on the wisdom or propriety of granting any single individual that kind of power, much less the President. Of course that kind of power doesn't exist to grant in the first place, so it's kind of a moo point. You know, like a cow's opinion.)
if you have an iPhone, stanza is my favorite there (support for most formats and integration with a number of online stores, plus a good interface, all at no charge)
Do you trust your data being up in the "cloud"? Do you want to risk that company tanking and your work going away? I don't. I can work fine over a IPSec link to my storage server (with more redundancy) and run subversion to keep track of my work.
if you are trusting your data to only one provider, whether it's yourself or some "cloud computing" vendor, you're doing it wrong.
Redundancy in services/vendors and backups/mirroring is just good practice, and applies whether you're computing circa 1989 or 2009. If you're using multiple vendors, the downside risk of any single one of them going AWOL for some reason is significantly mitigated.
(that said, there's always a SPOF somewhere with the current hierarchical DNS system, but even that can be made fairly robust without breaking the bank.)
if your systems are designed such that a $10K/min single point of failure exists in the first place, you have a bigger problem than upgrading OpenBSD once or twice a year. Seriously, look into redundancy - it's the hip new thing with the kids these days.
(probably not your fault; I've inherited networks like that more than once myself. still, claiming that OpenBSD's refusal to support anything but the current and most recent release is the reason you can't use it is disingenuous. If you're in a production environment, you shouldn't have any system that can't be taken offline for scheduled maintenance (i.e., every system has at least one redundant backup), and if you're not talking production systems... well, I've got OpenBSD boxes still running 3.7 somewhere in the network. They run just fine and still have no remote holes.)
systems architecture, from a conceptual perspective, resembles nothing so much as building large intricate things out of Legos. But instead of using actual Legos, we use pieces of technology, both logical (GB of disk, services like HTTP and DNS, Mbps of network bandwidth, load-balancing topologies, applications) and physical (servers, switches, routers, storage appliances).
We take smaller discrete units (say, a single server) and combine them to make larger units (a cluster), and those larger units can themselves be combined into bigger and bigger pieces (several clusters might power an application, several apps might be served from a datacenter, and several datacenters might be load-balanced to provide better global availability).
I'm told building very large projects from Legos involves a similar hierarchical approach to the architecture, and the metaphor is something most 4th graders could get a handle on (I use it to explain what I do to my folks and non-geek friends all the time).
It's what the internet was founded on, even if it's not used/remembered well. it's still dirt cheap to maintain, too.
don't get me wrong - I'm 100% in favor of retaining Usenet access; I think it's important and definitely one of the historic foundations of the Net (from an end user perspective). But it's only cheap to maintain in terms of support costs and hardware; supporting alt.binaries.* alone takes an inordinate amount of bandwidth, and peering arrangements aside, that kind of thing ain't cheap.
That said, I still think it was tacky of them to drop Usenet - but given the numbers of people who use it these days, a completely predictable (and from a pure business perspective, sensible) step for them to take.
take a look at ESX using NetApp for backend storage - deduplication at a block level can achieve what you are proposing, and then some (only store one copy of whatever-it-is, e.g. explorer.exe or/usr/bin/vi; every VM that would otherwise have an identical copy of $foo has instead pointers to the one set of blocks on-disk that contains $foo. The more VMs you run, the better your space savings.)
... learn BSD, and you know UN*X. I like Slack (started with it back in the day), but I have never learned as much as quickly as the first 6 months of running OpenBSD on the desktop and server every day. Not having to run out to an assortment of websites and info pages to find out how things work is one of the underrated features of OpenBSD (every single piece of the system has a man page that is complete, authoritative and up-to-date. None of this "this is a placeholder, see our info page!" or "see this website" crap that's so common in the man pages of Linux distros).
Learning UN*X by means of BSD gives one a more stable foundation, IMO, than starting with Linux, due primarily to the more cohesive, clean and consistent design of the BSD operating system as compared to the relative chaos of the average ephemeral Linux distro. (one of the things I like about Slack is that it's the most BSD-like of the Linux distros.)
that said, anything that forces you to know _why_ and _how_ something works in order to get it installed and running is going to benefit you much more than any wizard, GUI or automated installer that hides what's going on under the hood.
I've been running the network at ToorCon for the past several years (configs here), and the first year (before I was really helping out at all) we hung the entire con off a Ricochet 56Kbps wireless modem.:) We've had point-to-point wifi links and gigabit drops from hotels, but the last several years at the San Diego Convention Center, we've been using primarily donated EVDO cards as uplinks - mainly because SDCC wants $10,000 per diem for wired network access, with a stipulation of no NAT (making it useless for a conference LAN). This year we'll be running multiple EVDO uplinks load-balanced with OpenBSD; the goal is to have the speed of a wired uplink with the flexibility of cellular access.
If you happen to be at the con, stop by the NOC and say hi.
I have never posted "mod parent up" before, but... mod parent up. That's one of the most well-reasoned and to-the-point explanations of the crux of the issue I have heard from any source so far. Nicely put.
all of that may be true (although there's an awful lot of unrealistic "maybes" involved, particularly as to whether or not the OP controls what OS is in use - go read the article summary again, specifically the portability requirement). I still think the particular combination of requirements was unusual enough to warrant further explanation - or at the very least, to make Brysanix' flame of somebody who responded reasonably enough to "just use Excel or Calc" _un_warranted.
Think about it: if you care enough about the app being F/OSS to make it a requirement, but at the same time make Vista support a requirement, would a reasonable person (in this crowd, a reasonable geek) not be justified in asking what prompted such a half-assed^Wunusual set of requirements? If you're competent enough to be running your own DB and specifying requirements like "must be F/OSS", running it on *nix somewhere is clearly not an obstacle.
(I think this particular horse has been beaten to death now, so I'm done on this thread - a number of solutions that match the original requirements have already been proposed, and although I remain curious as to the rationale, that curiosity will probably remain unsatisfied.)
Slashdot Mirror
yes indeed. I've been tunneling all my outbound traffic over a localhost SSH SOCKS proxy for years precisely because I don't want anybody else on the LAN (wireless or otherwise) to be able to sniff that traffic. my ISP sniffing, well, I'm stuck with that for non-HTTPS traffic - but I can prevent the rest. To wit: http://cleverhacks.tumblr.com/post/443759182/ssh-its-whats-for-dinner-or-socks-proxy-port and if you can't get out on anything but tcp/443, see also: http://cleverhacks.tumblr.com/post/816507010/ssh-over-ssl-tunneling
THIS. the very concept of an "Internet killswitch" is nonsense on the face of it. Think about it: what, exactly, will the President shut off? MAE-EAST? Google datacenters? Sprint core routers? Facebook webservers? All of Comcast's residential netblocks? Undersea fiber between San Francisco and Australia? The most fundamental aspect of the Internet is its decentralization, designed specifically to PREVENT any single entity from shutting down the network. The entire discussion consists of uninformed blathering from morons and those who hope to make a truckload of money selling them nonsense solutions.
This is a logical step to secure critical infrastructure in the event of an attack. Not some paranoid bill that will allow big brother to sneak in unaware and monitor/control every aspect of the internet.
sure - there's no point in passing redundant legislation when warrantless wiretaps are already a well-established precedent.
Verizon does it (new FiOS customer; love my FiOS, but run my own DNS for this reason primarily (and because I want split-horizon). If they start intercepting port 53 outbound, we're all SOL until DNSSEC becomes ubiquitous.
*sigh* IMDB fail; try this Equilibrium instead.
Excuse me citizen - I believe you've missed your Interval; please report to the nearest Ministry office for assessment.
so the Law of Armed Conflict applies - great. Who are you retaliating against? The IP that attacked you? o rly? I submit that the US Armed Forces cannot even reliably identify the ultimate source of a network attack, much less the identity, motivation or affiliation of an attacker (all of which are necessary in order to provide justification for a measured physical response).
It's going to take another couple of generations before we end up with people commanding the armed forces who grew up on the Internet and have at least some basic clue that you can't just prepend "cyber-" to all your standard tactics and rules of engagement and think you're prepared.
Say what you will about Microsoft, but I'll start using Linux on my production machines when I want to start losing money. Get the facts, people.
2/10
obvious troll is obvious.
"shut down the tubes" meaning what, exactly? a router? all routers? core or edge or both? BGP sessions? exchange points? private or public?
what I'm driving at here is that the fundamental nature of the Internet, its very definition, is a number of independent networks agreeing to exchange traffic in a decentralized manner. Even shutting down a single large provider (e.g. MCI/UUNet/Verizon/AS701) is an nonsensical statement - what specifically are you shutting down? There are thousands of routers, peering connections, internal interconnects, hand-offs to smaller providers who in turn interconnect and hand off to still smaller providers ... the architecture very much resembles a fractal for the larger providers.
Now multiply that complexity by a dozen and you've covered probably 90% of the carriers in the US ... but wait, some of these aren't US based carriers! We have quite a few carriers with circuits or presence in the US where the organization is legally located elsewhere. What do you do then?
Telling AT&T to shut down (assuming you can even define that; let's say you mean disconnect from every other provider they peer with, and shutting down their tens of thousands of client connections) would cause damage, but would do little more than isolate AT&T from the rest of the world.
This legislation is an incredibly bad idea for a number of reasons, but the risk it poses to the availability of the Internet as a whole is not one of them.
Temporarily closing down nonessential Internet traffic isn't much different from shutting down the freeway when road conditions make driving on it unsafe.
...
I would give the president authority to shut down the Internet for not more than 48 hours, anything more than that should require congressional approval.
the idea of any single entity "shutting down" the Internet is a nonsensical statement, regardless of the entity involved. If you don't understand why, spend some more time thinking about how someone might "shut down" "the Internet". Shutting down a provider or a given link or exchange point, sure. "Shutting down the Internet", not so much.
(this doesn't even touch on the wisdom or propriety of granting any single individual that kind of power, much less the President. Of course that kind of power doesn't exist to grant in the first place, so it's kind of a moo point. You know, like a cow's opinion.)
Hypocrisy and greed, not that I've come to expect anything else from American companies.
s/American//
FTFY.
if you have an iPhone, stanza is my favorite there (support for most formats and integration with a number of online stores, plus a good interface, all at no charge)
minimum hardware requirements for Windows 7. :)
Do you trust your data being up in the "cloud"? Do you want to risk that company tanking and your work going away? I don't. I can work fine over a IPSec link to my storage server (with more redundancy) and run subversion to keep track of my work.
if you are trusting your data to only one provider, whether it's yourself or some "cloud computing" vendor, you're doing it wrong.
Redundancy in services/vendors and backups/mirroring is just good practice, and applies whether you're computing circa 1989 or 2009. If you're using multiple vendors, the downside risk of any single one of them going AWOL for some reason is significantly mitigated.
(that said, there's always a SPOF somewhere with the current hierarchical DNS system, but even that can be made fairly robust without breaking the bank.)
if by "cracked" you mean "brute-forced his password" or maybe "brute-forced him until he gave up his password", then yeah, I believe you.
Ken Thompson aside, I doubt there are purpose-built backdoors in any open source encryption project (commercial is another matter entirely).
holes that can be exploited, on the other hand, are probably a dime a dozen.
if your systems are designed such that a $10K/min single point of failure exists in the first place, you have a bigger problem than upgrading OpenBSD once or twice a year. Seriously, look into redundancy - it's the hip new thing with the kids these days.
(probably not your fault; I've inherited networks like that more than once myself. still, claiming that OpenBSD's refusal to support anything but the current and most recent release is the reason you can't use it is disingenuous. If you're in a production environment, you shouldn't have any system that can't be taken offline for scheduled maintenance (i.e., every system has at least one redundant backup), and if you're not talking production systems ... well, I've got OpenBSD boxes still running 3.7 somewhere in the network. They run just fine and still have no remote holes.)
why, it's almost like charging to send email (thank you slashdot for the original post)
systems architecture, from a conceptual perspective, resembles nothing so much as building large intricate things out of Legos. But instead of using actual Legos, we use pieces of technology, both logical (GB of disk, services like HTTP and DNS, Mbps of network bandwidth, load-balancing topologies, applications) and physical (servers, switches, routers, storage appliances).
We take smaller discrete units (say, a single server) and combine them to make larger units (a cluster), and those larger units can themselves be combined into bigger and bigger pieces (several clusters might power an application, several apps might be served from a datacenter, and several datacenters might be load-balanced to provide better global availability).
I'm told building very large projects from Legos involves a similar hierarchical approach to the architecture, and the metaphor is something most 4th graders could get a handle on (I use it to explain what I do to my folks and non-geek friends all the time).
It's what the internet was founded on, even if it's not used/remembered well. it's still dirt cheap to maintain, too.
don't get me wrong - I'm 100% in favor of retaining Usenet access; I think it's important and definitely one of the historic foundations of the Net (from an end user perspective). But it's only cheap to maintain in terms of support costs and hardware; supporting alt.binaries.* alone takes an inordinate amount of bandwidth, and peering arrangements aside, that kind of thing ain't cheap.
That said, I still think it was tacky of them to drop Usenet - but given the numbers of people who use it these days, a completely predictable (and from a pure business perspective, sensible) step for them to take.
take a look at ESX using NetApp for backend storage - deduplication at a block level can achieve what you are proposing, and then some (only store one copy of whatever-it-is, e.g. explorer.exe or /usr/bin/vi; every VM that would otherwise have an identical copy of $foo has instead pointers to the one set of blocks on-disk that contains $foo. The more VMs you run, the better your space savings.)
... learn BSD, and you know UN*X. I like Slack (started with it back in the day), but I have never learned as much as quickly as the first 6 months of running OpenBSD on the desktop and server every day. Not having to run out to an assortment of websites and info pages to find out how things work is one of the underrated features of OpenBSD (every single piece of the system has a man page that is complete, authoritative and up-to-date. None of this "this is a placeholder, see our info page!" or "see this website" crap that's so common in the man pages of Linux distros).
Learning UN*X by means of BSD gives one a more stable foundation, IMO, than starting with Linux, due primarily to the more cohesive, clean and consistent design of the BSD operating system as compared to the relative chaos of the average ephemeral Linux distro. (one of the things I like about Slack is that it's the most BSD-like of the Linux distros.)
that said, anything that forces you to know _why_ and _how_ something works in order to get it installed and running is going to benefit you much more than any wizard, GUI or automated installer that hides what's going on under the hood.
http://darkuncle.net/OpenBSD/OpenBSD_dualboot.txt if you want to try it on a system that's already running Windows ...
I've been running the network at ToorCon for the past several years (configs here), and the first year (before I was really helping out at all) we hung the entire con off a Ricochet 56Kbps wireless modem. :) We've had point-to-point wifi links and gigabit drops from hotels, but the last several years at the San Diego Convention Center, we've been using primarily donated EVDO cards as uplinks - mainly because SDCC wants $10,000 per diem for wired network access, with a stipulation of no NAT (making it useless for a conference LAN). This year we'll be running multiple EVDO uplinks load-balanced with OpenBSD; the goal is to have the speed of a wired uplink with the flexibility of cellular access.
If you happen to be at the con, stop by the NOC and say hi.
I have never posted "mod parent up" before, but ... mod parent up. That's one of the most well-reasoned and to-the-point explanations of the crux of the issue I have heard from any source so far. Nicely put.
I seem to recall a state whose title prominently featured both those words. Now what was it?
Ah yes... the German Democratic Republic (GDR).
It's what people do that matters - not what they say about themselves.
indeed, paraphrasing something penned much more recently, "It's what we do, not what we claim to be, that defines us."
all of that may be true (although there's an awful lot of unrealistic "maybes" involved, particularly as to whether or not the OP controls what OS is in use - go read the article summary again, specifically the portability requirement). I still think the particular combination of requirements was unusual enough to warrant further explanation - or at the very least, to make Brysanix' flame of somebody who responded reasonably enough to "just use Excel or Calc" _un_warranted.
Think about it: if you care enough about the app being F/OSS to make it a requirement, but at the same time make Vista support a requirement, would a reasonable person (in this crowd, a reasonable geek) not be justified in asking what prompted such a half-assed^Wunusual set of requirements? If you're competent enough to be running your own DB and specifying requirements like "must be F/OSS", running it on *nix somewhere is clearly not an obstacle.
(I think this particular horse has been beaten to death now, so I'm done on this thread - a number of solutions that match the original requirements have already been proposed, and although I remain curious as to the rationale, that curiosity will probably remain unsatisfied.)