Friction is Good: Let's add it to our digital experiences(theregister.com) |
Friction is Good: Let's add it to our digital experiences(theregister.com) |
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.
I wish day to day software emphasized speed
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.
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.
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.
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.
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.
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.
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.
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).
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.
"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.
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.
But secure implies slower. Therefore, fast as possible implies not secure.
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.
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.
I do think that the efficiency hype has made us all a little speed blind. It's not like faster = secure either...
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?
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.
Chip and pin or even chip and signature is just too much effort to pay for something
https://en.wikipedia.org/wiki/Brazilian_Carnival#/media/File...
