I am somewhat surprised by the statements about asymmetric crypto algorithms. Given a good library they don't seem more error prone and given many common use-cases they are not significantly slower.
Seriously? You want people to switch from software A to software B and you write an article that for the first half of the page sounds like you want them to stop using either of those softwares?
Actually I think, the misunderstanding is on your side. Unauthenticated DOES mean that the attacker can modify anything without you noticing. You might only notice because you are getting a file that looks like random junk but you wanted it to be a picture. But that is not something you should rely on for security.
But here's the point: Do you want people to spend their 10 minutes picking good passwords or setting up public key auth or should the spend them switching their server to port 24? Security BY obscurity is bad as the article states and unless you have infinite resources everything is a trade-off.
But obscuring may take away time from securing and it adds complexity to the system but systems with less complexity are easier to secure. So you at least have to be careful.
The appropriate way for users to defend themselves is to simply install https-everywhere and check "Block all unencrypted requests".
This avoids sslstrip, requires no redirect magic and no HSTS.
Although somebody should really patch it to just display big fat warnings because it is somewhat annoying to turn it on and off all the time.
I have been using http://neo-layout.org/ for years now and it works very well comes out of the box with Linux and does pretty much the same.
If you type only in english you will be wasting a few keys because it has german umlauts but it is imho still nicer than qwerty.
Write a crypto library and blog about how great it is.
Apply the tools that other people used to find bugs in it and repeat blogging about how great it is.
...
In the end you get a library that is slower and smaller (because you left out the optimized code, duh). It's still not as small as the smallest.
Is this easier to audit? Dubious but it doesn't matter because if people hadn't wanted the extra speed they wouldn't have added the optimized code anyway.
Plus, that code is already audited and rolled out and works! Who cares about auditing another library that provides nothing new?
The only non obviously-garbage argument here is usability which I am too lazy to look at because it is too fuzzy to refute anyway.
By all means, write your own crypto but DON'T USE IT! And of course don't tell other people to use it either.
I think this needs a bit more motivation (why do I want to know about BDDs) and more pictures. The code is great for playing with things and remembering better but the fundamental concepts would be clearer with more pictures.