I would say this is a great tool, when used in surround configuration, to enhance horror game experience.

You know, the "for optimal experience, play in a dark room with headphones" ones.

So is importing, in some countries.

Wrong. Since I follow the situation closely, let me explain.

The HTML5 Web Notifications API is in Chrome since forever under webKitNotifications.

The first draft spec of Notifications API included both icon-and-text simplistic notifications, and HTML notifications which were in fact just tiny windows that popped up.
Chrome implemented both, extension authors happily started using it.

Next, W3C drops HTML notifications from the draft. Chrome then drops it from the web context, but keeps it for extensions: they didn't want to suddenly break legacy apps, I guess. They didn't even mark it as deprecated until not long ago.

Fast forward a few releases. Chrome wants its own notifications center, and drafts a new Rich Notifications API. Long experimental, this finally hit Stable.

However.. Despite being touted as a replacement for HTML notifications, those don't come even close to customization possibilities of an arbitrary HTML page, with its own code running. And Google decided to make a hard switch: a browser version has either Rich or HTML notifications enabled. So, if the feature hit you, your old notifications keel over and die immediately.

But that's not the worst problem here. The worst problem is sudden fragmentation. Windows and Chrome OS have the new Rich notifications and do not have HTML ones anymore. OS X and Linux do not have Rich notifications but support HTML ones. See the problem? And despite saying that it will come to other platforms "soon" this isn't in Beta yet for sure, and possibly not even in the Dev branch, but don't quote me on that. So to even maintain both systems I now need two OSes.

In Russian we have a good umbrella term for what was described: silovik, "people of force".

Note that without the hardware part, the whole system cannot survive a hard drive wipe. So it's semi-useless for existing hardware not equipped with it, and my point is that the original question was about exactly this situation. Not to lessen the merits of the solution, of course - it's just not applicable.

Besides, Computrace persistency module will only re-enable itself under supported operating systems. Guess if Linux is included!
So the surviving module will be running on firmware/BIOS level only, and I personally consider that "hardware".

You definitely can't call accounting software "ordinary", at least not in terms of risks.
It operates in an area with high legal risks for its users in case of an error, and it's not a revelation for the developers of said class of software.

Note it's a hardware solution, while the question as about a software solution for existing hardware.

If you're a fan of Google Reader UI, check out The Old Reader.

It is a "fork" of Google Reader before it integrated with Google+.

Upsides:
* very familiar UI and very similar functionality
* an API is coming very shortly
Downsides:
* the feeds are not updated as timely as in Google Reader
* there are no long-term feed archives, at least not yet
* does not embed the Slashdot iframe with top comments

I enjoy the clean UI and none of the social/magazine nonsense of popular alternatives.
I'm also contributing to its Chrome Notifier.

Replying to undo accidental downmod, sorry.

Something I do not understand in this whole rhetoric - what's stopping Sony from doing the very same thing? How's that's an argument?
Any future mandatory software/firmware upgrade can alter the way it operates. See OtherOS problem.
So, what makes MS more likely to play that card?

I will also vote for The Old Reader.

I'm also contributing to the development of its notifier extension for Chrome, shaping it to be a more useful tool, in the spirit of "I have to live with that, may as well improve it".

Well, my point wasn't that the original card is impossible to clone given physical access to the card. My point is that using only radio communication with the chip, it is not possible to clone it. I imagine that NFC stuff and the crypto module are isolated, and the hardware crypto module quite literally has only one command exposed, to generate a response to a challenge. So neither passive (when you hear the challenge and the response) nor active (when you can submit challenges yourself) attacks can give you the required key, even if you can find a bug in NFC that you can exploit.

As for complex protocols. I'm a logician working with proof theory. There have been precedents of full formal verifications of such protocols that, given a set of assumptions about the hardware, can exclude any possibility of a flaw in the protocol itself. Example 1, example 2. It's usually very hard, but can be done, and gives the same rigor as normal mathematical proofs.

Smart card security isn't new. So it's a reasonably mature concept, but it has usability problems in this application.

Contactless payments differ a lot from magnetic stripe swiping, invisible barcodes etc.

They are not static information but an active challenge-response authentication system. You cannot clone the chip; it has an internal cryptographic secret it does not allow you to access, only challenge responses. You can trick it into authorizing a purchase you don't want if you're in physical proximity, which is happening here, but you cannot save that authorization for later use, since the bank is issuing the challenge here, just like with a chip-and-pin purchase. The whole point is to ensure that this is really the actual card.

So the main problem is the lack of user interaction to go ahead with the purchase. A touch button on the card itself would help, but would destroy part of the convenience.

Then it falls back to the patent office to pick out which arguments are convincing, which is a pretty much similar task.

[citation needed], I can't find this line anywhere.