[HN Gopher] Friction is Good: Let's add it to our digital experi...
___________________________________________________________________
Friction is Good: Let's add it to our digital experiences
Author : mpesce
Score : 47 points
Date : 2024-02-14 08:32 UTC (1 days ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| raspyberr wrote:
| >For sixty years, computing has emphasized speed
|
| I wish day to day software emphasized speed
| thfuran wrote:
| It's frankly amazing how slow a lot of everyday stuff is given
| how damn fast modern hardware is.
| aqfamnzc wrote:
| 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
| vonjuice wrote:
| 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.
| atahanacar wrote:
| I don't understand what the writer is proposing here. How is
| slower = secure?
| NegativeK wrote:
| Slower != secure.
|
| But secure implies slower. Therefore, fast as possible implies
| not secure.
| slowmovintarget wrote:
| 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.
| NegativeK wrote:
| 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.
| alwa wrote:
| 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.
| nurbl wrote:
| 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...
| klabb3 wrote:
| 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.
| smallmancontrov wrote:
| > 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.
| klabb3 wrote:
| 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).
| ghaff wrote:
| 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.
| jerf wrote:
| 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.
| skybrian wrote:
| 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?
| slowmovintarget wrote:
| Lots of words and salesmanship to say "maybe put humans back in
| the workflow for things that require security and safety."
| tempodox wrote:
| Too late for that. Using crappy "AI" would be cheaper, plus you
| can pretend that humans aren't responsible for failures any
| more.
| bluGill wrote:
| 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.
| rglullis wrote:
| 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_.
| samatman wrote:
| There is no way to set Apple Pay to activate without user
| input, is this not true in Android?
| wlesieutre wrote:
| Tap-to-pay NFC credit cards
|
| Chip and pin or even chip and signature is just too much
| effort to pay for something
| aqfamnzc wrote:
| 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.
| GauntletWizard wrote:
| 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/F
| ile...
| rglullis wrote:
| 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.
| aqfamnzc wrote:
| (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.
| eternityforest wrote:
| Chip and pin can be unreliable because of bad contacts
| bluGill wrote:
| 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.
| rglullis wrote:
| 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.
| skybrian wrote:
| 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.
| pram wrote:
| 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.
| marcosdumay wrote:
| 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.
| ToucanLoucan wrote:
| 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.
| al_borland wrote:
| 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.
| ChrisMarshallNY wrote:
| _> 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.
| m3kw9 wrote:
| Like add a delay?
| krunck wrote:
| $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.
| eternityforest wrote:
| 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.
| GMoromisato wrote:
| I agree with the sentiment, but this is UX 101.
|
| 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.
| unethical_ban wrote:
| 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.
___________________________________________________________________
(page generated 2024-02-15 23:02 UTC)