We must stop trying to fix the user to achieve security. We'll never get there, and research toward those goals just obscures the real problems. Usable security doesn't mean “getting people to do what we want.” It means creating security that works, given (or despite) what people do.

In other words, "lock the users up so they can't hurt themselves"?

Quite frankly, that's disturbingly authoritarian. In the real world, the analogy would be the government deciding a long time ago that crime can't be fixed, and enforcing complete control over everything the population does.

That's fortunately not how things turned out, although it now seems to be rapidly heading in that direction...

My personal view: people are going to continue do bad things either accidentally or maliciously, and trying to stop that completely means eliminating all personal freedom (and responsibility.) The ideal is somewhere in the middle between freedom and security.

No, it means that supposedly "dumb" actions by users like inserting a USB stick or opening a Word attachment shouldn't break the security of the system. (In fact, they're only "dumb" actions because our systems are designed without security in mind.) That's hardly authoritarian.

We are talking about tradeoffs- and the truth is, we traded security for development speed and low price, because security has a tendency to arrive very, very late in the game, the moment people want to abandon the system or concept.

https://en.wikipedia.org/wiki/Modified_Harvard_architecture

You can have a guest checkout so they don't need to have an account, but some people want them.

https://thisdata.com/blog/an-introduction-to-passwordless-lo...

The user may want to know in what state the order is, maybe change something after payment, return product, things like that. There is something reassuring about it too.

It is users who want to be remembered.

Note for example how you can track any package in the world when you know it's code. That seems to be working well without relying on user authentication, no?

I believe if statistics would be produced: the users mostly don't want them. The owners of the site and the programmers mostly do.

Some customers are repeat customers, but even if we are generous and assume that the majority are not repeat orders (I'd estimate 25% are repeat orders), that's over 1/3rd that created an account even though I offer guest checkout without an account and don't really push them to create an account.

For example, I personally like to be able to follow the order etc. but often online stores insist that I have to register for anything like this. If the order number and my name were enough, which technically should be, I wouldn't. But having no alternative, I do. So I count myself in "I would prefer not" but you see me registered and count "one of 3 who like registering."

Except for mailing lists. And email forwarding. And a lot of other stuff you take for granted. Users might not explicitly know about the technical details of how a lot of things work, but that doesn't mean they don't expect the resulting behavior.

It's fashionable, these days, to put authentication and authorization in the transport layer. It's not a natural law, though. As an example, consider s/mime or pgp message signing. MDAs could validate signatures and discard messages that are not correct. This is an example way to solve the auth problems you describe without breaking existing mailing lists, since you'd be validating the content instead of the envelope.

Just food for thought. SMTP isn't as broken as you think, and replacing it isn't necessary to solve today's problems.

You can't ask regular users to run pgp themselves. This is a prime example of the sort of technical details that a user shouldn't be asked to even understand or be aware it exists.

Lipstick on a pig yes, optional, no. If you want to have your e-mail delivered to Gmail you'll need them. And since Gmail is 50%+ of all e-mail that means it's pretty much mandatory.

Maybe for you. But considering I use gmail I block it all and never notice any problems

Tho ignorance of technology concepts is not something to be tolerated, it's something to be cured with vigilant education efforts.

I could let the user enter any password regardless of password rules, the only rule being it meets the minimum entropy requirements (long enough). Instead, I must make them enter a password that is a minimum of 8 characters with mix of case and symbols.

Why? Because it's the industry's best practice. To not follow would open the company to liability, so I do what the other monkeys are doing [1].

[1] - https://security.stackexchange.com/q/33470