Fair enough, was just thinking about many low effort scams that have “EMERGENCY!!! ACT NOW!!!” in red boldface. This, by being slightly? less aggressive is actually less likely to trip my “this is phishing” detector. Obviously ymmv.

> the actual solution is to avoid dependencies whenever possible, so that you can review them when they change.

If you're publishing your software: you can't "not" depend on some essential service like source hosting or library index.

> You ARE reviewing them, right?

Werkzeug is 20kloc and is considered "bare bones" of Python's server-side HTTP. If you're going to write a complex Python web app using raw WSGI, you're just going to repeat their every mistake.

While at it: review Python itself, GCC, glibc, maybe Linux, your CPU? Society depends on trust.

Depends what you use it for. I don’t think email is a single thing in that regard. For example I’ve used it as a backup method for important files and also as 2 factor. Those are wholly different things that warrant different solutions. The majority of email volume is not person to person communication but part of some corporation/spammers/scammers business model who at best, like my bank, is using it to shift liability away from themselves onto consumers and at worst is attempting to defraud me of all I own. It’s still useful in business, maybe, but pretty sure teams/slack/… will win eventually.

As long as you're OK with self signed certificates or PGP keys, I'd be on board with this.

I really, really dislike the idea of using TLS certificates as we know them for this purpose, because the certificate authority system is too centralized, hierarchical, and bureaucratic, tightly coupled to the DNS.

That system is great for the centralized, hierarchical, bureaucratic enterprises who designed it in the 90s, but would be a pain in the ass for a solo developer, especially with the upcoming change to 45 day lifetimes.

And one pwned domain later, we are back in square one.

That wouldn't work against a really sophisticated attacker. Especially for something that's clearly being maintained for free by one overworked person in their spare time (yet again).

You'd need some kind of offline verification method as well for these widely used infrastructure libraries.

> The solution is to tie a package to an identity using a certificate.

Identity on the Internet is a lie. Nobody knows you're a dog.

The solution is to make security easy and accessible, so that the user can't be confused into doing the insecure thing.

what about it?

I clicked the link like a genius :)

Oh, that makes much more sense - thanks!

> There is NO reliable indicators

Completely agree. The only reliable way is to never use an email/SMS link to login, ever.

I agree: any of the potential indicators of phishing (whether it's poor presentation, incorrect grammar, tight deadlines, unusual "from" addresses, unusual domains in links, etc.) can easily have false positives which unfortunately dull people's senses. That doesn't mean they can't continue to be promulgated as indicators of possible (not definite) phishing, though.

I used the word "often" rather than "always" for this reason.