At least it will make it that much harder for him to launder his money

... they still have to stop making dreck with secondary characters no one cares about.

The fact is that Twitter was bloated crap run by hypersensitive children of helicopter parents before Musk bought it. Their so-called curators were nothing but an Opinion Police brigade, and if they didn't like your opinion, you didn't get to use Twitter. You were One With The Body, or you were cast out. It was basically run by a bunch of Mean Girls with a Cancel button. Musk's management hasn't been perfect, but it's been a large improvement over the previous state of things. When he fired said curators, it was a situation of, as we say on Slashdot, And nothing of value was lost.

As for "bye bye", Musk would be the first to point out that you have plenty of Twitter alternatives to go and enjoy.

Microsoft is often accused of always being behind the curve, but Microsoft went all-in on mobile at a very, very early stage. Bill Gates personally made it a priority. And they were big into phones early on. They just couldn't figure out the interface. They were working on Metro when the first iPhone blew the doors open on the smartphone market, but by the time they were ready to ship, Google had already copied the iPhone interface with Android, and it was too late. The market just doesn't want to seem to take more than two competing systems. By the time Metro went public, Microsoft was an also-ran. It had to be incredibly frustrating for them as they'd seen the vision and had been working on mobile for so very long. And Metro WAS a very good interface for mobile. From what I understand, MS even offered to foot the costs for developing popular corporate apps like airline, food, travel, etc, but they were told that there was no interest in supporting a third ecosystem by the likes of Delta, American Express, etc. So they eventually just gave up on mobile. A shame, really.

Touching a button is not user authentication, it's confirmation. The difference, as you observed, is that anyone can press the button, including the attacker who stole your security key. There's also no way to tell which authentication request you're confirming.

That helps. It still doesn't provide any way to tell which authentication request you're confirming. I'm sure the FAR on that device is terrible, but that's probably fine in this context.

I suppose that depends on what CaptainDork's own prose is like. If it's bad enough, "bland average" could be quite eloquent by comparison.

Maybe. The facts that security keys generally don't require user authentication and are often left plugged into devices all the time are weaknesses under some threat models.

I have specific ideas about what the best solution is, but it hasn't yet been implemented. I'm working on it :-)

The Bluesky Mir is coming ;)

Huh? You're upset that Jack left Bluesky because people there didn't like him? I'm confused.

Sounds like Jack went full Kanye, and got booted out of Bluesky.

He didn't get "booted", but it was a rather amusing situation, where he dropped a bunch of seed money on Jay's project to make Bluesky... only to find out that the vast majority of the people who flocked there don't actually like him, and weren't afraid to let him know ;)

1) You don't open to more people than you have the capacity to serve.

2) They do not use the same backend. Bluesky's backend is specifically designed to fix Mastodon's design flaws that make it so annoying.

3) Bluesky is growing far faster than Mastodon.

Yep. This is the way to treat your crown jewels, which is what your primary email address is. At least until we finally move away from passwords and therefore from password reset flows.

That will, of course, create other problems :D

You can copy your Google Authenticator token to other devices quite easily. Of course, the more places you put the seed secrets, the more opportunity there is for someone to steal them.

They're not usernames, nor are they passwords. They have very different security properties from both, and don't fit into the username/password model.

The main difference from usernames is that usernames are not inherently bound to the person, but biometrics are. If I know your username, I can type it in and claim to be you. If I know your fingerprint, I cannot submit it to a proper fingerprint scanner (note that "proper" is carrying a lot of weight here). Said another way, in the context of a proper scanning and matching environment, biometrics do provide authentication. Very strong authentication.

This highlights, though, that all authentication value in biometrics comes from the integrity of the scanning process, which is why I said that it doesn't provide much when the scanning is done remotely, unobserved, with a scanning device under the control of the person allegedly being authenticated.

While biometrics fail as authenticators in uncontrolled environments, they fail as identifiers in nearly all contexts. The main requirement of an identifier, like a username, is that it be unique. Biometrics aren't.

Well, probably they are in some absolute sense, except for identical twins in some cases, but in practice all biometric matching is fuzzy because measuring bodies and matching them against templates is less precise than matching the bits of a username. Biometric matching is always testing whether the the livescan is close enough to the stored template under some complex distance metric. This means that given a large enough database you will get false positives. And thanks to the Birthday Paradox, this happens with a much smaller database than you might think.

To illustrate with some very rough and approximate numbers. Suppose that a biometric matching scheme has a 100,000:1 false accept rate (FAR). Suppose that this rate is absolutely consistent across individuals (pipe dream, but reality is way too complicated). So, you can think of it as a scheme that creates 100,000 pigeonholes and slots every individual into one of them. The probability of you falling into the same pigeonhole as me is 1 in 100,000. That's actually a very, very good FAR, BTW. I don't know of any commercially-available fingerprint or face systems that good.

Now, suppose I put a bunch of people in the database, and then you present your biometric and we try to identify you from the database. How many people can we put in the database and still have reasonable odds of uniquely identifying you? If we have 250 people in the database, odds are >50% that we'll hit at least one false positive. We'll match you, but also one or more others. What FAR would we need to guarantee a low probability, say 1/1000, with a database of a 1000 people? 500,000,000:1, or thereabouts. Nothing is that good.

The reason that biometrics are useful for identification in, for example, criminal trials, is that you don't (or shouldn't, anyway, it's happened, c.f. Prosecutor's Fallacy) convict a person based only on biometric evidence. You also need to have some other reason to believe they were in the vicinity, or had some motive, or something. They work extremely well as proof that an already-identified suspect was the perpetrator, though.

One other way in which biometrics are not like usernames, BTW, is that biometric scan templates are not really standardized. There are some standards, but they apply only to a subset of scanner types. In general, it is not possible to scan your fingerprint on your phone and send that to an off-device relying party for identification. It could work with face or iris imagery. Sort of. Face identification is much less precise than fingerprint. Iris could be good, I think. Also retina, except retinas change over time. Good identifiers should also be constant.

So, no, biometrics are not good identifiers. They are very strong authenticators, but only in the right contexts.

This is equally true of almost every other use case people have dreamed up for globally distributed ledgers. Unless there is no one who can be trusted to operate a centralized transaction database, the database will always be cheaper, faster and better. And it's even fine to have a set of centralized databases that get mutually reconciled on a regular basis -- which is how the financial systems work.

The only truly good application of distributed ledgers I've seen is for transparency-related projects where you want the data to be fully public and to make it impossible for any party or even large group of parties to subvert. Things like Certificate Transparency. I expect some future systems to be stood up that focus on binary transparency, making it easy to verify in an automated way that the binaries you're running are the ones they're supposed to be and that they're reproducibly-built from a specified version of the source code.

I've yet to see any other use cases where the cost, complexity and overhead of globally-distributed ledgers is justified.

(Distributed ledgers do make a lot of sense in highly-scalable systems under the control of a single entity. For example many eventually-consistent web-scale databases are built on some form of distributed ledger.)