[Terr_]

I think the idea is that it's reasonably-secure against skimmers taking your data and then re-using that data in another session or location when the card is absent.

But it won't save you from a compromised point-of-sale system that lies to you about how much you're paying or which commits fraudulent transactions while the card is still in the reader.

[lazaroclapp]

Which is why the amount should be displayed on a display embedded in the card itself. The control for authorizing the transaction should also be part of the card.

Now, if only we carried around a device that included a display and some sort of input mechanism, plus a near-distance communication chip...

(Ok, if the device is a general computing device, a special secure operation mode might be needed for this sort of use case, one which can't be subverted by normally installed software, but still...)

[pki]

> special secure operation mode might be needed for this sort of use case, one which can't be subverted by normally installed software

Now people will complain that "the app doesn't run on their rooted, bootloader unlocked, jailbroken phones"

[lazaroclapp]

No reason why it shouldn't. This is not DRM, is your own credit, secured on your behalf. It should just be resistant to software based tampering by default. Specially, as I said, "normally installed software". If you can make sure that rooting your device requires a explicit knowledgeable user interaction (say: rebooting, erasing all data, then re-keying your device to your bank account somehow - in person visit?), then I see no reason why you should be prevented from changing the secure operation mode code itself or building your own compatible device.

I mean, you can mod the brakes on your car if you really want to, at your own risk. What is a bit strange is when your media player can affect your brakes without you even noticing. Same principle here, less lives on the line.