Friction is Good: Let's add it to our digital experiences

>For sixty years, computing has emphasized speed

I wish day to day software emphasized speed

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.

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.

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.

Lots of words and salesmanship to say "maybe put humans back in the workflow for things that require security and safety."