Austria, Switzerland and Germany have a very long rock climbing history (unsurprisingly), and their respective climbing associations are obsessed about safety.
But YubiKeys are built on a hardened hardware security module instead of a general purpose phone operating system with full network connectivity and a huge attack surface.
Having a UI does not increase security in a meaningful way. The attacker is just going to wait until the victim connects to an interesting target server and then hijack that connection. The ControlMaster feature makes that trivially easy, but it's not hard to do real injection [1].
If the workstation is compromised, it's over.
At that point, all you can do is to prevent an attacker from copying the key or using it without user interaction. A YubiKey does both - you can optionally set it to a mode where you have to approve each signature.
With a bank transaction, the whole transaction is part of the approval process and can be verified out-of-band. With a SSH login, this is not possible since you're still going to trust the workstation as soon as the session is established.
I'm not saying this project is useless - IF your phone is actually more secure than your workstation - which may or may not be the case - AND you've been previously been storing your keys on your workstation, then it's definitely a step up. But really, at that point, just buy a YubiKey (and properly secure your workstation!).
Otherwise, you now have TWO single points of failure instead of one. If either your phone or your laptop is compromised, it's over.
If you want login approvals that show the server name, do it as a second factor and use something like Duo Security with push approvals. This actually increases your security - instead of having, an attacker would now have to compromise both of your devices.
For anyone interested in Kubernetes: Red Hat's OpenShift is worth taking a look at.
It's upstream Kubernetes + a PaaS framework built in top of it.
It takes care of role-based access control, has a secured Docker registry (prevents applications from pulling each other's source code), Jenkins integration and can automatically build, push and deploy your applications.
Our team started using it and it's great. The documentation is top-notch (it's probably the best docs I've ever seen in an open source project).
I've seen many teams re-invent the wheel over and over again, when OpenShift already does most of what they need.
It resulted in random, hard to reproduce ENOSPC errors down the line without either data or metadata being anywhere close to full. Neither us nor the btrfs developers that took a look at it were able to figure out what exactly went wrong, but it was something about new blocks not fitting anywhere despite lots of free space.
Someone on #btrfs said that the filesystem layout is a lot different when using the conversion tool and all of the regression testing happens with regular filesystems, not converted ones.
We reinstalled all machines from scratch. Never happened again.
And sometimes, you have no choice - there's no FOSS alternative to TeamViewer, and thanks to it running inside Chrome, I no longer have to run a Windows VM.
The web based SSH client is published by Google themselves and they use it internally.
> The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've made an "app".
The way things are, right now, Chrome is much better at protecting apps from each other than my Linux desktop is. If, for example, the Cleanflight or TeamViewer apps were regular apps, a bug in them would fully compromise my account.
---
Off topic remark about Linux distro security: I really like Arch, but security isn't their strongest suit. For example, they still haven't enabled full-system ASLR, citing unfounded performance concerns, when other distributions did so years ago. Even Windows with all their third party apps has a higher percentage of ASLR binaries than the average Arch system.
They also have no central build system and instead rely on volunteers who build the packages on their personal systems and sign them using their personal GPG keys.
I really want ASLR in Arch so I'll keep complaining about it publicly until it finally happens :-)
It's useful outside of Chrome OS if you have a security perimeter based on TLS with ACLs and auditing already in place and you want to use it for SSH as well:
I'm running btrfs in production with a very heavy workload with millions of files and all sorts of different access patterns. Regular deduplication runs, too. We're probably one of the largest btrfs users.
Had a LOT of unplanned downtime due to various issues with older kernel versions, but 4.10+ has been solid so far. You definitely need operational tooling (monitoring, maintenance like balance) and a good understanding of the internals (what happens when you run our of metadata space etc.).
Happy to answer questions!
On a related note: Never ever use the ext4 to btrfs conversion tool! It's horribly broken and causes issues weeks later.
This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps.
Some examples of specialized apps I use all the time that would require a native app otherwise:
- Signal Desktop
- TeamViewer
- Postman
- SSH client
- Cleanflight drone configuration tool
It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure.
Now everyone is moving to Electron and instead of one Chrome instance, I'm now running five which use more than one GB of RAM each. Much less secure, too, since each has its own auto-updater or repository and instead of being sandboxed by Chrome's sandbox, they're all running with full permissions.
It also means I cannot longer use Signal Desktop on my work device since installing native apps is forbidden for good reasons, while Chrome Apps are okay.
It also hurts Chrome OS users since Chrome Apps are being abandoned in favor of Electron. It also makes it less useful for developers to create Chrome Apps since the market is much smaller.
Since Chrome Apps continue to be available on Chrome OS, I'm considering separating that functionality into a stand-alone runtime or making a custom build for Linux. Anyone wants to help with that?