Some predictions were super accurate (i.e. Europe to America in 8 hours), some failed (lunch in 4 pills), but, due to immense optimism of human nature, one just couldn't envision the most influencing events of XX century - the rise of totalitarianism resulting in World War II and all its disasters. Something I can't escape thinking about when reading modern predictions.
You may wish to check https://pyrus.com - they are focused on no-code end-to-end processes with very flexible (and non-bloated) workflow setup, open API, and neat mobile apps (which is a must have feature for getting timely approvals from C-level guys).
Since E2E encryption is not enabled by default in Telegram, I believe it's used by 2% of their users at most. Messages of the rest can be read by Telegram team.
> Since E2E encryption is not enabled by default in Telegram, I believe it's used by 2% of their users at most.
You are probably answering another post here. I don't think it is intentional.
> Messages of the rest can be read by Telegram team.
Well, there are a number of ways to prevent that from happening easily.
I cannot verify this, but Telegram said years ago that they solved certain problems by routing keys and messages through different datacenters in different jurisdictions.
That said: the big question is if their solutions work and if it works that way? I don't know, they seem remarkable competent at certain aspects of what they do and other times I feel they suffer from the same thing that Elon Musk sometimes suffer from where they publicly state things that sound immediately unreasonable.
But that would be meaningful criticism so probably off topic in a Telegram bashing contest ;-)
"I cannot verify this, but Telegram said years ago that they solved certain problems by routing keys and messages through different datacenters in different jurisdictions."
Firstly, there is no proof of this happening. I've been looking for the documentation and/or source code for this for more than five years now, and it's never been published.
Secondly, even IF it was happening, the server that strips the in-transit encryption has access to the plaintext, and can copy the message to anywhere it damn pleases. It can write it to "plaintext-messages.txt" for all it cares, that's like two lines of Python in the backend.
Also, the servers creating database entries must by definition have the full database encryption key in its RAM, from where privileged processes can exfiltrate it (computer organization 101).
The thing is, there isn't technology out there that allows Telegram to do what it claims as securely as it claims. If they are indeed innovating on this, why aren't they publishing their research and proving their worth?
"they seem remarkable competent at certain aspects of what they do"
Yeah, you can be great at UX design and shitty at cryptography. That's perfectly fine. The fact they won't spend money to hire competent cryptographers is the shitty part. I don't know if it's this Russian pride wrt. Nikolai being an award winning mathematician, or if they don't really give a fuck and think damage control can mend the damage that resulted from nepotism.
Well, the first time they get hacked properly shows how shit the architecture was. We can only hope people will then ask "ok where the fuck did we go wrong, again, can we switch to something that fixed this once and for all", and that by then, Signal is usable enough for their needs.
> Firstly, there is no proof of this happening. I've been looking for the documentation and/or source code for this for more than five years now, and it's never been published.
I haven't found anything more either. See also below.
> Secondly, even IF it was happening, the server that strips the in-transit encryption has access to the plaintext, and can copy the message to anywhere it damn pleases. It can write it to "plaintext-messages.txt" for all it cares, that's like two lines of Python in the backend.
Theoretically, couldn't the client send the message to one server and the keys to a different set of servers? Clients would request the encrypted messages from one server and the keys from another?
It is still not nearly as good security as proper E2E-encryption but should still be possible to set up so that a single rogue sysadmin cannot get hold of messages.
> Also, the servers creating database entries must by definition have the full database encryption key in its RAM, from where privileged processes can exfiltrate it (computer organization 101).
The thing is, there isn't technology out there that allows Telegram to do what it claims as securely as it claims. If they are indeed innovating on this, why aren't they publishing their research and proving their worth?
See above. As long as they don't do serverside search or anything this should be possible?
> "they seem remarkable competent at certain aspects of what they do"
Yeah, you can be great at UX design and shitty at cryptography. That's perfectly fine.
Definitely.
As mentioned before I prefer Signal. I actually like your answer.
We need more of these answers and less:
- X is definitely in the pocket of FSB.
- E2E or nothing!
- Use WhatsApp or nothing!
Hey, even tptacek went as far as admitting this at some point:
Theoretically, couldn't the client send the message to one server and the keys to a different set of servers? Clients would request the encrypted messages from one server and the keys from another?
That would imply client-side encrypted cloud backups, with external key management which isn't the case in Telegram, if it were it could be shown from client-side code. Also, even if that would be the case, it would just need combining key and ciphertext in once place which is again the weak link.
Also, there's no way the search would work as fast as it does now if key /ciphertexts would have to be transported via servers, and finally, since it's a single server that can request data (I have checked the destination IPs), anything of the sort is not happening.
"should still be possible to set up so that a single rogue sysadmin cannot get hold of messages."
I'm afraid that's not possible. When the message arrives to server and the outer layer that is in-transit encryption is stripped, what must remain is the plaintext message, or a message that the server can not decrypt. Such technology already exists, it's called end-to-end encryption. If there was a simpler way to protect from malicious servers, there wouldn't be a need for E2EE communication ;)
"See above. As long as they don't do serverside search or anything this should be possible?"
So no that wouldn't work in practice. Proper cryptographic design in secure messaging apps doesn't distinguish between entities on server who have access to keys. "Jack has one part of the key and Jill has another, but they will never collude or get hacked at the same time" is very bad security rationale.
"- X is definitely in the pocket of FSB."
Well, the problem here is, if the scenario is this "Telegram is secretly in the pocket of the FSB and they're giving access to every message on their server" I can't say "No way, it's all end-to-end encrypted they have nothing to give". I can say that for Signal, however, so I'd rather recommend it instead, and actually, because I can't say Telegram definitely isn't in the pocket of FSB, I don't think it should be used. I hope you understand this requirement of verifiability. If Telegram really wanted to lock themselves from user data, the would've implemented E2EE from the get go.
"E2E or nothing!"
Not sure what to make of this, I haven't heard anyone claim no encryption is better than weaker encryption. But wrt. message confidentiality, since there is no difference when it comes to service provider obtaining the plaintext copy, it's hard to not say "don't use it if it's not E2EE".
"- Use WhatsApp or nothing!"
Another complex problem that boils down to trusting WA has not changed source code after Moxie helped implement Signal Protocol. Like I said earlier, there's maybe a 1..2% chance of backdoor that allows WA to snoop on it's E2EE. So if for some reason one would have to compare these particular ones (IRL this is what we'd call a false dilemma), I'd say
1. Telegram secret messages for one-on-one chats
2. WhatsApp group messages
3. Telegram group messages
WhatsApp may have 1..2% chance of backdoor, but with Telegram I know there's a front door with 100% probability.
If we forget the false dilemma, suddenly Signal solves all of our woes wrt. cross-platform private one-on-one chats and group chats.
"Hey, even tptacek went as far as admitting this at some point:"
Let's not put his words "almost literally any secure messenger is better than email."
Firstly, that assumes he considers Telegram a secure messenger. Secondly, encrypted email has serious problems with deniability (which we'll ignore this time) and forward secrecy: in those respects Telegram's E2EE is better, sure, but E2EE email for group chats (Assuming the client knows how to reply individually to all, and to use each individual's PGP key to protect it) is again more private than Telegram's group chats.
I always took the claim of routing keys and messages in different jurisdiction to be about not writing them to storage in those jurisdiction, not about not having them in RAM.
the idea being that there can be an internal policy to shut down the server and wipe the ram but it is harder to do with drives.
I also have a question since you probably can answer: can E2E offer a similar user experience to what normal telegram chats offer?
" I always took the claim of routing keys and messages in different jurisdiction to be about not writing them to storage in those jurisdiction, not about not having them in RAM."
There's no precedent I'm aware of that if e.g. NL Telegram server has the key in its RAM but not in its disk, that it doesn't have to hand out the keys. Also the keys and/or plaintexts can just be stolen by foreign intelligence establishments. It's not just judicial means we need to be concerned about. E.g., just because it's legal in China to hack Telegram servers abroad, doesn't mean it's right, and Telegram should take this into account.
"the idea being that there can be an internal policy to shut down the server and wipe the ram but it is harder to do with drives."
This is pure speculation and it wouldn't matter because key lifting attacks would be transparent, i.e. the exploit is polished enough not to raise alarms.
"I also have a question since you probably can answer: can E2E offer a similar user experience to what normal telegram chats offer?"
Yes. Except channels and extremely large supergroups. But these two don't enjoy expectation of privacy. You can't expect something you say to a group of 10,000+ people to remain private, people consider such groups public.
Encrpytion is just math so there's also no way around the UX problem of authentication that's part of E2EE, but since that's expected of users, it's not a problem either.
Everything else, group chats with roles, synced chats, file transfers, locations, stickers... you name it, can be done over E2EE, just look at how Signal is showing each of those can be done. It's not trivial of course, but like you asked, "can it be done", yes, it can.
Does anyone know of good extension to use PGP on top of Telegram Web? So that whenever you chat with person X, if thats persons public key is saved, all messages with that person are PGP encrypted
It's surprising how Telegram successfully lured public to believe it is a secure messaging app while not providing end-to-end encryption by default.
You need to explicitly start secret chat (under More button on the contact page) to opt-in for E2EE, something you get by default in every Whatsapp chat.
We used both zeromq and its sort-of-descendant nanomsg but eventually moved to NATS because of it's approach to high availability (every node knows the topology of the whole cluster) and zero management overhead.
Some criticize NATS for the absence of message durability in the core technology, but we figured out we can drop this requirement in 95% of cases. Your microservices should be highly available anyway, so there's always a live consumer - and it's better to handle the message to it directly rather than introducing the overhead of storing a message somewhere and dealing with more-than-once delivery.
There's a bit more to that like you should let your microservices exit gracefully and finish processing consumed messages. And of course in 5% of cases, where you can't allow to lose a single message, you have to use NATS Streaming or the likes, but so far we've been greatly impressed by NATS for high load.
One practical reason we chose Nats over Kafka was that Nats doesn't need zookeeper for HA.
Nats doesn't provide message durability too, luckily it's not required for 95% of our use cases. Also, having NATS already implemented it's a natural move to use NATS Streaming for durability rather than introducing a completely new technology to your stack.
NATS by itself is designed to be more of an always-on style queuing system (the term they use is "dial tone") but doesn't handle node failures by itself. If you're looking for a Kafka-flavored NATS, there's a new release I saw recently called LiftBridge that adds some durability to the NATS protocol.
It's insightful to learn that in their guide on pricing Sequoia cites Phil Libin, then-CEO of Sequoia-backed Evernote, who was later kicked out exactly because the company struggled to find the right pricing model.
While it is easy to blame Boeing these days, I suspect we have survivorship bias here. Dig into Airbus software and all sorts of similar scary bugs will pop up. For instance, one may remember inconsistencies between airspeed measurements that resulted in the loss of AF 447 on June 1, 2009. Overall, it's great that at least some airliner's closed software finally gets more eyes looking at it.
Frozen pitot tubes causing an airspeed disagree is something we train for. The issue there isn't software, it's mechanical, and what the Airbus did is exactly what it's supposed to do according to the manual.
The problem there was the junior co-pilot responding all wrong and the other pilot not noticing because Airbus sticks don't move together. The captain woke up, came to check and realized what was wrong but did so too late to fix it.
Agree, though the investigators also pointed to the lack of a clear display of the airspeed inconsistencies even though the computers had identified them. This sounds more like a UX problem rather than a bug, but still the software issue in the edge case.
I seem to recall Airbus having different engineering teams across EU using different versions of the CAD tool and then when they went to build the plane the wires were too short because one version of the CAD tool accounted for the radius of wires turning a corner while the other didn't.
Boeing had an approach to this issue: Your either running the correct version of the CAD software, or you can't check in designs. This also meant that every time it was updated there was a rush to get engineers who's update did not work back up and working. Fortunately those were a small minority and it was usually disk space issues.
The measurements would have been the same in both cases: therefore it would have been a) designed correctly and implemented correctly, or b) designed incorrectly, but caught in the design phase, looping back into a). This way, you get c) designed correctly, but implemented incorrectly or d) designed incorrectly and the design implemented as specified, in both cases leading to an unworkable implementation.
It is certain that under close scrutiny one can find bugs as well in Airbus airplanes. Bugs are inherent to software production, all processes are just there to minimizes the risks posed by critical bugs.
However, as airbus released the first fly by wire airliner (a320), they have more experience in software over boeing. Boeing was always afraid to give too much power to the software, a boeing plane has more mechanical backup than an airbus.
I sincerely hope that they are not fucking around by following the agile trend from the sw industry, and instead stay focused on old and proven engineering development practices.
I must say that this whole boeing show makes me scared to hop in a boeing, and is another reason why i will now seek flight in a a320 instead of a 737. The first reason is simply comfort, the 737 cabin size is really too small.
Edit : the a350 had a bug where the pilots needed to switch off the plane every 149h, and recently they discovered a bug in the a220 P&W engine (not airbus developped) leading to engine shuting down in flight.
They also found a kind of mcas like bug the a321neo, but I think it happens in extreme manoeuver which can be only replicated in simulators
A Boeing with an engine fire will pop up a dialog saying “flight computer detected a possible engine fire, would you like to shutdown?”. An Airbus with an engine fire will pop a dialog saying “flight computer detected an engine fire, shutting down engines”.
The joke being Boeing pilots have a chance of saving the plane in the event it’s not an engine fire, Airbus will just do what it thinks is best and let the pilot sort out the aftermath. MCAS changed all that
