If Twitter is being paid to promote a brand through my appearing to follow it, they're having me act as a spokesman aren't they? If so, where's my fee? I think 10% of the gross that Twitter receives is fair.

1. Ingress/egress filtering near the edges. Backbone providers obviously can't feasibly do this, but edge networks like consumer ISPs have a solid knowledge of what netblocks are downstream of each subscriber port and what netblocks should be originating traffic on their networks. Traffic coming up from each subscriber should be blocked if it doesn't have a source address in a block owned by that subscriber, outgoing traffic through the upstream ports should be blocked if it doesn't have a source address of a netblock that belongs on or downstream of the network, and incoming traffic through the upstream ports should be blocked if it doesn't have a destination address that belongs on or downstream of the network.
2. Disconnection of infected systems. If a subscriber system is confirmed to be originating malicious traffic due to a malware infection, shut off the subscriber's connection until they contact the ISP and clean up the infection. Time and time again it's demonstrated that the people getting repeatedly infected won't do anything as long as their connection appears to still work, and that the only thing that gets their attention is connectivity going out. Get their attention and make it clear to them that letting this continue is just not acceptable.
3. Extend this as far into the Internet as is feasible. Even if you have so much interchange traffic that you can't filter all ports, you may also have some ports where there's a manageable number of known netblocks handled through them and you can do filtering on those ports to reinforce the filtering that should be happening on the connected network.

Yes, it can lead to an arms race. The problem is that if you hold off and your enemy doesn't, you're a sitting duck. Avoiding the arms race is only possible if everybody involved holds off, and you don't/can't trust any of them to hold off so you have to proceed as if you're already involved in an arms race whether you want to be or not. Because the only thing worse than being in a Mexican standoff is being the one guy in a Mexican standoff without any guns.

With the consumerization of IT continuing to drive employee expectations of corporate IT, how will this potentially disrupt the way companies deliver IT?

It won't. Corporate IT and how it operates is driven by the people who sign the checks. That, BTW, is not the employees. The people who do have considerations other than employee expectations in mind when they decide on policies, and some of those things like compliance with laws and regulations aren't optional. Corporate IT will, as always, continue to be bound by what upper management decides on and the rest of the company will have to live with upper management's decisions. And no, IT isn't any happier about this than the rest of the company, because frankly their job would be a lot easier if upper management would stop telling them how to do things and just let them do whatever they needed to do to deliver what upper management needed. I don't see that happening any time soon.

Upstream verification won't help. The client has to verify that the image it received is the same one the server verified, otherwise someone can hack a router to silently redirect the client to a malicious server and serve up whatever image they want alongside a copy of the signed manifest for the official image and you're fsckd. What they need is:

1. The manifest has to be signed.
2. The manifest has to contain a secure checksum (cryptographic hash) of the official image the server has.
3. The client has to verify the signature of the manifest to confirm that the manifest hasn't been altered and comes from the official source.
4. The client has to verify that the checksum of the image it received matches the checksum for the image in the manifest.

5. Step 4 is apparently what's missing from the client.

For one thing, if North Korea was capable of this sort of hack they've got more tempting targets to use that capability on. And it's just a bit too convenient, coming on the heels of a disappointing performance by Sony, for SPE to suddenly get an excuse to get out from under another apparent flop. My bet is the hack's just another in a long string of breaches by the usual gangs of malcontents, aided and abetted by corporate obliviousness to security, and various parties are just taking advantage of superficial connections for their own reasons.

There should be more isolation, yep. When I handled POS the terminals had no local storage at all, they were network booted from images on the site server and the LAN they were on had no outside access at all. The site servers were on our own wide-area network that connected them to corporate, and there were only two network segments (Development and Support) that could connect to the site servers (sites couldn't even connect to each other). Access to the Dev and Support networks from the rest of the company was highly restricted, and any unexpected access from Dev or Support netted you a phone call and/or an in-person visit from the support manager to find out what had blown up.

I can think of ways to get malware out to the POS system through all that, but all of them involve physically being in the basement of the corporate headquarters where the Support and Development department offices were located and any unknown face would've had to avoid 2 managers and 3 secretaries before being grabbed by the scruff of the neck by Cory and hustled back upstairs (because if Cory didn't recognize you you were not supposed to be down there).

I'd note that the 3 points at the end of the article aren't unique to open-source software but apply to all third-party software you use in building your software. And those points are harder to address for proprietary third-party software than for open-source, because any software component may contain other components you aren't directly aware of and without the source code it's a lot harder to scan proprietary libraries to detect those included components (and it may be impossible if the included components are themselves proprietary because the people who wrote the scanner may not even know those components exist let alone have access to their code to create the necessary detection routines). Or they may be easier to address, if your license for the proprietary libraries doesn't include a right to redistribute then the answers become very simple if rather limiting and any less-restrictive licenses for other components become irrelevant.

Apple argues, and Schultz agrees, that its intentions were to improve iTunes, not curb competition.

I'd note that the two alternatives aren't incompatible. It's entirely possible to intend to improve iTunes while also determining that the best way to improve it is to block all competitors from accessing it (doing that would, among other things, eliminate bugs due to incorrect accesses and malformed music files and remove an inconsistent user experience due to badly-written software from other vendors). After all, when AT&T was banning all other vendors from connecting equipment to it's phone network it was only intending to protect the network from damage due to incorrectly-designed equipment (or at least so it's testimony went). In neither case do intentions alter the end result.

Times of stress/trouble usually mean a loss of population. The arithmetic's simple: one woman can bear one child every 9 months to a year, while one man can sire multiple children in that same time. That means that adding female offspring at the expense of male will make it easier to recover the population loss. And of course sacrificing the least resilient male offspring favors the ones that'll survive the longest and sire the most children. The fun question is how the mechanisms that've evolved to make this happen actually work. Figuring that out's going to keep researchers occupied for the next century or two.

The article's behind the curve. The class has a plaintiff for the suit and it will continue.

Your metaphor is off. It isn't about the court compelling you to produce the document, it's about compelling the foreign confederate to produce the document.

But in this case it's not a confederate that has the data. The servers in Ireland belong to Microsoft, not another company. Let's reduce it to a simpler case: A sues B in state court in state 1 (A lives in state 1, B is based there and the offense involved occurred there so state 1 has jurisdiction over the case). B stores older documents in a warehouse it owns in state 2. A shows that B has documents relevant to the case and that they're in that warehouse. Can the state court judge order B to produce those documents even though the documents aren't in the judge's physical jurisdiction, or must the judge punt the case to Federal court or a court in state 2 and have them handle that? My sense is that the judge can order B to produce the documents and B would be obliged to comply. If B refuses to comply then A would probably have to go through a court in state 2 if they wanted deputies to go in and seize the documents, but wouldn't if they merely wanted B sanctioned for failure to comply with the court's order.

I suspect the situation here would turn on whether or not Microsoft's operations in Ireland are a legally independent entity that could legally refuse to do what Microsoft tells it to do. I suspect Microsoft's Irish operations walk a very fine line, trying to be independent enough not to be subject to US tax laws but without being independent enough to actually be able to act independently of Microsoft.

Agreed. If you're impaired, it shouldn't matter why you're impaired. Combine a field sobriety test with dash/body cams so there's an objective record of the actual test (so the defense can't claim the officer is exaggerating the results) and just use the blood tests as supporting evidence, eg. "Defendant failed the field sobriety test miserably. When his blood was tested during booking, the results showed the following levels of potentially-impairing substances which are consistent with and support the field test's result of "massively impaired".".

That'd be true normally. However, copyright law doesn't have any provision for holding you liable for someone else's infringement unless you actually contributed directly to the infringement. Cox may have grounds for terminating your service for breach of terms of service, but a third party like a copyright holder can't avail themselves of that (they're not a party to the contract) and if they try pressuring Cox then you might well have a case against them for tortious interference with contract if Cox agrees with them and terminates your service.

That doesn't mean the copyright holder isn't without recourse. Discovery plays by a completely different set of rules, and they'd be entirely within their rights if they subpoenaed Cox for the subscriber's identity for the purposes of calling the subscriber in for a deposition to answer questions about who was using their connection when for the purposes of identifying the actual infringer. It's just that the copyright holders don't want to go through this on an individual basis because it'd cost more than they could hope to recover. However, as more than one court has pointed out, that's not the court's problem. Every plaintiff and every defendant has to make that same decision as to whether it's worthwhile pursuing or fighting a case, copyright holders aren't an exception to that.

Not to be picky, but I think you're confusing "can" and "are allowed to". "can" has to do with being physically and technically able to. "are allowed to" involves things like "Is it legal?" and "Have the sysadmins been ordered to?". The admins may not for example be legally allowed to just record and scan your IM sessions for no reason, but if diagnosing a weird network problem requires capturing traffic on the wire your packets will get caught and get included in the logs regardless of what the law says (since if I knew exactly what I was looking for well enough to just capture the relevant packets I'd already have diagnosed the problem and wouldn't need to do a traffic capture) and key words in your session may catch my eye. And beyond that kind of legitimate situation, we've all seen cases where companies do things that aren't legal if they think they won't get caught or the benefits outweigh the cost of any fines they may have to pay.

OTOH, as I've reassured people, "Don't worry about it. Yeah, I can see everything if I want to. But your porn is boring unto tears and frankly my to-do list is too long already and I do not want to have to add anything more to it.".