ptoomey3

Yeah, to match the dot pitch apple is designing for, the 4K monitor would have to be more like 22 inches instead of 27. We know this since the 4K iMac is a 21.5 inch screen.

For me the option key was always the one that threw everything else off..since failure to recognize it made me doubt all the others :-). One "pneumonic" that helps for the option key is that it looks a bit like a "fork in the road" (i.e. "an option"). The ^ for ctrl goes back to linux, so "logical" for folks with that background. And, cmd is used so often I just got used to it.

One issue with HTTPS client cert auth is that it can be non-trivial to support at the application level when you have a multi-tier architecture where TLS termination happens at the edge of your infrastructure.

What isn’t stated in that post is that we are sending monthly email notifications to any user found using password authentication during the deprecation. As a result, we expect the vast majority of users will have been notified several times before the brownout. The brownout is mostly aimed at unearthing any forgotten automations that will break when we disable support for password authentication permanently.

GitHub Actions tokens are actually based off our newer “GitHub apps” system and not “OAuth apps”. GitHub app tokens support much more granular controls (both in terms of abilities and resources). OAuth doesn’t lend itself to super granular controls since they are scope based (ex. Defining a scope per repository doesn’t really scale). This whole area is something we want to address with personal access tokens in the future.

Think of this deprecation as step one of a multi-step plan/roadmap .

My experience with password managers is that they work great for me, because I understand every sharp edge and can work around them. My experience when advising family to use them is that they invariably fail them and they get frustrated. Password managers rely on pretty gross heuristics to work. They are effectively trying to automate something built for a human (choosing, remembering, and entering a password). WebAuthn gives us a real API built by and for machines. This will make the flow much less error-prone and more secure.

100% true. I personally wish the hardware-focused U2F bit didn't predate the WebAuthn spec. I feel, because of that, way too much focus is placed on the "hardware security" bit. I view the main benefit as replacing user selected weak passwords with a non-phishable, non-server-side loggable, non-server-side sensitive secret needed authentication standard that can be implemented entirely by code, largely without user involvement, and that doesn't rely on gross failure-prone heuristics the way password managers do today. Oh, and it is all a better user experience too. It is one of those crazy wins that you just don't get in the security space that often. I really don't care if that takes the form of a hardware security key or as a pure software implementation in the platform browsers. My guess is we will strike a middle ground...with the dominant form of authenticator being hardware based...but that hardware taking the form of the devices you already own (phone, laptop, etc).

Yet another batteries included downside...a blackbox http implementation that is hard to debug.

This isn’t to say it happened on every response..it was a relatively small fraction. But, it was enough to tell _something_ was going on. Who knows, it could be something quirky on the network and not even a gRPC issue. But, because the runtime is so opaque, it made debugging quite difficult.