There's a long list of known vulnerabilities in EC schemes, e.g: https://github.com/elikaski/ECC_Attacks

Ironically, for all the talk of how RSA has a lot of "gotchas", EC has a long (longer?) list of its own, and they're not as intuitively obvious as the RSA ones. But most of them are *verifiable* by the other party. So this means nobody is verifying.

I worry that the emudhra CA vulnerability is as trivial as tiny coefficients. This is *easily* detected, and that means in all likelihood there are folks out there who have automation to detect them, and they knew about this before the rest of us.

But if I'm looking at the right certs, this has been out 18 months, and if nobody in the "white hats" found this until now, that leaves the possibility that a bunch of bad actors have been able to play with this for a while. And there may be others.

The more realistic version of events is that the people promoting passkeys (webauthn) are genuinely in this for the good. Well, a bunch for the promotions (see “PDD”) but even that’s mostly neutral.

But when it comes to resourcing work on interoperability (transfer), you already know how that goes, right? Low priority. And that’s reasonable—why help some other platforms before yours? But you also know that “low” can end up “never”. Not intentionally—this is just how big tech works.

And I get *why* it’s necessarily nontrivial to extract them. That’s the entire point! If it were just a few taps to copy/paste your passkey as base64 into a web site, they would fail at one of their primary goals.

But the lack of *any* ability to do this, without a solution built inside the same ecosystem, doesn’t help the case.

Passkeys are actually quite nice, and solve a bunch of actual problems. The conspiracy theory is unhelpful, because companies and individuals don’t actually run to evil mastermind plans. The simpler explanation as to why they are, essentially, turning into yet another form of platform lock-in is: there’s no incentive not to.

I too am hesitant to “upgrade to passkey” on my iPhone, given how nontrivial it is to copy or transfer them off the Apple ecosystem. No conspiracy, just blunt corporatism.

Occurred to me this was before I knew of the existence of pharmacokinetics. Half-life is apparently 10-12 hours, so that bloody explains. This is how it affects everyone, just most people don’t react as strongly. Must be so many driving on NyQuil out there.

RE: https://infosec.exchange/@0xabad1dea/117427929316787408

Dunno about anyone else, but if I have even the smallest dose of NyQuil, that’s 36 hours of feeling like I’m 6 pints drunk. (This is apparently not most people’s severity). While also doing nothing to help me sleep. I cannot stand the stuff.

Anyway, this is definitely a nuance that has been totally lost to the slop-brained folks building out data centers. Or rather, power is not a constraint to them at all, because they feel no remorse at cranking up performance at ever-decreasing efficiency and ever-increasing number of gas turbines.

It's a shame, because otherwise we would at some point have seen data centers *shrink* in their power usage, over the course of years.

Why is making your service faster actually...er... slower? Because modern data centers are *very dense* to the extent that they need to balance power allocations. You're likely cramming as many instances into a server as possible, up to its resource limits—often the power limit. So that 20% increase in power loses 20% of the instances you can fit, and overall it's now 10% lower rate of task completion.

So guess what happens when you make the server more efficient? Yep, faster.

Little not-very-secret thing I learned from my time designing servers:

Efficiency is performance.

Huge ramifications, but not really a secret, because this is exactly why things like AWS Graviton exist. And yet, it still seems to be a really alien, contrarian thing to say, in this field. Especially in today's "AI" craze, which goes 100% against this.

So, let's say you improve your service's performance by 10% with a neat trick. But it increases power by 20%. This made your service *SLOWER*.

It's not like you could just ask YouTube to host your snuff video (US government firing squad), because obviously they're going to immediately cancel your account and call the police.

So presumably you'd have to roll-your-own, which the DOJ doesn't have the means to do, so it would be _other people's servers_ and again you would instantly have your account canceled and the police called on you.

So you'd have to roll your own servers, which of course will not scale. And your peer call the cops.

Knowingly streaming a snuff video would, under normal legal operation of the nation, get your internet peering contracts canceled, law enforcement summoned, and all those responsible put through the criminal justice system.

Would also apply to anyone knowingly allowing this peering arrangement.

So, who's gonna blink first?

It really is every 5-10 years this keeps happening: https://en.wikipedia.org/wiki/DRAM_industry_price_fixing

They come up with some deniable excuse why they're unable to fulfill demand, and depending on how strong global governments are at the time, they either get away with it; or pay huge fines, have their executives jailed, and then promoted to President of Samsung Europe. (Yes that is real)

Here we are with another round, and seriously, please think twice about coming to their defense.

While it is monumentally expensive to build a fab, this is very much an overstatement for a number of reasons:

* The "expensive" part is mostly the R&D and large scale tuning/yield of a whole new process node. But this doesn't apply.
* The timescale involved is likewise for a whole new node and/or building in a new territory. Also doesn't apply.
* They would be well on their way to completion by now if they started back in 2024.
* Even DDR4 would be relieve some demand.

Any time you ask, "Why aren't DDR manufacturers at least half way to building extra capacity already?" some reply-guy pops up with "It's not simple building a DDR5 fab". And that is the manufacturers' scheme working perfectly.

Related: If a user interface occupies more display area than the content, then the author considers their application more important than the content.

Low-contrast, low-affordance user interfaces are the natural result of assigning low value to the content it controls, and the people who use it.

RE: https://esq.social/@LeslieBurns/117389328743492936

Let's take a sip of fresh hot coffee just before I get a quote for how much my health insurance will cost next month after COBRA expires...

It strikes me that the reason I'm running into all these basic quality of life (and C++ support) issues, is related to my previous comment about how all the C-based RTOS out there have _suspiciously similar code_. They're all written by the same people, or cross-pollinated by people who moved between places.

The last few RTOS I've worked on were internal, and I (eventually) won battles to make this shit work.

I haven't done that here, and I'm not going to invest in a slop repository.

It is apparently a deliberate design choice in Zephyr that C++ static constructors are called _after_ kernel and driver init, so you can essentially only safely use C++ in "application code".

I can say with 100% certainty this is the wrong choice.

About ready to give up on this shit.