The government shouldn't be requiring ISPs to disconnect infected computers, no. But ISPs still should be disconnecting infected computers. Not computers that don't run the ISP's anti-virus package, not computers that aren't up-to-date on Windows, but computers that're actively showing the tell-tale signatures of known infections (including spewing spam e-mail). If a computer shows up infected, the user should be warned. If the infection isn't removed fairly soon after, the computer should be disconnected until the user contacts the ISP about solutions.
Think of it like a medical quarantine. We don't quarantine you just because you haven't had your shots. But once you're diagnosed with the actual infectious diseases, you're quarantined until either you get medical treatment and are cured, you get over the infectious stage on your own or you die.
DNSSEC. If the root-zone keys are distributed through an independent channel (ie. downloaded from ICANN and loaded into the local resolver/server software configuration), then even running a root DNS server won't let you forge responses for any part of the DNS tree you don't actually control (ie. have the private keys to generate new signatures for).
The problem is you can't maintain links. The material the link points to can change or be removed entirely, which creates a problem. If I criticize someone's positions or evidence in their article, they can change the article and smear me for having lied about what they said and I can't prove a thing. The only way I can prove they said what I say they said is to make my own copy of their article, one that they can't change, and serve it up off my own servers alongside my commentary on it. And I may need to show the entirety as a defense against claims that I'm cherry-picking statements of theirs and taking them out of context. My only defense against that is to show enough of the article to show that no I'm not taking isolated statements out of context, and that may well be the entirety of the article.
If it's an enterprise using domains, set up your own CA and create your own CA signing certificate. Push that certificate out into the root certificate bundle or database for your browsers etc., and use it to sign all your server certificates. Since browsers can validate your server certificates, they won't complain. Have the certificate available for importing into browsers that don't accept automatic pushes. That should solve the problem, at least internally.
First advice: do not connect the network that runs the SCADA systems to the Internet or to any network that connects to the Internet. Leave an air gap between your control systems and the outside world. It's OK to network them, but make it an isolated, stand-alone network. It's much harder to attack a network when getting access to it requires physically going to one of your offices or plants. It may make it less convenient, but remember you're making it less convenient for the bad guys too and the consequences of a successful attack probably outweigh any inconvenience in having to bring in updates via USB drive or the like. And don't let the vendors cow you. It's your system, after all, and you that's going to be responsible if an attacker causes a problem. If they insist their stuff absolutely needs access to the Internet, ask them point-blank if they'll be willing to sign a binding contract taking full, 100% responsibility for any and all costs stemming from a successful attack on the system from the Internet. If they won't, ask yourself whether you want to be their fall-guy.
It's possible to firewall things thoroughly enough to have indirect connection (eg. the SCADA network connects to your office network, which in turn connects to the Internet, with firewalls at both boundaries), but it's dangerous. You'll need an expert network engineering and design team to do it, and the first thing they're going to ask you is why you need that connection. If you don't have a really good answer for them, you probably don't need even that indirect connection.
Give me a keyboard with the symbols in question on it directly and I'll agree with him. But if I've got to remember arcane multi-key combinations for symbols not printed on keycaps or immediately obvious from what's printed (eg. dead keys for accents and such), or if I've got to remember 3-digit codes for characters, then it's a no-go and I'll stick to what's on the keyboard.
It probably won't be not being able to read your Facebook page. It'll more likely be that one day your Internet connection stops working because your ISP doesn't have enough IPv4 addresses to give one to every subscriber, they can't get any more netblocks, and you happened to be the guy whose computer was turned off when someone else wanted the last free address. Or your company suddenly can't submit it's payroll because the company that processes their payroll started providing IPv6 address resolution and, while your company's machines understand it quite well, the corporate firewall and filtering appliance doesn't and isn't capable of passing the traffic through. And it may very well be comparable to driving your family's car over a cliff with them in it when payday arrives, you need to write that rent check and the paycheck deposit isn't in your checking account and Payroll can't tell you when they'll be able to fix the problem. Note that this isn't theoretical, there've already been problems with Web sites who started providing AAAA records becoming intermittently or permanently inaccessible to people whose machines understand IPv6 but whose ISPs don't yet support it. The software's fully capable of falling back to IPv4 when IPv6 isn't available, but treated the case where IPv6 was available but didn't work as a network failure.
You don't want that question answered. Just like when a car's headed for a sheer cliff, you don't want to know exactly when it'll go over it. You want to avoid ever having to have that question answered.
The reason the day of recekoning's been being pushed back is because the IT techies, even as they've been warning of the inevitable cliff, have also been doing everything they can to push the deadline back. They know there's going to inevitably be problems making the switchover to IPv6, and they're trying to buy as much time as possible so we'll have time to fix any glitches, but sooner or later they're going to run out of ideas and tricks and the deadline's not going to move anymore. Ideally by that point it shouldn't matter because we've taken the warning and done what's needed to avoid the cliff entirely. But if everyone keeps assuming that, just because the deadline's been pushed back once, it'll keep being pushed back indefinitely, well, suddenly going into free-fall as the car's wheels pass over the cliff-edge is not a good feeling.
You want really impressive examples? Look back to the big fireball over Cape Canaveral that a few seconds before was STS-51-L (Challenger), or the big fireball over Texas that a few minutes before was STS-107 (Columbia). Challenger blew up because the managers at NASA knew the O-rings were eroding and would sooner or later be breached, and they brushed this off with "Well, it hasn't happened yet so it won't happen ever.". Columbia disintegrated during re-entry because managers at NASA knew pieces of heavy foam insulation were striking the leading edges of the wings during launch and sooner or later one of those strikes would fatally damage the heat-resistant panels, and they brushed this off with "Well, it hasn't happened yet so it won't happen ever.". When we run out of IPv4 addresses the results won't be quite so pyrotechnic, but if we keep saying "Well, it hasn't happened yet so it won't happen ever." we will end up regretting it.
Translation of Zuckerberg's comments: "Microsoft has loads of cash, and they're willing to cut me an insanely good deal and throw money my way if it's got any chance of giving them a leg up on Google.".
Sure, there's lots of versions of Android out there. But how many of those really matter? No, not in the sense of market share or anything, but in the technical sense of you have to worry about them in the code.
I run into this programming for Unix. Sure, there's probably hundreds of versions of Unix out there, hundreds of thousands if you count variations in installed software. But in large part I can ignore them. The major question is usually "SysV or BSD?", that is are the system's APIs based on BSD's or System V's. Some libraries I care about version but I often only care about large swathes of versions, eg. I care whether OpenSSL is 0.9.7 vs. 0.9.8 but I don't care about 0.9.8e vs. 0.9.8n (other than that 8e has bugs that're fixed in 8n, but that won't usually affect my code). And of course different hardware has different screen resolutions, but then I shouldn't be hard-coding for exact screen resolution anyway. Make the relevant calls to find out the screen size and just adapt to it, and you'll usually find you have a few general sizes you need to handle and a plethora of one real close to one of those general sizes that you can just handle automatically. Eg. a 328-pixel width probably can use the same layout, icon sizes etc. as a 320-pixel width, just make the main area 8 pixels wider or add a pixel to each side of padding and border spaces to make up the 8 pixels.
You don't handle driving a car by learning how to drive a Ford Focus, and then learning how to drive a Ford Fusion, and then learning how to drive a Chevy Cobalt, and then learning how to drive a Toyota Camry, and so on, and then when faced with a Hyundai Sonata you have to sit there and wait for someone to teach you how to drive one because you haven't driven one before. You learn how to drive a car, and you apply that general method to the particular kind of car you're in at the moment. The controls may be a bit different on each make and model, but the truly basic ones boil down to "Manual or automatic?". Beyond that, things like the headlight switch, turn signals, wipers, radio and all the rest are usually a matter of a couple minutes to sort out. If someone complained that there's thousands of makes, models and years of car out there and it's so much work learning to drive all of them, you'd laugh at them I'm sure. Computer systems are the same way: you don't learn every variant individually unless you're just starting out, you learn different kinds of systems and how to categorize any particular system by what kind it is in a particular area.
All the major browsers support HTTP digest authentication, which avoids the problem of sending the cleartext password. The major web-server platforms like Apache support it, even IIS supports it as far as I know. And it doesn't require any manipulation of HTTP headers, in fact CGI apps shouldn't even need to worry about it because it's handled at the web-server level by access control directives in the configuration files. The major web server platforms all support path-specific configuration so you don't even need access to the global config files.
For me, when I'm at a hotel I don't use tappable/monitorable e-mail. I'm either using secure IMAP to my own server, running a client on my home machine remotely via X11-over-SSH, or using my own WebMail server (or a Google one) via HTTPS with a check of the certificate. I assume that any time I'm on a "free wi-fi" network there may be proxy servers handling all unencrypted traffic (and potentially trying to MITM SSL traffic), so I avoid running anything across the network that I don't want the general public to see.
HTTP and the browsers already allow for that. It's just that sites don't want to use the built-in HTTP authentication mechanism, they want to roll their own based on form submissions.
When is the simple solution going to be applied by users: never trust links in e-mail. If I got an e-mail from LinkedIn telling me about a contact request, I'd ignore any URL in the e-mail. I'd go to LinkedIn itself through the bookmark already in my browser. If it's a real contact request, it'll be sitting in my inbox there waiting for me. I don't need to trust anything in the e-mail. And if there isn't anything waiting in my inbox, then the e-mail was a fake and I shouldn't be trusting anything in it.
It's the same rule as for unsolicited phone calls. If someone calls you up claiming to be from the power company saying you've got an overdue balance and you have to pay up or have power shut off, you do not accept their helpful offer of doing the payment over the phone if you'll just give them your bank-account number to do an e-check. You've no idea whether it's actually the power company calling or just some random con-man. You thank them, hang up, pull out your last bill and get the customer-service number from that. Then you call that number and ask them about the status of your account. And if they say you are, it's now safe enough to do an e-check because (barring someone having usurped the phone company's switches themselves, or having switched physical bills on you) you know you're really talking to the power company.
And the Strickland campaign might want to point out this ruling in Lenz v. Universal Music where the judge said that copyright holders must consider whether the use of the material constitutes fair use under copyright law before filing their takedown request.
Define "fully patched". On my systems the version numbers often have nothing whatsoever to do with what patches have been applied to them. Sometimes the patchlevel's updated, but many simply don't bother updating the version. And what would they update it to, anyway? There may be thousands of permutations of applied patches, there's no way to assign versions to them.
What security software? I don't know of any "security software" vendors who make anything for my systems. And frankly I'd consider a system that needed security software to be fatally buggy and I'd be replacing it ASAP with something more secure.
Firewall? That's something I run on the border routers to control access to my network. Internally firewalls are verbotten, they cause too many technical problems. Untrusted machines get access via wireless (everything connecting by wireless is by definition untrusted, it's not nailed down permanently to the wiring), with client isolation turned on and access to the internal network only via IPSec VPN. If your machine needs a local firewall to be safe, over on the wireless segment it goes without VPN access so it can't endanger my network.
Malware-free, that's the normal state of my machines. Malware is a hazard to be blocked at the edge of the network, and my systems do a pretty good job of it.
I've been running since the early 80s, and have yet to have anything of that sort found on any machine under my control. Which is more than I can say for the networks I've seen "protected" by the major security vendors, every single one of them has regular problems with malware infections. So, when Microsoft can show me a network that's been running under their system for say 5 years with no machine on it ever needing to be cleaned of malware, then I'll take their recommendations seriously. Until then, well, I'll stick with the procedures and policies that've given me a 25+-year clean track record.
Oh, and one of those policies? No Microsoft software unless absolutely necessary, and when necessary it's use should be heavily controlled and restricted to only those things it's necessary for.
Yes. The Web browser is today's iteration of the IBM 3270 workstation. You'll notice we abandoned the 3270 because it wasn't nearly as flexible as the character-oriented interactive terminals that replaced it.
So, what they're saying is that we simply need applets so Web sites can just run their client application locally on the client machine without needing a lot of setup first. Hmm, I wonder however could we do that?
When trying to figure out how to best put in a screw, the first step is to put down the hammer and go get a screwdriver.
The court shouldn't've ruled she had no commercial interest in her name. Down that path lies a situation where nobody can get redress for libel and slander because they had no interest in their good name. They should've ruled simply that nobody has a right to be the only subject of any particular search. She can hold the search engine liable if she can show the results weren't responsive to that particular search but the search engine put them in anyway. She can't hold the seach engine liable for results that are responsive to her search but merely refer to someone other than her. But she can hold someone liable if they're presenting material that isn't associated with her and isn't associated with what it's being presented as but they're associating it nonetheless. Ie. if a Web site's presenting images that aren't of you or about you, but they're tagging them with your name, you can sue the Web site (but not the search engine that led you to it).
First, there's a bottleneck in the on-chip caches. When a core's working on data it needs to have it in it's cache. And if two cores are working on the same block of memory (block size being determined by cache line size), they need to keep their copies of the cache synchronized. When you get a lot of cores working on the same block of memory, the overhead of keeping the caches in sync starts to exceed the performance gains from the additional cores. That's not new, we've known that in multi-threaded programming for decades: when you've got a lot of threads dependent on the same data items, the locking overhead's going to be the killer. And we've known the solution for just as long: code to avoid lock contention. The easiest is to make it so you don't have multiple threads (cores) working on the same (non-read-only) memory at the same time, that just requires some thinking on the part of the developers.
Second, you only gain from additional cores if there's workload to spread to them usefully. If you've got 8 threads of execution actually running at any given time, you won't gain from having more than 8 cores. And on modern computers often we don't have more than a few threads actually using CPU time at any given moment. The rest are waiting on something and don't need the CPU and, as long as we aren't thrashing execution contexts too badly, they can be ignore from a performance standpoint. To take advantage of truly large numbers of cores, we need to change the applications themselves to parallelize things more. But often applications aren't inherently multi-threaded. Games, yes. Computation, yes. But your average word processor or spreadsheet? It's 99% waiting on the human at the keyboard. You can do a few things in the background, file auto-save and such, but not enough to take advantage of a large number of cores. The things that really take advantage of lots of cores are things like Web servers where you can assign each request to it's own core. And no, browsers don't benefit the same way. On the client side there are so (relatively) few requests and network I/O's so slow relative to CPU speed that you can handle dozens of requests on a single core and still have cycles free assuming you use an efficient I/O model. But it all boils down to the developers actually thinking about parallel programming, and I've noticed a lot of courses of study these days don't go into the brain-bending skull-sweat details of juggling large numbers of threads in parallel.
It works, assuming that the military commander understands that this is both a military and a technical situation. If he sees something that raises a red flag to a military eye, he needs to call the techies' attention to it and have them determine whether it's something the tech ought to be doing or if it's really a problem (which shouldn't take the techies long). By the same token, though, he also has to listen to the techies and, when they see something that doesn't look like something the tech should be doing, pay attention to them and determine whether there's a military reason it's doing that or if it's really a sign of a problem. And if there's a military reason and the techies say "No! If someone's doing that, it's going to open up holes.", listen to them. They know the tech, just like the military guy knows the military side of things, and you can't/shouldn't dismiss the idea that someone on the military side's just being network-clueless and doing the network equivalent of telling a sentry to not demand identification from any HMVs with a general's star painted on them because a general's coming in for an inspection and you don't want to inconvenience him.
Unlike a lot of the rest of the military, techies work best when they know what the goal is and why you want that goal accomplished, and what the restrictions on methods are and why they're there. We've proven in business time and time again that forcing them to just do whatever non-technical management tells them to do results in systems that utterly fail to do the job they're supposed to be doing (even though they meet every single requirement to perfection). There's a reason for the closing line to the filk: "It's just what we asked for, but not what we want!".
Forget at the routers. In a network like this you should be using managed switches, and every switch should be set up with a filter on each port limiting the MAC addresses it'll allow through to just the ones that're supposed to be plugged into that port. Plus, ports that shouldn't be in use should be disabled in the switch and the system should scream if the same authorized MAC address shows up on two different ports at the same time. If you're got wireless, it ought to be doing Radius authentication with those same MAC address checks, and there should be an alarm if both the wireless and the wired MAC addresses of a single authorized device show up at the same time.
Not a problem. As a developer I had full Internet access. Grab SATAN, install it, run it, no problem. If I needed to get it onto the internal network, I just had to burn it to CD and take it over to one of the Support machines that was on the internal network. Or, later on, use ssh and scp to move it to a bastion host and then onto the production-side system I needed it on. Fortunately we were using Unix and X11 and weren't dependent on a full desktop environment, so running all the graphical tools I needed through an SSH X11 tunnel was fairly trivial.
So, what they want is a private IP-based network. No sweat, we've been building those for a couple of decades now. When I did point-of-sale for a truck-stock company, we had our own private network for connecting to our stores, credit-card processors and the like. You need routers, appropriate leased-line or other dedicated bandwidth, and some time spent on a white-board laying out the topology. The only real hard part is making sure you don't connect any machines to this network that also have connections to the public Internet. Yes, this means the machines on that network aren't going to be able to access the public Internet. You wanted a private, isolated network, you get a private, isolated network. If you want to live dangerously you can create appropriate DMZs and firewalls and proxies to give internal machines external access, but remember that that means worms, viruses and other malware can ride in on stuff coming back in through that external access and infect machines inside the perimeter. At that point your "protected" network isn't protected at all (in fact it's probably more vulnerable, since you likely skimped on internal protection since it's supposed to be a protected network).
I sometimes find Google Instant useful, same as with history-based completion in the URL bar of Firefox. But when it's not useful it's easy to ignore and doesn't seem to bog things down any (at least I'm not noticing it). As for the ads, when I'm looking to buy what I'm searching for they're often relevant to my search (and thus useful), and when I'm not they're easy to ignore. A lot of other search/advertising engines seem to get the first bit but ignore the second part about getting out of the way. No, scratch that, they get the second part but consider doing it to be an explicit thing to be avoided. Which I think is why Google's so popular and so profitable.
Slashdot Mirror
The government shouldn't be requiring ISPs to disconnect infected computers, no. But ISPs still should be disconnecting infected computers. Not computers that don't run the ISP's anti-virus package, not computers that aren't up-to-date on Windows, but computers that're actively showing the tell-tale signatures of known infections (including spewing spam e-mail). If a computer shows up infected, the user should be warned. If the infection isn't removed fairly soon after, the computer should be disconnected until the user contacts the ISP about solutions.
Think of it like a medical quarantine. We don't quarantine you just because you haven't had your shots. But once you're diagnosed with the actual infectious diseases, you're quarantined until either you get medical treatment and are cured, you get over the infectious stage on your own or you die.
DNSSEC. If the root-zone keys are distributed through an independent channel (ie. downloaded from ICANN and loaded into the local resolver/server software configuration), then even running a root DNS server won't let you forge responses for any part of the DNS tree you don't actually control (ie. have the private keys to generate new signatures for).
The problem is you can't maintain links. The material the link points to can change or be removed entirely, which creates a problem. If I criticize someone's positions or evidence in their article, they can change the article and smear me for having lied about what they said and I can't prove a thing. The only way I can prove they said what I say they said is to make my own copy of their article, one that they can't change, and serve it up off my own servers alongside my commentary on it. And I may need to show the entirety as a defense against claims that I'm cherry-picking statements of theirs and taking them out of context. My only defense against that is to show enough of the article to show that no I'm not taking isolated statements out of context, and that may well be the entirety of the article.
If it's an enterprise using domains, set up your own CA and create your own CA signing certificate. Push that certificate out into the root certificate bundle or database for your browsers etc., and use it to sign all your server certificates. Since browsers can validate your server certificates, they won't complain. Have the certificate available for importing into browsers that don't accept automatic pushes. That should solve the problem, at least internally.
First advice: do not connect the network that runs the SCADA systems to the Internet or to any network that connects to the Internet. Leave an air gap between your control systems and the outside world. It's OK to network them, but make it an isolated, stand-alone network. It's much harder to attack a network when getting access to it requires physically going to one of your offices or plants. It may make it less convenient, but remember you're making it less convenient for the bad guys too and the consequences of a successful attack probably outweigh any inconvenience in having to bring in updates via USB drive or the like. And don't let the vendors cow you. It's your system, after all, and you that's going to be responsible if an attacker causes a problem. If they insist their stuff absolutely needs access to the Internet, ask them point-blank if they'll be willing to sign a binding contract taking full, 100% responsibility for any and all costs stemming from a successful attack on the system from the Internet. If they won't, ask yourself whether you want to be their fall-guy.
It's possible to firewall things thoroughly enough to have indirect connection (eg. the SCADA network connects to your office network, which in turn connects to the Internet, with firewalls at both boundaries), but it's dangerous. You'll need an expert network engineering and design team to do it, and the first thing they're going to ask you is why you need that connection. If you don't have a really good answer for them, you probably don't need even that indirect connection.
Give me a keyboard with the symbols in question on it directly and I'll agree with him. But if I've got to remember arcane multi-key combinations for symbols not printed on keycaps or immediately obvious from what's printed (eg. dead keys for accents and such), or if I've got to remember 3-digit codes for characters, then it's a no-go and I'll stick to what's on the keyboard.
It probably won't be not being able to read your Facebook page. It'll more likely be that one day your Internet connection stops working because your ISP doesn't have enough IPv4 addresses to give one to every subscriber, they can't get any more netblocks, and you happened to be the guy whose computer was turned off when someone else wanted the last free address. Or your company suddenly can't submit it's payroll because the company that processes their payroll started providing IPv6 address resolution and, while your company's machines understand it quite well, the corporate firewall and filtering appliance doesn't and isn't capable of passing the traffic through. And it may very well be comparable to driving your family's car over a cliff with them in it when payday arrives, you need to write that rent check and the paycheck deposit isn't in your checking account and Payroll can't tell you when they'll be able to fix the problem. Note that this isn't theoretical, there've already been problems with Web sites who started providing AAAA records becoming intermittently or permanently inaccessible to people whose machines understand IPv6 but whose ISPs don't yet support it. The software's fully capable of falling back to IPv4 when IPv6 isn't available, but treated the case where IPv6 was available but didn't work as a network failure.
You don't want that question answered. Just like when a car's headed for a sheer cliff, you don't want to know exactly when it'll go over it. You want to avoid ever having to have that question answered.
The reason the day of recekoning's been being pushed back is because the IT techies, even as they've been warning of the inevitable cliff, have also been doing everything they can to push the deadline back. They know there's going to inevitably be problems making the switchover to IPv6, and they're trying to buy as much time as possible so we'll have time to fix any glitches, but sooner or later they're going to run out of ideas and tricks and the deadline's not going to move anymore. Ideally by that point it shouldn't matter because we've taken the warning and done what's needed to avoid the cliff entirely. But if everyone keeps assuming that, just because the deadline's been pushed back once, it'll keep being pushed back indefinitely, well, suddenly going into free-fall as the car's wheels pass over the cliff-edge is not a good feeling.
You want really impressive examples? Look back to the big fireball over Cape Canaveral that a few seconds before was STS-51-L (Challenger), or the big fireball over Texas that a few minutes before was STS-107 (Columbia). Challenger blew up because the managers at NASA knew the O-rings were eroding and would sooner or later be breached, and they brushed this off with "Well, it hasn't happened yet so it won't happen ever.". Columbia disintegrated during re-entry because managers at NASA knew pieces of heavy foam insulation were striking the leading edges of the wings during launch and sooner or later one of those strikes would fatally damage the heat-resistant panels, and they brushed this off with "Well, it hasn't happened yet so it won't happen ever.". When we run out of IPv4 addresses the results won't be quite so pyrotechnic, but if we keep saying "Well, it hasn't happened yet so it won't happen ever." we will end up regretting it.
Translation of Zuckerberg's comments: "Microsoft has loads of cash, and they're willing to cut me an insanely good deal and throw money my way if it's got any chance of giving them a leg up on Google.".
Sure, there's lots of versions of Android out there. But how many of those really matter? No, not in the sense of market share or anything, but in the technical sense of you have to worry about them in the code.
I run into this programming for Unix. Sure, there's probably hundreds of versions of Unix out there, hundreds of thousands if you count variations in installed software. But in large part I can ignore them. The major question is usually "SysV or BSD?", that is are the system's APIs based on BSD's or System V's. Some libraries I care about version but I often only care about large swathes of versions, eg. I care whether OpenSSL is 0.9.7 vs. 0.9.8 but I don't care about 0.9.8e vs. 0.9.8n (other than that 8e has bugs that're fixed in 8n, but that won't usually affect my code). And of course different hardware has different screen resolutions, but then I shouldn't be hard-coding for exact screen resolution anyway. Make the relevant calls to find out the screen size and just adapt to it, and you'll usually find you have a few general sizes you need to handle and a plethora of one real close to one of those general sizes that you can just handle automatically. Eg. a 328-pixel width probably can use the same layout, icon sizes etc. as a 320-pixel width, just make the main area 8 pixels wider or add a pixel to each side of padding and border spaces to make up the 8 pixels.
You don't handle driving a car by learning how to drive a Ford Focus, and then learning how to drive a Ford Fusion, and then learning how to drive a Chevy Cobalt, and then learning how to drive a Toyota Camry, and so on, and then when faced with a Hyundai Sonata you have to sit there and wait for someone to teach you how to drive one because you haven't driven one before. You learn how to drive a car, and you apply that general method to the particular kind of car you're in at the moment. The controls may be a bit different on each make and model, but the truly basic ones boil down to "Manual or automatic?". Beyond that, things like the headlight switch, turn signals, wipers, radio and all the rest are usually a matter of a couple minutes to sort out. If someone complained that there's thousands of makes, models and years of car out there and it's so much work learning to drive all of them, you'd laugh at them I'm sure. Computer systems are the same way: you don't learn every variant individually unless you're just starting out, you learn different kinds of systems and how to categorize any particular system by what kind it is in a particular area.
All the major browsers support HTTP digest authentication, which avoids the problem of sending the cleartext password. The major web-server platforms like Apache support it, even IIS supports it as far as I know. And it doesn't require any manipulation of HTTP headers, in fact CGI apps shouldn't even need to worry about it because it's handled at the web-server level by access control directives in the configuration files. The major web server platforms all support path-specific configuration so you don't even need access to the global config files.
For me, when I'm at a hotel I don't use tappable/monitorable e-mail. I'm either using secure IMAP to my own server, running a client on my home machine remotely via X11-over-SSH, or using my own WebMail server (or a Google one) via HTTPS with a check of the certificate. I assume that any time I'm on a "free wi-fi" network there may be proxy servers handling all unencrypted traffic (and potentially trying to MITM SSL traffic), so I avoid running anything across the network that I don't want the general public to see.
HTTP and the browsers already allow for that. It's just that sites don't want to use the built-in HTTP authentication mechanism, they want to roll their own based on form submissions.
When is the simple solution going to be applied by users: never trust links in e-mail. If I got an e-mail from LinkedIn telling me about a contact request, I'd ignore any URL in the e-mail. I'd go to LinkedIn itself through the bookmark already in my browser. If it's a real contact request, it'll be sitting in my inbox there waiting for me. I don't need to trust anything in the e-mail. And if there isn't anything waiting in my inbox, then the e-mail was a fake and I shouldn't be trusting anything in it.
It's the same rule as for unsolicited phone calls. If someone calls you up claiming to be from the power company saying you've got an overdue balance and you have to pay up or have power shut off, you do not accept their helpful offer of doing the payment over the phone if you'll just give them your bank-account number to do an e-check. You've no idea whether it's actually the power company calling or just some random con-man. You thank them, hang up, pull out your last bill and get the customer-service number from that. Then you call that number and ask them about the status of your account. And if they say you are, it's now safe enough to do an e-check because (barring someone having usurped the phone company's switches themselves, or having switched physical bills on you) you know you're really talking to the power company.
And the Strickland campaign might want to point out this ruling in Lenz v. Universal Music where the judge said that copyright holders must consider whether the use of the material constitutes fair use under copyright law before filing their takedown request.
I've been running since the early 80s, and have yet to have anything of that sort found on any machine under my control. Which is more than I can say for the networks I've seen "protected" by the major security vendors, every single one of them has regular problems with malware infections. So, when Microsoft can show me a network that's been running under their system for say 5 years with no machine on it ever needing to be cleaned of malware, then I'll take their recommendations seriously. Until then, well, I'll stick with the procedures and policies that've given me a 25+-year clean track record.
Oh, and one of those policies? No Microsoft software unless absolutely necessary, and when necessary it's use should be heavily controlled and restricted to only those things it's necessary for.
Yes. The Web browser is today's iteration of the IBM 3270 workstation. You'll notice we abandoned the 3270 because it wasn't nearly as flexible as the character-oriented interactive terminals that replaced it.
So, what they're saying is that we simply need applets so Web sites can just run their client application locally on the client machine without needing a lot of setup first. Hmm, I wonder however could we do that?
When trying to figure out how to best put in a screw, the first step is to put down the hammer and go get a screwdriver.
The court shouldn't've ruled she had no commercial interest in her name. Down that path lies a situation where nobody can get redress for libel and slander because they had no interest in their good name. They should've ruled simply that nobody has a right to be the only subject of any particular search. She can hold the search engine liable if she can show the results weren't responsive to that particular search but the search engine put them in anyway. She can't hold the seach engine liable for results that are responsive to her search but merely refer to someone other than her. But she can hold someone liable if they're presenting material that isn't associated with her and isn't associated with what it's being presented as but they're associating it nonetheless. Ie. if a Web site's presenting images that aren't of you or about you, but they're tagging them with your name, you can sue the Web site (but not the search engine that led you to it).
What they're saying is basically two things:
First, there's a bottleneck in the on-chip caches. When a core's working on data it needs to have it in it's cache. And if two cores are working on the same block of memory (block size being determined by cache line size), they need to keep their copies of the cache synchronized. When you get a lot of cores working on the same block of memory, the overhead of keeping the caches in sync starts to exceed the performance gains from the additional cores. That's not new, we've known that in multi-threaded programming for decades: when you've got a lot of threads dependent on the same data items, the locking overhead's going to be the killer. And we've known the solution for just as long: code to avoid lock contention. The easiest is to make it so you don't have multiple threads (cores) working on the same (non-read-only) memory at the same time, that just requires some thinking on the part of the developers.
Second, you only gain from additional cores if there's workload to spread to them usefully. If you've got 8 threads of execution actually running at any given time, you won't gain from having more than 8 cores. And on modern computers often we don't have more than a few threads actually using CPU time at any given moment. The rest are waiting on something and don't need the CPU and, as long as we aren't thrashing execution contexts too badly, they can be ignore from a performance standpoint. To take advantage of truly large numbers of cores, we need to change the applications themselves to parallelize things more. But often applications aren't inherently multi-threaded. Games, yes. Computation, yes. But your average word processor or spreadsheet? It's 99% waiting on the human at the keyboard. You can do a few things in the background, file auto-save and such, but not enough to take advantage of a large number of cores. The things that really take advantage of lots of cores are things like Web servers where you can assign each request to it's own core. And no, browsers don't benefit the same way. On the client side there are so (relatively) few requests and network I/O's so slow relative to CPU speed that you can handle dozens of requests on a single core and still have cycles free assuming you use an efficient I/O model. But it all boils down to the developers actually thinking about parallel programming, and I've noticed a lot of courses of study these days don't go into the brain-bending skull-sweat details of juggling large numbers of threads in parallel.
It works, assuming that the military commander understands that this is both a military and a technical situation. If he sees something that raises a red flag to a military eye, he needs to call the techies' attention to it and have them determine whether it's something the tech ought to be doing or if it's really a problem (which shouldn't take the techies long). By the same token, though, he also has to listen to the techies and, when they see something that doesn't look like something the tech should be doing, pay attention to them and determine whether there's a military reason it's doing that or if it's really a sign of a problem. And if there's a military reason and the techies say "No! If someone's doing that, it's going to open up holes.", listen to them. They know the tech, just like the military guy knows the military side of things, and you can't/shouldn't dismiss the idea that someone on the military side's just being network-clueless and doing the network equivalent of telling a sentry to not demand identification from any HMVs with a general's star painted on them because a general's coming in for an inspection and you don't want to inconvenience him.
Unlike a lot of the rest of the military, techies work best when they know what the goal is and why you want that goal accomplished, and what the restrictions on methods are and why they're there. We've proven in business time and time again that forcing them to just do whatever non-technical management tells them to do results in systems that utterly fail to do the job they're supposed to be doing (even though they meet every single requirement to perfection). There's a reason for the closing line to the filk: "It's just what we asked for, but not what we want!".
Forget at the routers. In a network like this you should be using managed switches, and every switch should be set up with a filter on each port limiting the MAC addresses it'll allow through to just the ones that're supposed to be plugged into that port. Plus, ports that shouldn't be in use should be disabled in the switch and the system should scream if the same authorized MAC address shows up on two different ports at the same time. If you're got wireless, it ought to be doing Radius authentication with those same MAC address checks, and there should be an alarm if both the wireless and the wired MAC addresses of a single authorized device show up at the same time.
Not a problem. As a developer I had full Internet access. Grab SATAN, install it, run it, no problem. If I needed to get it onto the internal network, I just had to burn it to CD and take it over to one of the Support machines that was on the internal network. Or, later on, use ssh and scp to move it to a bastion host and then onto the production-side system I needed it on. Fortunately we were using Unix and X11 and weren't dependent on a full desktop environment, so running all the graphical tools I needed through an SSH X11 tunnel was fairly trivial.
So, what they want is a private IP-based network. No sweat, we've been building those for a couple of decades now. When I did point-of-sale for a truck-stock company, we had our own private network for connecting to our stores, credit-card processors and the like. You need routers, appropriate leased-line or other dedicated bandwidth, and some time spent on a white-board laying out the topology. The only real hard part is making sure you don't connect any machines to this network that also have connections to the public Internet. Yes, this means the machines on that network aren't going to be able to access the public Internet. You wanted a private, isolated network, you get a private, isolated network. If you want to live dangerously you can create appropriate DMZs and firewalls and proxies to give internal machines external access, but remember that that means worms, viruses and other malware can ride in on stuff coming back in through that external access and infect machines inside the perimeter. At that point your "protected" network isn't protected at all (in fact it's probably more vulnerable, since you likely skimped on internal protection since it's supposed to be a protected network).
I sometimes find Google Instant useful, same as with history-based completion in the URL bar of Firefox. But when it's not useful it's easy to ignore and doesn't seem to bog things down any (at least I'm not noticing it). As for the ads, when I'm looking to buy what I'm searching for they're often relevant to my search (and thus useful), and when I'm not they're easy to ignore. A lot of other search/advertising engines seem to get the first bit but ignore the second part about getting out of the way. No, scratch that, they get the second part but consider doing it to be an explicit thing to be avoided. Which I think is why Google's so popular and so profitable.