Been there done that. This was the same thing touted by the folks at "iCache" who released a few test units of the "Geode" -- an iPhone jacket and universal card combo that could do this as well as provide support for barcodes using an e-ink window on the back of the case.

Unfortunately, the company -- after a successful Kickstarter and infusion of venture cash, crashed and burned. HARD.

http://www.zdnet.com/icache-geodes-spectacular-crash-and-burn-7000014801/

As it turns out, there were huge limitations on where this type of "cloned" card could be used -- no ATMs, no "pull through" swipers like at gas pumps... It all fell apart quite noisily with accusations of fraud and deceit on the part of the company's founders.

The bottom line is this: Payment card providers require three things: 1) the card should be signed, 2) the card should be present so the merchant can verify the expiration and CVV (or pay a CNP fee), and 3) the card provider's logo must be visible on the card. Failure to comply with any of the three means a merchant may lose his ability to accept cards to the provider. The Geode could do ONE of those things; the same goes for this card, as technically interesting as it may be.

And of course this goes out the window as NFC or chip-and-pin cards eventually come into fashion in the US (as chip-and-pin already is in Europe).

This is a waveguide for a SNR-75 "Fan Song" fire-control radar for the Russian SA-2 (NATO) missile system. You can learn about it here (an SNR-75 set abandoned in Czechoslovakia): http://forum.valka.cz/viewtopic.php/t/74858

And you can see the waveguide cone pictured in the AP stories and twitter here:
http://forum.valka.cz/attachments/1945/RSN-75M3_Fan_Song_E_1.jpg

And unless I miss my guess, this is the first _direct_ seizure we've seen of ACTUAL missile hardware on a North Korean ship.

You're splitting hairs here.

P3P 1.0 doesn't allow for multi-site delclarations, only "cross-site" declarations. There can be one -- and only one -- P3P policy; by the standard it doesn't allow but ONE policy and states that others, if present, should be ignored. This just isn't how the Web works these days. Cloud services have pretty much become a defacto standard, but P3P forces site administrators to take a P3P policy from the integrated service and mash it into their own policy (and hope the service policy never changes). This just isn't practical.

A site admin CHOOSES to use +1 buttons and FB like buttons. Inclusion of these objects would optimally prompt an admin to adjust their _own_ P3P policy, but it's just a plain 'ol administrative nightmare to manually take the respective organizations' policies and create a master policy out of all of them. It's fully manual; it has no concept of "merging" policies to present users with enough information to make informed choices on the multitude of SaaS services sites now use. That's the issue.

The darn thing is broken. Period. Hard to claim "cop-out" when dealing with a protocol that's stuck in 2001.

This is correct. However, as stated further down in the same section, the effect of such policies is to be positive and declarative (meaning the policy should state what the site DOES do, not what it DOES NOT do), and be informative to the user. The standard allows for user agents to then use the P3P policy to make it the basis for "authorization" but then goes on to state that implementers of user-agents can make their own decisions as to what the declarations mean in the context of the connection.

This has led to situations where browsers that implement P3P and tie it to certain "security features" end up with a browser implementation that works dramatically different than other browsers for the very same privacy declaraion. In most cases, browsers do not even IMPLEMENT a user-readable informational dialog for P3P -- it is by standard the browser implementers' decision.

If you're keeping score at home, that's bad.

Can't say I really can fault Google for this. Explaining why would require an understanding of how P3P 1.0 objects are configured and how limited those types really are.

P3P 1.1 work has stalled (albeit in provisionally final state) and is likely to not restart; in its absence is P3P 1.0 which exists firmly in the world-as-it-was of 2000/2001. It covers cookies and certain types of form transmission, but doesn't cover privacy aspects of other types of persistent data, new transmission protocols (like SPDY), advanced caching techniques, or HTML5 storage. Technology has advanced past the point that P3P 1.0 is useful -- and quite simply, it's doubtful it ever really was. If you visit the link Google supplies it explains some of their reasoning, and it's pretty dang valid for a post-2007 view of the Web.

Those chucking bombs over this would be better served to focus their efforts on either modernizing or replacing P3P 1.0 -- or, better yet, trying something radically different like PRIME or Policy-Aware-Web tried to do.

Don't get me wrong; I'm all in favor of this -- I want earlier versions of IE to die a thousand silent deaths, but...

This will hurt some large enterprises who have specifically designed certain website features to work only in IE. Older versions of IE tended to have some quirky rendering behaviors and a lot of sites rely on those quirks. Taking the browser directly to the latest IE will render things in IE "Standards" mode which will break some of these sites.

They better read up on how to explicitly set IE rendering modes:

http://msdn.microsoft.com/en-us/library/cc288325(v=vs.85).aspx

Three ways to do this: 1) do it in the page body with a META tag, 2) do it in the HTTP headers with the X-UA-Compatible header, or 3) push a GPO update to your internal IE clients that forces the browser to render the sites you specify in "IE Compatibility Mode".

HP is one of the vendors I tried to buy from who sat on my $150 for 3+ weeks, renewing the hold every Friday like clockwork until finally canceling it with no attempt to reconcile with me as a customer.

Just speaking as a person who tried and failed multiple times to get orders in for one of the firesale units with multiple vendors -- and went to multiple retail stores in search of one... only to be shut out by the douchebags who bought dozens at a time. And whose attempts to get orders in with a certain few vendors ended up tying up charges against my credit cards for weeks as, slowly -- one by one -- each vendor admitted "yeah, we just don't have enough. sorry for sitting on your cash."

Have fun, all you wild-eyed bargain hunters. I'll just sit this one out.

As a famous jerkwad once said: "Fool me once, shame on — shame on you. Fool me — you can't get fooled again."

First rule about DoD security and stability? Don't talk about DoD security and stability. :>

This should come in handy for doctors trained this way when a blue, eight-foot tall hermaphroditic troll shows up at a hospital emergency room complaining of chest pains.