This is why I've become a fan of StrictYAML [0]. Of course it is not supported by many projects, but at least you are given the option to dispense with all the unnecessary features and their associated pitfalls in the context of your own projects.
Most notably it only offers three base types (scalar string, array, object) and moves the work of parsing values to stronger types (such as int8 or boolean) to your codebase where you tend to wrap values parsed from YAML into other types anyway.
Less surprises and headaches, but very niche, unfortunately.
A service that lets you sign up by uploading a SSH public key could just as well let you upload multiple public keys in your profile to be able to connect from other devices.
This is incorrect. SSH certificates work just like x509 certificates in that regard. Also, with PubkeyAuthentication, there exist all kinds of ways to collect host keys before connecting to them for the first time and thus avoiding the trust-on-first-use problem. Especially in private networks where you control all the nodes.
> Signing in is cryptographically signing a commitment to the current ephemeral tunnel.
I can see how SSH could be used for authentication on the web. And I have no doubt that it would be sound out-of-the-box. But I am not sure what you mean by your last sentence. Do you mean that authentication targets are gated and only reachable by establishing a tunnel via some kind of forwarding?
Aside from the wonderful possibilities that are offered by using port forwarding of some kind, you could also simply use OpenSSH's ForceCommand to let users authenticate via SSH and then return a short-lived token that can then be used to log into an application (or even a SSO service).
I guess no one uses SSH for authentication in this way because it is non-standard and kind of shuts out non-technical people.
That is a valid point. But no, the company has been around for 31 years and I have only worked there for just over 8 years. I am confident however that no large-scale layoffs ever happened there, because I have heard all sorts of harrowing stories from "back then", abusive managers and the like, but layoffs were never mentioned.
Might be survivorship bias though because the people that could have been laid off in the first few years cannot be there to tell the tale, of course.
I think the size definitely matters, but I am not sure about the extent to which it matters.
I work at a company of roughly over 200 employees that is part of a much bigger org. Layoffs never happen where I am working. And one factor may be that HR has a different, in some cases personal relationship with their employees. That is certainly not the case in the parent org where large-scale layoffs happen every few years.
Edit: And I would not even attest that my company is one of those with a "heart", as you say.
I am not advocating for this but you could turn that argument easily around: Not laying off people makes them feel very secure which does not incentivice them to take risks and innovate either. At least when they are no inherently driven to push their careers forward.
Edit: To expand on my comment: At my company the problem with missing innovation is not related to layoffs (which do not happen, thankfully). But rather that hiring is very slow as management thinks teams need to "earn" those additional resources by innovating instead of the other way around: hiring people that are willing to innovate.
Most notably it only offers three base types (scalar string, array, object) and moves the work of parsing values to stronger types (such as int8 or boolean) to your codebase where you tend to wrap values parsed from YAML into other types anyway.
Less surprises and headaches, but very niche, unfortunately.
[0] https://hitchdev.com/strictyaml/