4 ms·

I had this argument with my bank, who insisted that all payments must be confirmed with their app instead of their card reader code. They presented it as being

I had this argument with my bank, who insisted that all payments must be confirmed with their app instead of their card reader code. They presented it as being more secure, which is not true as most people's phones a littered with app that are either easily exploitable or malicious by design. Chances that the average user's phone is compromised is very high. All people around me that are not involved in tech have so many crap apps on their phone and think I'm weird for not even having Google Play or any other Google service on my phone. It's kinda like that xkcd on voting software, if you work in the business, you know how bad things really are. https://xkcd.com/2030/ https://xkcd.com/2030/

pflanze 5y ago
I think this Xkcd strip is missing an important point, which is that voting is exposed to a very broad attack vector: probably quite a large percentage of the population would try to corrupt the results if that could go undetected. The risk that electronic voting is exposed to is corruption, not really accidental failure. The other examples in the strip are talking about accidental failure. So while it's true that software quality management is usually (very) bad compared to in engineering disciplines, this is largely because of missing incentives and arguably missing regulation (for worse in this view), which could be changed, but unlike in the engineering cases, it would be a different level of difficulty for regulation to solve the issue, since the devices in question can be exposed to bad actors on pretty much every level. Or with a corrupt government / dictatorship even the regulation agencies themselves could be compromised.
mcintyre1994 5y ago
Anyone who wants to put something important in a phone app should be required to give somebody non-technical an Android phone with Facebook installed and take a look at what apps are on the phone after an hour. I'm convinced a big chunk of Facebook's mobile money machine is just advertising blatantly malicious apps and pretending not to know.
lmns 5y ago
>Chances that the average user's phone is compromised is very high. How do you know? Android and iOS apps are much better sandboxed than desktop applications (which usually aren't really sandboxed at all). I would guess the chance of phones getting compromised is much lower than for the average desktop.
- FriedrichN 5y ago
  Sandboxes are hardly watertight, especially considering the hardware vulnerabilities that seem to be pouring in in the last years. And the phone have taken over the space for useless applications from the desktop. Most desktops today only have a browser and some office application installed. But that is besides the point, because a hardware token is almost impervious to attack. One would have to engineer a very specific bit of software or hardware and have physical access to this token. Requiring a phone app to confirm a payment made on your desktop just increases the attack vector.
  - lmns 5y ago
    >Most desktops today only have a browser and some office application installed. The desktops I see on a daily basis don't have only a browser and office application installed. I'm not sure which phone or OS you are using, but almost all smartphones have some kind of TPM or TEE nowadays. FWIW, the banking app on my Android phone makes use of that through the KeyChain API.

pflanze 5y ago

I think this Xkcd strip is missing an important point, which is that voting is exposed to a very broad attack vector: probably quite a large percentage of the population would try to corrupt the results if that could go undetected. The risk that electronic voting is exposed to is corruption, not really accidental failure. The other examples in the strip are talking about accidental failure. So while it's true that software quality management is usually (very) bad compared to in engineering disciplines, this is largely because of missing incentives and arguably missing regulation (for worse in this view), which could be changed, but unlike in the engineering cases, it would be a different level of difficulty for regulation to solve the issue, since the devices in question can be exposed to bad actors on pretty much every level. Or with a corrupt government / dictatorship even the regulation agencies themselves could be compromised.

mcintyre1994 5y ago

Anyone who wants to put something important in a phone app should be required to give somebody non-technical an Android phone with Facebook installed and take a look at what apps are on the phone after an hour. I'm convinced a big chunk of Facebook's mobile money machine is just advertising blatantly malicious apps and pretending not to know.

lmns 5y ago

>Chances that the average user's phone is compromised is very high. How do you know? Android and iOS apps are much better sandboxed than desktop applications (which usually aren't really sandboxed at all). I would guess the chance of phones getting compromised is much lower than for the average desktop.

FriedrichN 5y ago
Sandboxes are hardly watertight, especially considering the hardware vulnerabilities that seem to be pouring in in the last years. And the phone have taken over the space for useless applications from the desktop. Most desktops today only have a browser and some office application installed. But that is besides the point, because a hardware token is almost impervious to attack. One would have to engineer a very specific bit of software or hardware and have physical access to this token. Requiring a phone app to confirm a payment made on your desktop just increases the attack vector.
- lmns 5y ago
  >Most desktops today only have a browser and some office application installed. The desktops I see on a daily basis don't have only a browser and office application installed. I'm not sure which phone or OS you are using, but almost all smartphones have some kind of TPM or TEE nowadays. FWIW, the banking app on my Android phone makes use of that through the KeyChain API.