codesections @codesections@fosstodon.org

I want to be able to tell my friends why #mastodon is better than the birdsite, so I wrote a thing: "Mastodon Is Better than Twitter: Elevator Pitch"
https://www.codesections.com/blog/mastodon-elevator-pitch/

I want this to be as persuasive as possible to outsiders, so I'd appreciate as much feedback as possible from Mastodon users

Current status:

Adjusting the kerning … of a monospaced font.

> On my way to the 2022 conference for #perl and #raku – my first in-person conference since covid started.  Feels weird! https://rakuconference.us​

Of course, the part that feels the weirdest is being back in an airport for the first time in years. A short flight like this used to be so routine, but it sure doesn't feel that way now.

(It's worse due to how normally everyone else is acting. Most people don't have masks, whereas I have 3 – to have different comfort/security tradeoffs available)

On my way to the 2022 conference for #perl and #raku – my first in-person conference since covid started. Feels weird!

https://rakuconference.us

Publishing a content hash would mean that the site couldn't roll out changes to their login page daily (contra the current CI/CD mantra). But a high security application really ought to version its releases, even for a web app (and, indeed, Bitwarden does: https://bitwarden.com/help/releasenotes/)

So each release would be a time when users/extensions would update their known-good hash.

…

All of ^^^^ seems workable. But it also seems obvious enough that I wonder if I'm missing a big flaw. Any thoughts?

If the hash of the main HTML document matches, that would mean that it requests all the same javascript files. A malicious server could mess with the content of those JS files. But JS already has the <script> "integrity" tag to check each script's contents against a known-good hash, https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

So, any change in any requested script (or CSS) would flunk the integrity check unless the HTML's hash gets updated – but changing *that* would make the HTML's hash flunk.

3/n

> couldn't a site mitigate [the amount of trust in the server that client-side WebAuthn requires] by publishing a hash of the document HTML – basically like SSH's known_hosts?

To flesh that out, I'm imagining a site (eg, bitwarden) posting the hash of the HTML for their login page so that users can check the login page's actual hash against it (manually or maybe with an extension?)

Of course, the server hosting the hash could be compromised too, but it's a static page–a low surface area!

2/n

The biggest flaw I've heard with WebAuthn/other attempts to do security critical or zero-trust tasks in client-side JS: even if you're *theoretically* not trusting the server with your secrets, you're *still* trusting them not to be so thoroughly compromised/malicious that they send malicious JS (which of course gets re-downloaded on each visit). See e.g., https://github.com//bitwarden/web/issues/660#issue-705107304

But couldn't a site mitigate that by publishing a hash of the document HTML – basically like SSH's known_hosts?

1/n

There are dozens of fish or fish-like emoji (e.g., 🐟 🐠🎣🐡🦈🐬🐳🐋🐟.𓆝𓆟)

In fact, there are so many that, if I sent you a random one, a third party wouldn't have a good chance of guessing which one I'd sent.
This means we could adopt a new form of 2FA based on sending fish emoji

“In addition to your password, please log in with your one-time cod”

Hmm and my post ^^^^ is, oddly enough, now on the HN front page – even though it I didn't submit it and hardly anyone has upvoted it.

I guess no one is online this time of morning-ish on a Saturday?

And now there's a followup to ^^^^
Unix philosophy without left-pad, Part 2: Minimizing dependencies with a utilities package, https://raku-advent.blog/2021/12/11/unix_philosophy_without_leftpad_part2/

I intended part 2 to be shorter, but it ended up nearly 2× as long. And, the thing is, the main topic I went on about was the value of concise code!

… I might have a problem.

I've got a new blog post: _Following the Unix philosophy without getting left-pad_, https://raku-advent.blog/2021/12/06/unix_philosophy_without_leftpad/

It's part of the #raku Advent Calendar, but I tried to write it in as language-agnostic way as possible (and I actually spent more time talking about #javaScript than Raku. #rust and #python also get a few mentions)

Under appreciated facts:

* Context switching is very expensive for computers. It causes them to synchronize their CPU caches to main memory

* Context switching is very expensive for humans. It causes them to empty their mental cache

The one fact that gives me the most optimism about the future of tech is that, fundamentally, software development suffers from diseconomies of scale.