The phisher’s app or login would be from a completely new device though.
Passkeys are also an active area to defeat phishing as long as the device is not compromised. To the extent there is attestation, passkeys also create very critical posts about locking down devices.
Given what I see in scams, I think too much is put on the user as it is. The anti-phishing training and such try to blame somebody downward in the hierarchy instead of fixing the systems. For example, spear-phishing scams of home down payments or business accounts work through banks in the US not tying account numbers to payee identity. The real issue is that the US payment system is utterly backward without confirmation of payee (I.e. giving the human readable actual name of recipient account in the banking app). For wire transfers or ACH Credit in the US, commercial customers are basically expected to play detective to make sure new account numbers are legit.
As I understand it, sideloading apps can overcome that payee legal name display in other countries. So the question for both sideloading and passkeys is if we want banks liable for correctly showing the actual payee for such transfers. To the extent they are liable, they will need to trust the app’s environment and the passkey.
There is some world where somebody scammed through sideloading loses their life savings, and every country is politically fine with the customer, not the bank, taking the losses.
But for regular people, that is not really the world they want. If the bank app wrongly shows they’re paying a legitimate payee, such as the bank, themselves or the tax authority, people politically want the bank to reimburse.
Then the question becomes not if the user trusts the phone’s software, but if the bank trusts the software on the user’s phone. Should the bank not be able to trust the environment that can approve transfers, then the bank would be in the right to no longer offer such transfers.
If the actual bank app does that, or is even easy to fool into doing that, then the bank should be responsible. That's the world "regular people" want and it's the world as it should be.
If random malware the user chose to install does that, then that is not the bank's fault. The bank is no more involved than anybody else. And no, I don't think "regular people" want to make that the bank's fault.
Why do banks go through all the know-your-customer (KYC) process if not to identify the beneficial owner of every account? If they receive a transfer via fraud, then they either get it clawed back, have to pay it back, and/or get identified to law enforcement. If the last bank in the chain doesn't want to play by the rules, then other banks shouldn't transfer into them, or that bank itself should be held liable.
This is more or less how people expect things to work today ....
Maybe I’m biased working in insurance software, but I don’t get the feeling much programming happens where the code can be completely stochastically generated, never have its code reviewed, and that will be okay with users/customers/governments/etc.
Even if all sandboxing is done right, programs will be depended on to store data correctly and to show correct outputs.
Insurance is complicated, not frequently discussed online, and all code depends on a ton of domain knowledge and proprietary information.
I'm in a similar domain, the AI is like a very energetic intern. For me to get a good result requires a clear and detailed enough prompt I could probably write expression to turn it into code. Even still, after a little back and forth it loses the plot and starts producing gibberish.
But in simpler domains or ones with lots of examples online (for instance, I had an image recognition problem that looked a lot like a typical machine learning contest) it really can rattle stuff off in seconds that would take weeks/months for a mid level engineer to do and often be higher quality.
The issue in the late-90s was all the investment created a lot of real revenue for telecoms and other companies. Even though there were a lot of shenanigans with revenue, a lot of real money was spent on fiber and tech generally.
But the real money was investment that didn’t see a return for the investor. The investments needed to have higher final consumption (such as through better productivity or through displacing other costs) to pay back the investment.
Given how much of the spending is hard goods and simply not AI-able (rent, most of housing new construction, most of other goods, most health care, much of other services), the replacement theory would require a massive displacement.
It seems like the bigger day to day issue is the possibility of downgrades from STARTTLS or a server that doesn’t support TLS. Encryption in the GPG isn’t necessary or even would be unwanted (for a company to have records of all the emails).
So there are mechanisms to put encrypted things in workplace emails and then have some mechanism for receiver in a different organization to unencrypt. I have seen a mechanism that comes down to magic links, which I found ironic (though yes, intercepting is less of a threat than sending the data unencrypted).
I feel like supporting an option to not send an email unless STARTTLS happens is the way to go. There’s probably a lot of practical problems for, say, online Outlook or Gmail supporting that option when sending an email. But I feel like that’s the easiest solution.
I will say that for Google's Advanced Protection, I was convinced having a recovery phone added was okay.
I just have a hardware key on my key chain and one on a pretty fireproof safe (which I got for other reasons). But I still added a phone recovery just in case.
As I understand it, the recovery process will always wait multiple days while sending many emails to me that it's been initiated.
Having different passwords doesn't prevent phishing where you think you're logging into the service being phished. The hacker would also create a new TOTP on that service once they get in to that service.
Passkeys are also an active area to defeat phishing as long as the device is not compromised. To the extent there is attestation, passkeys also create very critical posts about locking down devices.
Given what I see in scams, I think too much is put on the user as it is. The anti-phishing training and such try to blame somebody downward in the hierarchy instead of fixing the systems. For example, spear-phishing scams of home down payments or business accounts work through banks in the US not tying account numbers to payee identity. The real issue is that the US payment system is utterly backward without confirmation of payee (I.e. giving the human readable actual name of recipient account in the banking app). For wire transfers or ACH Credit in the US, commercial customers are basically expected to play detective to make sure new account numbers are legit.
As I understand it, sideloading apps can overcome that payee legal name display in other countries. So the question for both sideloading and passkeys is if we want banks liable for correctly showing the actual payee for such transfers. To the extent they are liable, they will need to trust the app’s environment and the passkey.
reply