Yes, and furthermore, there's already built-in support for ledger monitors to ensure the honest and integrity of their log.
The whole point of Key Transparency is to keep the server honest. Publishing may be centralized, but verification is decentralized. This is literally a problem space I'm working in right now! https://soatok.blog/category/technology/open-source/fedivers...
> Repeat after me: The server matters. A lot. Even if you don't want it to.
The only thing the server can influence is availability:
1. Whether or not you can participate in the network to begin with (which is mostly to prevent spam, and is the only component you still need a phone number for today)
2. Deciding whether messages are delivered or not, to everyone.
Signal can't selectively censor users, they can only stop the operation of the entire service at once. Sealed Sender and zkgroup address this.
With key transparency, Signal couldn't even mislead users about which public keys belong to each user if they wanted to.
There is no other powers, besides basic availability, that the server needs to provide.
Just because you're used to technologies where the server has more power than the clients, and where some clients can continue to use OMEMO 0.3.0 in 2025 while the rest of the ecosystem is on 0.8.3, doesn't mean your experience is necessarily relevant here.
As noted elsewhere, Signal has offered reproducible builds since March 2016. If you care that much about about client security, why not check that yourself and blow the whistle if the binaries mismatch?
Thank you for your work and thanks for your immense patience answering mostly-already-addressed concerns of someone who has not bothered to even read the article. It's bad form; noble of you to answer (and hopefully useful for others / posterity).
_edit_ spent some time on your blog (turns out I've done that before - recognised style as well as furry universe / ontology; nice feeling to return). Reading reasons for disliking AES-GCM (always liked this simplicity + auth-baked-in AEAD approach as a dev/architect/user of applied crypto)...
If you see this _edit_ - do you use any specific tools to generate various sequence / flow diagrams? anything besides mermaid (+ draw.io, I somehow never got rid of using this one in times of urgent need...)? Thanks :)
Yes, and furthermore, there's already built-in support for ledger monitors to ensure the honest and integrity of their log.
The whole point of Key Transparency is to keep the server honest. Publishing may be centralized, but verification is decentralized. This is literally a problem space I'm working in right now! https://soatok.blog/category/technology/open-source/fedivers...
> Repeat after me: The server matters. A lot. Even if you don't want it to.
The only thing the server can influence is availability:
1. Whether or not you can participate in the network to begin with (which is mostly to prevent spam, and is the only component you still need a phone number for today)
2. Deciding whether messages are delivered or not, to everyone.
Signal can't selectively censor users, they can only stop the operation of the entire service at once. Sealed Sender and zkgroup address this.
With key transparency, Signal couldn't even mislead users about which public keys belong to each user if they wanted to.
There is no other powers, besides basic availability, that the server needs to provide.
Just because you're used to technologies where the server has more power than the clients, and where some clients can continue to use OMEMO 0.3.0 in 2025 while the rest of the ecosystem is on 0.8.3, doesn't mean your experience is necessarily relevant here.
As noted elsewhere, Signal has offered reproducible builds since March 2016. If you care that much about about client security, why not check that yourself and blow the whistle if the binaries mismatch?