Friction is Good: Let's add it to our digital experiences(theregister.com)
theregister.com
Friction is Good: Let's add it to our digital experiences
https://www.theregister.com/2024/02/14/friction_is_good/
15 comments
>For sixty years, computing has emphasized speed
I wish day to day software emphasized speed
I wish day to day software emphasized speed
It's frankly amazing how slow a lot of everyday stuff is given how damn fast modern hardware is.
It sure seems like modern hardware's speed is wasted on making things slightly easier for devs, rather than speed or performance increases for users huh. If 29 layers of abstraction saves a little dev time over 5 layers, that's fine, but it feels like it creates this unnecessary requirement to use <5y old hardware to run things smoothly
From electron instances everywhere, to the niche suckless philosophy, so much of software seems to be programmer-first. Truly missing the forest for the trees.
[deleted]
This article is light in details, but I'm going to guess that the money stolen was crypto of some sort. It is unlikely you could pull this off with regular banks as banks log everything. Sure if I gave you my checking account number you could take all the money I have in there - but the banks all know who got that money and so when I go to the police there is a trail to trace and much higher odds I get it back. This is one reason why crime goes through Swiss banks (traditionally) or Cayman islands (more likely) - the banks there are much less likely to cooperate with any police I go to and so it is much harder to reverse charges.
I still won't post my checking account number publicly though. Bank logs are not fool proof, but they are a lot better than crypto.
I still won't post my checking account number publicly though. Bank logs are not fool proof, but they are a lot better than crypto.
It says right in the first paragraph it was crypto.
Still, if you think the problem doesn't apply to "real money": there was this story in Brazil some years ago of thieves going around to Carnival parties with NFC-enabled payment machines. They got away with hundreds of thousands of BRL just by walking in the middle of the crowd with the machine set to collect a small payment.
IOW, people were getting robbed because we've become too lazy to type a PIN code.
Still, if you think the problem doesn't apply to "real money": there was this story in Brazil some years ago of thieves going around to Carnival parties with NFC-enabled payment machines. They got away with hundreds of thousands of BRL just by walking in the middle of the crowd with the machine set to collect a small payment.
IOW, people were getting robbed because we've become too lazy to type a PIN code.
US passports have a cover that makes it hard to read the chip unless opened. I don’t know how well it works, but it seems like something similar would be useful for payment cards, even if there’s no PIN.
I didn't say it doesn't apply to real money. I said there is a lot more logging so you have a better chance of finding where the money went, catching them, and getting your money back. It isn't perfect, and it does depend on Brazil's courts. It also depends on someone going through a lot of effort, it isn't automatic.
Still, we are now being forced to spend an uncountable amount of time and resources to create a system that can mitigate an issue brought by some technology which was supposed to save us what, 10 seconds of each in-person transaction? It makes no sense.
There is no way to set Apple Pay to activate without user input, is this not true in Android?
Tap-to-pay NFC credit cards
Chip and pin or even chip and signature is just too much effort to pay for something
Chip and pin or even chip and signature is just too much effort to pay for something
To do this, are they using some kind of modified payment terminal with extended range somehow? My understanding is that the NFC coils have to be very close, like single-digit cm to get any kind of power or data through.
At carnival in Bazil, you bump into people; Like, when they talk packed streets, they're talking body to body contact filling the street for blocks and blocks. All you'd have to do is put a terminal around your waist and you'd get close enough to activate NFC for hundreds of people just pushing through the crowd.
https://en.wikipedia.org/wiki/Brazilian_Carnival#/media/File...
https://en.wikipedia.org/wiki/Brazilian_Carnival#/media/File...
If I remember correctly, yes, they had a modified terminal that picked up cards more than a meter away. But the other comment is overestimating the damage, there is no way they took 'hundreds of thousands', more like thousands in total. Especially since contactless payments usually have a very low transaction limit (something around R$100 in Brazil).
(Reply depth reached) I guess if you're filtering through a big crowd then indeed you could get really close to people and their wallets. I thought GP was saying you could immediately skim every person in a crowd at once.
Have you been to a Carnival party in Brazil? Most of the time, you won't have "single-digit cm" between you and the next closest to you.
Chip and pin can be unreliable because of bad contacts
TurboTax has this kind of “performative slowness” to convince you it’s doing more than it actually is. It has pointless loading bars and spinning wheel pages as you navigate through every section. I definitely wouldn’t be an advocate of replicating it.
The article is asking for functional slowness, not performative.
And it's a quite popular opinion, because almost every channel has some form of it, and he had to go way out of his way into cryptocoins to enable the problem to happen at all.
And it's a quite popular opinion, because almost every channel has some form of it, and he had to go way out of his way into cryptocoins to enable the problem to happen at all.
One could argue though if you're purposely designing your systems in such a way where they operate slower than they could otherwise, that in itself is just performative slowness.
Most of the processes that I think this author wants to see adopted don't even need to be slow, necessarily. More than anything it's just shocking how much modern software is so utterly bare bones in terms of features, especially around security. While I was attending a therapist not long ago, she had me use an app service I won't name to manage my appointments and payment information, and every login was done with a magic link. This was both annoying, because the app wouldn't stay logged in for a certain amount of time at all and I had to have it send me another password link every time I used it, and also ineffective, because if my email was compromised, nothing was stopping that actor from getting full and complete access to this app.
I don't think it was necessarily a huge risk, but there was literally no options for this. No MFA, not even a password or a PIN to set for stuff like billing information. I could see this being an absolute nightmare to unwind if you happened to have your email breached.
Most of the processes that I think this author wants to see adopted don't even need to be slow, necessarily. More than anything it's just shocking how much modern software is so utterly bare bones in terms of features, especially around security. While I was attending a therapist not long ago, she had me use an app service I won't name to manage my appointments and payment information, and every login was done with a magic link. This was both annoying, because the app wouldn't stay logged in for a certain amount of time at all and I had to have it send me another password link every time I used it, and also ineffective, because if my email was compromised, nothing was stopping that actor from getting full and complete access to this app.
I don't think it was necessarily a huge risk, but there was literally no options for this. No MFA, not even a password or a PIN to set for stuff like billing information. I could see this being an absolute nightmare to unwind if you happened to have your email breached.
I wonder if some of that was added to try and nudge people to pay attention. With no cost to jumping around and going back, people will likely be more careless. If a user knows going back and redoing something is slow and annoying, they may pay more attention and double check their work before clicking Next.
> Thinking fast has left us vulnerable.
It also affords really big mistakes. There's a famous photo, from the original version of The Design of Everyday Things, by Don Norman, that shows reactor control rod controls, topped by beer tap handles, to ensure that the operators can differentiate, because the original design had the same knob, which could make it easy to mix them up.
It also affords really big mistakes. There's a famous photo, from the original version of The Design of Everyday Things, by Don Norman, that shows reactor control rod controls, topped by beer tap handles, to ensure that the operators can differentiate, because the original design had the same knob, which could make it easy to mix them up.
It’s not terribly difficult in case of financial transactions. Just separate into queueing and executing, with an auto-timer, notifications (email, push etc) and an option to cancel directly from the notification channel (without requiring 2FA etc to prevent hijacking issues).
This could be applied to other things, like updating an auth factor (change email for instance). Just notify the old email and queue the operation.
Doesn’t solve all the issues but gives humans a chance to counter bots and hackers based on speed alone.
The main engineering challenge is to estimate impact of an operation, since it depends on other actions. For instance, exfiltrating $1M in $5 increments should not be possible.
This could be applied to other things, like updating an auth factor (change email for instance). Just notify the old email and queue the operation.
Doesn’t solve all the issues but gives humans a chance to counter bots and hackers based on speed alone.
The main engineering challenge is to estimate impact of an operation, since it depends on other actions. For instance, exfiltrating $1M in $5 increments should not be possible.
> in case of financial transactions
The friction is already there.
Every single goddamn time I want to transfer more than a few thousand dollars between any of my accounts, it turns into a complete shitshow of bouncing transactions, hunting down reasons, navigating bureaucracy that doesn't want to be navigated, sometimes to the point of looping in authorities (!), and generally burning many hours of my life to get the financial institutions to do their most basic job.
It's not great. If the purpose is security, we can do better, but I'm not convinced. If the purpose is because financial institutions know that they can prevent customer outflow by shitting up the outgoing transfer mechanism, we should make them do better. If this drop in friction makes security worse, then we should go back and make security better again using a type of friction that isn't such a fucking migrane to deal with.
The friction is already there.
Every single goddamn time I want to transfer more than a few thousand dollars between any of my accounts, it turns into a complete shitshow of bouncing transactions, hunting down reasons, navigating bureaucracy that doesn't want to be navigated, sometimes to the point of looping in authorities (!), and generally burning many hours of my life to get the financial institutions to do their most basic job.
It's not great. If the purpose is security, we can do better, but I'm not convinced. If the purpose is because financial institutions know that they can prevent customer outflow by shitting up the outgoing transfer mechanism, we should make them do better. If this drop in friction makes security worse, then we should go back and make security better again using a type of friction that isn't such a fucking migrane to deal with.
Yes, trad banking is a mess. Also, what are considered big transactions? It totally depends on the account.
Wise has a way to set rolling limits on things like online purchases and ATM withdrawals. That’s very neat. I think that if you’re say emptying your entire savings, it’s good to have multiple safeguards (and of course being clear about what happens and why).
Wise has a way to set rolling limits on things like online purchases and ATM withdrawals. That’s very neat. I think that if you’re say emptying your entire savings, it’s good to have multiple safeguards (and of course being clear about what happens and why).
You also have something like Gmail's option to have a short delay before sending an email which I use semi-regularly. Honestly, wish I had a 5 second delay on my cell phone for all the times I fat finger dial someone on my recents tab.
Lots of words and salesmanship to say "maybe put humans back in the workflow for things that require security and safety."
Too late for that. Using crappy “AI” would be cheaper, plus you can pretend that humans aren't responsible for failures any more.
$90k should not be in an online wallet. It should be in a hardware wallet with a passphrase. If you insist on keeping it in a wallet on a computer then airgap the machine.
I don't use and have no interest in using crypto, but I do notice that emails can easily be sent to the wrong person, and very little thought seems to go into stopping this.
We have "Do you really want to send this" that doesn't even tell you who it's sending it to. "Do you really want to send this to X" with a slide lock, and a little box with a brief summary, would be so much better.
We have "Do you really want to send this" that doesn't even tell you who it's sending it to. "Do you really want to send this to X" with a slide lock, and a little box with a brief summary, would be so much better.
I've pondered on this before, but it's another place where the counterintuitive spanning of so many orders of magnitude effectively trashes any effort to do this. Any simple solution fails, and not just by a little, but utterly. "Hey, maybe we should slow down our bandwidth so an attacker can't exfiltrate our entire petabyte database." Yup, sure, that's great, but the attacker only cares about the most valuable few megabytes, like your customer data and accounting. Any attempt to slow down access to those megabytes is useless, because what's the point of petabytes of data with a window of access small enough to make downloading a few megabytes noticeably difficult?
"But jerf, we could 'just'..." Yeah, you could, but you're not going to have just one or two "justs", you're going to have thousands upon thousands, and they'll end up interacting with each other. You end up having to build an incredibly complicated scheme of labeling the value of everything, and along with getting the labeling wrong, there isn't even a correct labeling anyhow.
A: "We limit access to the users table because only so many users log in per second and we don't want anyone to SELECT * the table and walk off with the whole thing in 2 seconds."
B: "OK, great, well, I have a job here than needs to run across the entire table and send an email to anyone who hasn't logged in in a year that we're going to cut off their access soon. How long will that take?"
A: "Let's see... with the current friction on our system, it'll take... a week and a half."
B: "Oh, well, that's OK then. With the restrictions on how many emails our email systems will send per hour, that system's looking at 3 or 4 months to do the job."
You may think I'm exaggerating the time scales for effect, but I'm not. That's those "orders of magnitude" I refer to. Try to put enough friction on systems to meaningfully slow down attackers and you can easily push jobs into days, weeks, months. Especially if, as I'm kind of thinking of in this example, all this poor developer has to work with is the leftover capacity for emails, because the throttled rate is already nearly consumed by the normal functioning of the system.
(Bear in mind that if you "just" build a back door to let such processes work, that's a back door the attacker can walk through, thus defeating the entire purpose.)
It's a neat idea but it's a non-starter if you sit down and start working with the numbers. At most there's a few places you could add it and get a specific protection, but as a general principle it is not useful.
"But jerf, we could 'just'..." Yeah, you could, but you're not going to have just one or two "justs", you're going to have thousands upon thousands, and they'll end up interacting with each other. You end up having to build an incredibly complicated scheme of labeling the value of everything, and along with getting the labeling wrong, there isn't even a correct labeling anyhow.
A: "We limit access to the users table because only so many users log in per second and we don't want anyone to SELECT * the table and walk off with the whole thing in 2 seconds."
B: "OK, great, well, I have a job here than needs to run across the entire table and send an email to anyone who hasn't logged in in a year that we're going to cut off their access soon. How long will that take?"
A: "Let's see... with the current friction on our system, it'll take... a week and a half."
B: "Oh, well, that's OK then. With the restrictions on how many emails our email systems will send per hour, that system's looking at 3 or 4 months to do the job."
You may think I'm exaggerating the time scales for effect, but I'm not. That's those "orders of magnitude" I refer to. Try to put enough friction on systems to meaningfully slow down attackers and you can easily push jobs into days, weeks, months. Especially if, as I'm kind of thinking of in this example, all this poor developer has to work with is the leftover capacity for emails, because the throttled rate is already nearly consumed by the normal functioning of the system.
(Bear in mind that if you "just" build a back door to let such processes work, that's a back door the attacker can walk through, thus defeating the entire purpose.)
It's a neat idea but it's a non-starter if you sit down and start working with the numbers. At most there's a few places you could add it and get a specific protection, but as a general principle it is not useful.
Well, yes, the headline is way too broad and think about this in terms of undifferentiated data is way too abstract.
But the example in the article was a financial transaction and the relevant measurement is transaction size in dollars, not bytes. Think about it like a bank with limits on ATM withdrawals, or a store with a safe that doesn’t open at night. There’s no reason large transactions for consumers need to be fast - how often do you buy a house?
But the example in the article was a financial transaction and the relevant measurement is transaction size in dollars, not bytes. Think about it like a bank with limits on ATM withdrawals, or a store with a safe that doesn’t open at night. There’s no reason large transactions for consumers need to be fast - how often do you buy a house?
Traditional banks know this and use context based authentication for sensitive transactions.
Sms based 2fa is a known crummy 2fa. Get TOTP or a hardware token.
I feel the article is trying to sound smart by using lofty words when the answer really is simpler.
Sms based 2fa is a known crummy 2fa. Get TOTP or a hardware token.
I feel the article is trying to sound smart by using lofty words when the answer really is simpler.
I don't understand what the writer is proposing here. How is slower = secure?
Slower != secure.
But secure implies slower. Therefore, fast as possible implies not secure.
But secure implies slower. Therefore, fast as possible implies not secure.
So theater.
You actually do need to present consistently slow evaluation times when handling encrypted values, as failing fast gives out information that can be used for cracking. But other than that, there usually isn't a good reason to do it.
You actually do need to present consistently slow evaluation times when handling encrypted values, as failing fast gives out information that can be used for cracking. But other than that, there usually isn't a good reason to do it.
The article specifically mentions why fully unsupervised, no "friction" processes lead to actual, specific problems.
You could slow your stuff down without securing it in response to the article's idea, but that's not what I was referring to in my comment.
You could slow your stuff down without securing it in response to the article's idea, but that's not what I was referring to in my comment.
The more consequential the thing, the more likely that it will still be consequential after some time passes at a human scale, and the more important it is to take the time and be sure it’s done right.
It takes time to catch mistakes-whether mistakes on the operator’s part or mistakes on the system designer’s part-that unforeseen circumstances or malicious actors might be turning to unexpected effect.
In the author’s example of a cryptocurrency heist: had this happened in a US bank, where somebody tried to initiate a $90,000 transfer from the victim’s account to a strange one, there’s a much better chance that, in the days it takes to settle, a bank employee would ask questions or the friend would notice a large pending transaction and question it in time to cancel it.
I mean for that matter, we have examples of fast-settling systems (like credit card fraud detection) where that prudent degree of friction comes from having an automatic system auto-deny the transfer in the minority of cases it finds suspicious, requiring the friend to meet a higher bar of scrutiny for that specific high-consequence action.
In the case of most all $90,000 transfers to strangers in a person’s life, the money’s just as good “day after tomorrow” as it is “just as soon as this block makes it on the chain.” The house/car/rucksack of contraband will still be there, and your money will still be good.
It takes time to catch mistakes-whether mistakes on the operator’s part or mistakes on the system designer’s part-that unforeseen circumstances or malicious actors might be turning to unexpected effect.
In the author’s example of a cryptocurrency heist: had this happened in a US bank, where somebody tried to initiate a $90,000 transfer from the victim’s account to a strange one, there’s a much better chance that, in the days it takes to settle, a bank employee would ask questions or the friend would notice a large pending transaction and question it in time to cancel it.
I mean for that matter, we have examples of fast-settling systems (like credit card fraud detection) where that prudent degree of friction comes from having an automatic system auto-deny the transfer in the minority of cases it finds suspicious, requiring the friend to meet a higher bar of scrutiny for that specific high-consequence action.
In the case of most all $90,000 transfers to strangers in a person’s life, the money’s just as good “day after tomorrow” as it is “just as soon as this block makes it on the chain.” The house/car/rucksack of contraband will still be there, and your money will still be good.
Consider that in a world where almost everything is automated and reacts quickly, some faulty logic somewhere could cascade and lead to a lot of bad stuff happening before anyone even has a chance to notice. Introducing some latency, need for validation, etc, at the right places could mitigate this. I don't think just sprinkling slowness everywhere is the idea.
I do think that the efficiency hype has made us all a little speed blind. It's not like faster = secure either...
I do think that the efficiency hype has made us all a little speed blind. It's not like faster = secure either...
[deleted]
Like add a delay?
arsh4151(1)
UX isn't about always letting the user do something as fast as possible--that's just cargo cult UX. UX is about reducing the obstacles between user-intent and computer action. We want the computer to carry out the user's intent.
Sometimes that means frictionless UI: if I'm changing a font size, I want direct manipulation, instant feedback, etc. But if I'm transferring money, I want to make sure there are no mistakes and sometimes that means friction: confirmation steps, etc.
Saying that friction is good is just as useless as saying that speed is good. The whole point of UX design is to know when it's good and when it's not.