Perhaps such a measure would at least get cabbies to shut up.

... but I'm not giving up "FBI Surveillance Van".

How about Apple invests in a server business that corporations can actually use? Buy Windows client and AD licenses for all Macs ... no, all Apple devices. Build a better AD than Microsoft, own the corporate environment, give big customers real choices. Interoperate better with Linux. Extend SAMBA and support FOSS projects... (who am I kidding, right?)

Think how many more people we'll have to lock up to sustain that trend.

In fairness, the press has always sought to align us to their goals. The assertion of objectivity is relatively recent, and Machiavellian in its subtlety.

That's not how (these types of) smart cards work. The card is smart, and performs private key operations on board the card. All the host gets are session keys, hashes, etc. By design, the private key memory of the card can only be written, at a specially configured programming station. That doesn't mean there aren't user-readable or re-writable areas on the card, but the credential private keys aren't among them. The hardware literally doesn't support reading back private keys, only overwriting them. Any key escrow is accomplished by the programming station, when the card is first written.

The trojan steals "use" of the inserted card, and probably the PIN. The private key remains safely in the card, and the trojan can't use it once the card is removed. The defenses are (1) don't use smart card on untrusted computer, or (2) if no other choice, use smart card only long enough to accomplish a specific task. The smart card PIN can be changed by the user, so it may not even be necessary to revoke the credential after an exposure. However, the trojan also gains temporary use of the card holder's digital signature -- meaning that authentic digitally-signed spear phishing emails could be sent under the card-holder's email account. If the card is inserted but the PIN is never entered, then a trojan might maliciously enter several random PINs and block the card as a DoS attack...

If you are working for DoD or any armed service subsidiary, I'm pretty sure the policy is for you to have the drives destroyed before they leave your control, period. You can re-use them internally indefinitely, but at the end, they need to get physically destroyed. The various overwrite processes are usually considered "good enough" to reuse them at lower security levels until then, though.

... are the agencies that overpaid Oracle, probably by (a lot) more than the amount of the settlement. The funds will be returned to the general revenue, and the government programs Oracle ripped off will never be reimbursed. That means Johnny doesn't have as many bullets to shoot at Al Qaeda, because the logistics chain is out the extra money they paid Oracle. It also means that contractor Jane got laid off, because the money to pay her went to Oracle instead.

"Applied security by obscurity" is not a new concept: it is usually referred to as "operational security (OPSEC)," at least in military circles. The author's use of complex notation doesn't change anything, although he seems to imply that it might be appropriate to deliberately analyze and model OPSEC at very high levels of design. The "know your enemy" concept is popular among pundits, but also problematic: while directed profit-motivated attacks and state-sponsored hacking have become popular topics in the press, there are still plenty of work-in-the-dark-do-what-we-can basement hackers out there, who will take delight in breaching your OPSEC just to prove it's possible (the ability to sell their results only adds motivation).

Seems more likely to me that PayPal has succeeded in identifying 1000 overseas botnet clients by IP address.

...because Microsoft already has all of our software money.

If you root the PLC, then you can probably do something like cycle the locks until the solenoids burn out. Given the inherent conflict between safety and security, I wouldn't care to bet whether they'd fail in lockdown or free-for-all mode, or 50/50 either way. Any countermeasure implemented in PLC code instead of hardware (or a semi-autonomous downstream PLC) would be vulnerable to alteration. A well-designed PLC implementation will have only *monitoring* outputs accessible to Internet-connected PCs, while the actual control inputs remain locked up tight in multiple ways.

"3. Management Security Policy [...] c. System and Services Acquisition. In accordance with DOJ IT Security Standard – System and Services Acquisition (SA) Control Family, Components shall: [...] (6) Ensure third-party providers are contractually required to comply with this policy to employ adequate security measures to protect information, applications and/or services outsourced from the Department." [http://www.justice.gov/jmd/publications/doj2640-2f.pdf] I've got a banana peel that says the ManTech contract didn't contain such clauses, nor any means of verification if it did.

This is very convenient, if both you and your condition happen to be covered by Medicare, and you can find health care providers willing to settle for Medicare payments.