Egregoros

that sort of all-or-nothing argument doesn't make much sense to me, just as much as "we need the fixes!" I mean, do you seriously believe that the existing fixes fix all side-channel problems for good? given the ongoing stream of such problems, IMHO it would be irresponsible to act as if this was the case and not take other isolation precautions. at which point the so-called fixes are more like wasteful overhead.

the way I see them, the boundaries are most useful to avoid accidental data corruption and leakage. the information and tactical asymmetries and the general quality of software make it so that an intelligent and resourceful opponent who gains some access can likely find ways to escalate that access, and presuming otherwise is likely self-defeating.

how doesn't the door that Intel uses to alter the CPU properties in an Intel-controlled way fit your description of backdoor? just because they're upfront about its existence, so we might as well call it a front door?

sure, you have to open that door for it to sneak its blob in, unlike other vendor-backdooring systems at higher levels of enshittifiability, and it's presumably not universal, unlike other vendor-backdooring systems, but it seems specious to not consider it a backdoor.

but I get that you're speaking of a theoretical backdoor they could conceivably install if you open the preexisting backdoor to them. that amounts to dismissing the known, actual backdoor to distract yourself with a theoretical one.

I suppose you'll find that most users aren't aware and have never heard of this "advertised" feature. can you point of an ad that even mentions something like "get your processor fixed or broken or downgraded through your operating system vendor!"

see, in your post you show you trust Intel to not be an attacker, because you imply Intel should have access to the innards of your computer. well, not mine. if I'm not allowed to change those bits, nobody should.

and if it didn't have any security impact, why do we seem to always end up talking about security when the topic is microcode?

but, sure, if you don't want to call it a backdoor, what kind of door do you want to call it? sneakydoor? sidedoor? bottomdoor? frontdoor? masterdoor?

#ilovefs

free software is a wonderful conceptual framework that enables users to have control over their digital lives, instead of being subjugated by others through the software they use

there's this one person who figured out the ethical, social and political problem with nonfree software, and showed us the path to freedom

it didn't make everyone happy, of course. those who wanted to keep their power and privilege first ignored him, then laughed at him, and then fought him in very very dirty ways.

a number of people fell for the lies used to attack him, and foolishly made the attacks against their own freedoms stronger.

others knew they were lies, but joined the lynching for personal advantage.

on this day of celebration of free software, I thank everyone who didn't join the lynching, and stood firm in defense of free software, even from these ad hominem attacks against our movement.

I also thank those who came to realize their error, publicly repented, and worked hard to undo the harm their error enabled.

wow, that is clever indeed: they don't get your key, they get the random part that goes into forming the key, while the other part is derived from the PIN, so they can (i) authenticate the pin without knowing it or ever getting it, and (ii) extract the part they hold from the enclave and send it back to you (if you provided the right authentication within a limited number of attempts) so you can hash it along with a separate key also derived from the PIN they don't know to recover your master and application keys. it feels sound even without the replicated enclaves. even if they retained the random number outside an enclave, they'd still have to brute-force the PIN to recover your key, and IIUC all this would get them would be your social graph. (maybe your backups too?)

but then again, the weakness is the computing device where PIN gets entered and random part gets generated. whoever controls that device gets both, and can thus derive all the keys and gain access to whatever the keys were supposed to protect

CC: @feld@friedcheese.us @rysiek@mstdn.social

you seem knowledgeable about signal. I hope you don't mind if I shoot you some questions.

does it use TPM features on mobile phones as well?

how does it deal with linking multiple devices to an account? does each device get a separate key generated locally using TPM? or do they all share the keys first generated in a compromised mobile phone?

when you link a new device to an account, does it gain access to past messages, or only to future messages?

is there any way for you to tell in case someone else uses your compromised keys/credentials to gain access to your account, e.g. by linking a device that becomes visible to other devices or somesuch?

thanks in advance,

CC: @feld@friedcheese.us @rysiek@mstdn.social

of course you can. they just won't get it before they come online. which is kind of duh! for instant messaging, isn't it?

now, if you're concerned about the two of us never being online at the same time, install Jami on your home server, or on a VPS, link your account there, and it will get a copy of your messages whenever you send or receive them, and it will transfer them to your peers or to your own device whenever they come online.

now, if that's not good enough for you, I guess you really prefer to share your conversations with third parties for them to do this for you. me, I prefer my autonomy.

CC: @davep@infosec.exchange @rysiek@mstdn.social

nope. I'm told they don't even have access to data, or even metadata, thanks to some technology indistinguishable from magic in its protocol. but I won't pretend I really understand how that works.

the main problem with signal is their insistence on demanding a snoop phone to get started. that spoils the entire experience, and probably exposes its users' conversations, metadata and even secret keys to third parties. see https://blog.lx.oliva.nom.br/2026-02-01-signal-of-awareness.en.html and https://blog.lx.oliva.nom.br/2026-01-25-compromising-encryption-keys.en.html

the secondary problem with signal is its insistence on centralization. this makes the "not being online at the same time" a problem for all its users, when their centralized servers are not online

CC: @feld@friedcheese.us @rysiek@mstdn.social