I will definitely try this because I have trouble with all other voice chat services including Skype, WhatsApp and Hangouts. Often one of those three will work but not always.
But the most annoying problem with any internet voice chat is not so much the quality but the latency. Landline phones have noticeably lower voice quality but one can still enjoy a conversation perfectly well. High latency, on the other hand, absolutely ruins the experience.
I always see these services talking about "crystal clear quality", but never latency, which is a shame. Maybe there is simply nothing they can do about it. I've noticed latency get worse and worse on the Internet since I started using it in the 90s and nobody seems to talk about it.
There are so many more sources of latency on every layer on the modern internet and it's a damn shame. I remember when interleaving got enabled on my ADSL and latency to everything doubled overnight. Then there are NATs, and all kinds of filtering shit that ISPs insist on. Sigh...
>I always see these services talking about "crystal clear quality", but never latency, which is a shame. Maybe there is simply nothing they can do about it. I've noticed latency get worse and worse on the Internet since I started using it in the 90s and nobody seems to talk about it.
Well, the first problem at home is likely your wireless. Live in an apartment and you can pick up 30 other routers in your wifi search. Chances are you're going to have latency and re-transmit issues to your AP.
Second problem, your router. Most of them suck. If you're lucky and yours doesn't setup QoS/shaping rules. I use fd_codel on mine to attempt to minimize the amount of buffer bloat that occurs. In the race to make your internet 'fast' huge buffers act like buckets for data, which is really bad if you want your data instantly. And if you search buffer bloat you'll see a lot of people talk about it, very few ISPs want to do anything about it though.
Lastly, the one you can't do anything about is the path that your data takes to the remote user. If it is overloaded or has capacity induced latency there isn't much you can do, other than change ISPs maybe.
Having used Drayteks, and supported them, and indeed having owned one (company supplied for site-to-site VPN) I wouldn't recommend them. The feature set is great, the router is not.
Fair enough. This is the problem with consumer gear, it's all so variable. For me, Draytek have been the only vaguely consistent vendor over the years. I've had countless issues with T-link, Asus and Netgear routers.
That's: https://lede-project.org or:“Linux Embedded Development Environment” - the new project born from OpenWRT. I've used it with some old d-link routers, and I'm quite happy.
The documentation is still not stellar, but it has gotten better, and the configuration more consistent. It's quite easy to set up ssh-access with a key, and simply get a copy of configuration files with scp - ready to set up identical configurations on new router installs.
The Opus codec ( http://opus-codec.org/comparison/ ) can enable very low latency audio. 26.5 ms algorithmic delay (the time it takes to go through the algorithm) by default, but can be set to a very impressive 5ms. Digital audio can't achieve the near no-latency analog POTS has, but it can get pretty darn close e.g. if Opus is used in the very low latency mode. I believe Mumble and maybe TeamSpeak let you choose the Opus latency. I know some other apps like WhatsApp, Wire, and Signal use Opus as well. I don't know what settings they use though.
Another problem is cell phones add ~150ms latency (pre VoLTE) and people that route calls through Google Voice adds an additional 150ms+ latency on top. If you ever talk to someone on a cell phone on google voice, it sounds like they're calling from the moon.
150ms is about the human limit before turn-taking and talking over each other becomes an annoyance. That's why cell-to-landline conversations (150ms one way) were tolerable, but cell-to-cell (300ms one way) conversations are abysmal. And that's all in the same area code. Once you add long distance, it gets worse.
Just fyi, POTS is digital up until the very last mile. While the network is digital, it uses time multiplexed serial PCM streams under the hood. Aside from the delay imposed by fiber transmission at the trunk level (~40 milliseconds from one side of the US to the next. If you're using a long distance network that packetizes the connection or sends a call on some weird route, that can certainly increase), the g.711 encoding delay should be fixed at 0.125 milliseconds.
g.711 has such low latency because it doesn't take advantage of inter-sample redundancy in any way whatsoever - it's just raw 8-bit samples at 8 ksps with a compander on either end (traditionally on the analog side of the DAC and ADC).
> But the most annoying problem with any internet voice chat is not so much the quality but the latency. Landline phones have noticeably lower voice quality but one can still enjoy a conversation perfectly well. High latency, on the other hand, absolutely ruins the experience.
Maybe this is because traditional communications were built by people working exclusively in that field - and they eventually became true experts, with a deep understanding of the real issues.
Nowadays Internet chat services are cobbled together by happy-go-lucky engineers who, prior to this, maybe did an ads firehose on Twitter, and after this project will perhaps move on to work on Facebook games or whatever. Smart people to be sure, but their understanding of the field is necessarily superficial.
The fast rate of change in this industry explains many of the things that are ailing it currently.
> Nowadays Internet chat services are cobbled together by happy-go-lucky engineers who, prior to this, maybe did an ads firehose on Twitter,
Skype has been around for 13 years. It isn't a young startup full of ex-node.js programmers.
WhatsApp also has some excellent infrastructure built on top of Erlang which has decades of experience and refinement of heavy-duty telecom usage baked into the framework.
If anything the experience of previous development trickles down and younger engineers benefit from that knowledge. But I'm not sure I buy the idea that you can only build great systems if you've only been doing that one category for your whole career.
The rate of jobs changes faster and in front-end development the pace of toolset changes pretty fast. But even in front-end development it's still the same languages. usually just the tools are the trendy part. And if it's switching languages every 5-7 yrs that knowledge of languages is transferable. I've only benefited as a programmer from exposure to many other languages (and projects).
Regardless, the hardcore backend guys you get to build this type of infrastructure isn't the same hipster front-end devs that Twitter hired in the early years to build out a consumer product. Consumer is very different than building out telecom infrastructure in Erlang/C++.
> I've noticed latency get worse and worse on the Internet since I started using it in the 90s and nobody seems to talk about it.
You're remembering incorrectly then. Dialup latency was in the range of hundreds of ms. Early high speed internet access also had higher latency than modern connections.
If you have latency problems it's likely a problem with your hardware.
Latency for a 56k modem was 180ms. Latency for a voice call on the same line was _much_ smaller. AFAICT, latency from my games console television to my TV is much higher...
Cable tends to have a higher latency than aDSL. I don't know if that's the tech or just over-subscription on cables part. The trade off is in the bandwidth allowed so people mostly gave up that feature in exchange for enough bandwidth to do other stuff.
Unless you're hitting an IP node that transcodes to g.729 or something, landline phones should sound pretty good; the mu-law codec uses companded 8-bit PCM that roughly equates to about 14-bit linear in terms of precision. If you're sending a lot of very low frequencies (most phones and line cards have a pass filter in them to remove stuff below ~60-100 hertz, so while the network is very capable of sending it, it doesn't always in practice), you'll start to hear companding noise, but it's rarely the case that it gets loud enough to cause an issue.
As for the sample rate, 8 khz is a bit low, but you can make it sound significantly better with a bit of equalization; usually turning down frequencies near 1 khz a little goes a long way. Sometimes too, it doesn't hurt to gently (and I stress, gently) reduce frequencies near ~300 hertz if it sounds too muffled.
The best phone voice quality is still ISDN. Digital all the way to the handset, and rigidly clocked with fixed delay. Switzerland has ISDN phones, and the voice quality is impressive.
ISDN was 64kbps pet channel though - and to my knowledge did not use a wideband voice codec by default (or at least didn't mandate all ISDN receivers support wideband audio).
Lots of people who had ISDN kit plugged their old POTS phones into their TAs anyway.
ISDN is actually used quite a bit in niche markets in the states. For studios, typically you'll see a couple B-channels bonded to give someone 128K MP3 or AAC. At a bare minimum, 64 kbps/16khz g.722 is used. I worked in a newsroom a few years ago where I frequently had to record a weather guy from a distant area who used this.
I think it sounded good because it was clean 64K end-to-end. No trickery with transcoding a bunch of times along the way so someone could save a nanopenny.
Can relate, I remember enjoying more talking with friends in TeamSpeak than with my girlfriend via skype/hangouts/facebook call... now with a discord server, talking with friends is so much easier, but quality is not as good as TS... but still convenience beats quality, and the loss is not that bad.
I've been using TS recently on a consulting project, after my client suggested we use it, due to issues sometimes with Skype. Seems good so far, though not used it for many days yet. Needs a server though. The software is free for a basic version. I think it supports multiple people on the call, though we haven't tried that yet. And seems to have many features overall, not tried them out yet, but will try some over time.
Have you tried Amazon Chime? We are ridiculously aware of the latency issue in high quality voip. We do not at the moment support user generated keys the way Telegram does but we do use TLS/DTLS encryption end to end for our VOIP streams.
> We are ridiculously aware of the latency issue in high quality voip. We do not at the moment support user generated keys the way Telegram does but we do use TLS/DTLS encryption end to end for our VOIP streams.
Any plans to make this available to developers as a service via AWS?
Multiple data frames are interleaved and transmitted together. Good for error tolerance, since bursty noise doesn't wipe out a complete frame, but small parts of multiple ones, which then can individually be fixed by their Reed-Solomon error correction codes. But it adds latency, since the sender has to collect data from multiple frames to combine, and the receiver has to receive the entire block before it can be decoded, instead of transmitting each frame as it arrives.
"
Each time you make a Voice Call on Telegram, a neural network learns from your and your device‘s feedback (naturally, it doesn’t have access to the contents of the conversation, it has only technical information such as network speed, ping times, packet loss percentage, etc.). The machine optimizes dozens of parameters based on this input, improving the quality of future calls on the given device and network."
Is it just me or does this sound like serious bullshit? Unless you have some hard evidence of course...
The 'neural network' is probably an SVM or logistic regression. There's nothing special that a neural network can learn with high-level features like network speed, ping times, etc.
In fact, it's probably just a TCP-like algorithm, i.e. decrease rate of packet sending if not getting ACKs back. One day, Intel might come out and say their microprocessors are AI-powered, since it has branch prediction.
"Each time you make a Voice Call on Telegram, a neural network learns from your and your device‘s feedback (naturally, it doesn’t have access to the contents of the conversation, it has only technical information such as network speed, ping times, packet loss percentage, etc.). The machine optimizes dozens of parameters based on this input, improving the quality of future calls on the given device and network."
I have the feeling that's there soley for the "AI-Powered" hype train benefit. Versus actually being used as a genuine feedback loop to improve the service.
Logs of speed, ping times, packet loss, would likely be more useful in good old, non-AI reports...to identify regional issues, peering opportunities, etc.
I don't think you need AI for voip calls that upgrade/degrade quality based on network health.
It's fundamentally very similar to the sorts of issues you end up with if you compress then encrypt. If the attacker can make some educated guesses about the plaintext prior to the compression, the compression ratio can be a very powerful tool in their arsenal.
On the other hand, if you could do it, you'd probably have invented a convoluted speech-to-text (where text is a index into a dictionary of words). Note that you would also likely lose things like inflection, voice, accent etc - so while it might work as a texting system with voice input - it would be a poor substitute for voice chat..
This is HN. A link to an example would be appreciated.
Edit:
To clarify, I work with audio codecs too, and can't really
think of parameters (other than the compression level?)
that would make much sense to adjust on the fly.
If "AI" is used for more than just a buzzword here, then
I imagine the answer must be quite interesting.
They probably adjust the incoming / outgoing buffer sizes (and therefore the audio delay, since it's live) to account for packet loss.
They might also prioritize traffic depending on how full your buffers are.
I can only assume Youtube and Netflix do similar parameter tweaks to optimize their video delivery based on the connection (totally filling the buffer to a max size all the time would waste bandwidth, but if the client has lots of packet loss they need a larger safety net).
> Party A will generate a shared key with B — or whoever pretends to be B — without having a second chance to change its exponent a depending on the value g_b received from the other side; and the impostor will not have a chance to adapt his value of b depending on g_a, because it has to commit to a value of g_b before learning g_a.
> The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct visualization in their attack, which means that using just over 33 bits of entropy represented by four emoji in the visualization is enough to make a successful attack highly improbable.
I like it. I tried to explain it in slightly simpler terms to some friends in a group chat like this:
> reading about the emoticon generation thingy, it's actually worth a read
> they use a DH KEX[1], but wrapped with something which is interesting. Client A generates a, client B generates b, and g seems to be an already-exchanged finite group generator. That's all standard.
[1] diffie-hellman key exchange
> now before A sends g^a to B, it will send hash(g^a) to B. B responds as normal (with g^b) to which A will respond with what it normally would send first: g^a.
> after receiving g^a, B can check whether the initially received hash(g^a) matches. This means that A can't brute force a specific value of a, so it doesn't matter that it's only 33 bits of entropy in that emoticon thingy. Any brute forcing will change the hash (unless you collide, iirc, sha256) and B will go "dude wtf" and kill the connection
I haven't personally reviewed it, but based on their previous inability to make principled cryptographic choices and resistance to critical feedback from actual cryptographers… I'm skeptical.
tldr: First message from TelegramApp has some marketing copy ("acm winner phds") but not horrible. The TelegramApp user remains calm/careful and mostly polite in every message after that. There are only a few cases of sideways slapping and they come from HN users. Despite this the conversation between TelegramApp and HN users remain informative debate and discussion.
Being cordial and polite on Hacker News wasn't my concern. My concern is their repeated dismissal of feedback from experienced cryptographers.
Cryptographers can't seem to make sense of a lot of their design decisions in the MTProto protocol. Their response to criticism has mostly been in the form of: if you can't demonstrate a break directly, then we don't care.
Given how fragile cryptography can be, this is an absurdly irresponsible way to maintain a cryptosystem. Modern cryptographic designs try to be very principled, and steps are taken to prevent any kind of theoretical weakness, even if we don't know how to break it in practice. This is because cryptographic breaks only ever get stronger — never weaker.
As an example, TLS 1.0 using doing authentication for CBC modes with MAC-then-Encrypt was known to be weak, but it was only years later when researchers were able to turn this into a plaintext-leaking break. And MTProto is absolutely littered with unconventional or known-weak constructs, giving a lot of potential levers attackers can use to break it.
You might argue that it's fine for this to be the case, as long as they respond quickly to protocol breaks. The problem is, the good guys only learned how to break TLS 1.0 CBC when the attack was published. Did the NSA/CIA/GRU/FSB know about these attacks before we did? There's no way to know. But if it had conservatively chosen an Encrypt-then-MAC scheme to begin with, such an attack would have never been possible in the first place.
That's not to throw the TLS 1.0 authors under the bus here. The weaknesses of that type of scheme were yet to be widely known. In the case of MTProto, weaknesses in their use of certain constructs are widely known, and they don't seem o care.
I read through the linked thread in my previous post and I think it gives a good idea of the rift between the in-house-HN-cryptographers and those at Telegram. One will find the exact same disconnect between cryptographers that worked under heavy computational constraints, and those that have not. For example, in the Satellite TV industry.
The Telegram designers built a protocol with anticipation of some constraints. But rather than debate the plausability of the percieved constraints, the HN-crowd just dug into whatever they already knew and threw in a lot of snark in their response to close the door.
> Their response to criticism has mostly been in the form of: if you can't demonstrate a break directly, then we don't care.
I haven't seen that. I went looking for it. If you have the patience and time please dig up a link or quote.
> That's not to throw the TLS 1.0 authors under the bus here. The weaknesses of that type of scheme were yet to be widely known. In the case of MTProto, weaknesses in their use of certain constructs are widely known, and they don't seem o care.
I did see a good bit of discussion about the feasability of some of the weakness pointed out. They responded in a way that seemed to indicate they fully understood the issue but "chose" to take the risk. I'm not sure this means "they don't care". Perhaps it does. But this is where I started to see that the rift here was really about the perception of constraints, not lack of knowledge or, in my opinion, lack of care.
By the way, it is also worth noting that Nikolai Durov, designer of MTProto, is completely absent from any public discussions of that protocol. Doesn't like talking to the plebs, I suppose.
I've managed to setup Telegram for most of my (non-technical) family - wife, siblings, mother (she doesn't even have a smart phone and just uses Telegram as a message client on her desktop. It's a very convenient way to share family related pictures).
Voice calls are an excellent addition. If these could now also be extended to video calls, I could likely ditch Skype forever.
A client of mine once explicitly asked to communicate via Wire [1] which is pretty similar to Skype but E2E encrypted.
It was launched by a Skype co-founder, is easy to use and has a pleasant interface. And it's open source.
I can't really tell if the product really does what it's advertising, perhaps someone with more expertise could chime in on that.
I got stuck on it and I'm considering ditching Skype altogether for it. Perhaps not the solution you were looking for but interesting nonetheless!
It's open source indeed [1] and was recently audited for the quality of the crypto protocol implementation [2]. Not sure what questions you specifically have but I'm happy to answer as I'm part of the team.
I used it for a year with friends and family. I have never in my life experienced a buggier app on Android. My friends and family said the same about it. The seem to focus on bringing new features (like an alien voice FX feature) when they should try to fix the basics first.
Most of my family is on iPhone's, while I'm using Android. I tried using Wire as a substitute for Facetime (my 3 year old doesn't consider it a real phone call unless there's video), but it was way too buggy and people would just get annoyed.
Signal's new video chat, however, has worked really well after it got out of beta. There aren't many apps that manage to do video calls well between Android and iPhone, I'm a bit surprised that that feature hasn't gotten more attention.
Telegram has been around for three years now. I wouldn't hold my breath for open source servers/ability to run your own. That's not their business model.
I think at this point it's quite clear they are not ever going to do that. They actually stopped publishing their client source code and they aren't responding to any questions about that.
> Definitely, updated source codes will be online later today.
And the Desktop client[1] is kept very up to date. My biggest complaint is that they have stopped updating the API documentation [2] which has lead me to become a rather lukewarm telegram developer (though I still have a few projects I am work with)
First check you're running the last Telegram version, that's 2.3.36.2
Second, have you tried to delete the cache (.cache/com.ubuntu.telegram)? That will erase your secret chats too, so you can make a copy before deleting it.
Yup, latest version. I tried clearing the cache and no change. Since I was in console, I just checked syslog and I'm getting a dbus DENIED. I'll poke at it when I have more time, but I wonder if they need to fix up their apparmor perms.
Curious as to why your getting a different result though.
EDIT: I'd also be curious as to your opinion of Touch in general?
My opinion: I love it. I'm not a huge fan of Unity, or Ubuntu, and it's definitely in the beta stage. I like that most of the problems that I have were solvable on my own via shell-script or whatever hacks I come up with.
They've rolled out a new version of video/voice calls this month[1] which supposedly improved the quality quite a bit. I haven't personally tried it yet, though.
They are one of the newer kids on the block. Open sourced in March 2016, End to End encrypted (everything and by default) since June 2016 (or the other way around). Supports chats, calls, video calls, file transfers and multiple devices (including Linux, though Electron...).
The emoji out of band authentication is cool, but probably annoying. You have to read those emoji by voice to the other end, so they can check them. That could be a pain if the emoji are chosen randomly from the 2600 available emoji.
The idea comes from the STU-3 secure phone, where there was a 2-digit number display to be read back by voice. It's one of the ways to detect a man-in-the-middle attack. If there's a MITM, the crypto bits sent and received are different, because the MITM is re-encrypting, and this is detectable if you have some out of band channel for comparing them. A MITM would thus have to be able to fake the voice of the other party.
With techniques like this, you can make an MITM work arbitrarily hard to maintain the illusion that it's the other party. I've proposed some ways to do this for web pages.
They're sitting on troves of data. Extremely few use the E2E encrypted "secure chat" feature (mainly because it isn't default, but also because it doesn't sync between devices) and all the chat logs and data are stored on their servers (and are readable by Telegram). They also store your address book on their servers.
I'm sure they will find ways monetize this. Data is the "new gold", as they say[1]...
And what in the world makes you think that a company run by a russian nationalist[1] offering a free service with a million dollar bill will stick by their word (which, in this case is literally a single word)? The naivety of people in this post Snowden world is striking to me.
Are you really serious? This is a post snowden society.
> An FAQ isn't binding.
Probably not, but please beware that this service is not subject to US law, but the laws of the Russian Federation.
> What does their TOS say?
TOS are subject to change, right? And even if it wasn't, do you really think the TOS will stop a company run by a russian nationalist[1] offering a free service with a million dollar bill will stick by their word (which, in this case is literally a single word)?
Telegram is losing millions each year, paid by Pavel Durov, its founder.
"If you look at Telegram today, every month it burns over $1 million. It might seem that it’s just going nowhere, but if you want to come up with business model, you need to get to a decent size first. We have 62 million users at the moment, which is enough userbase to attract third-party developers to create products on top of your platform. You can’t do that from day one. It’s difficult."
Isn't this just hoping that products come along that use your platform and that people are willing to pay for that? Doesn't seem a good strategy to my limited understanding.
Also, experience has taught that users are fickle and that products that are free that transition to paid products quickly lose their users.
I read at some point that they were betting on "Messaging as a platform", eventually they may introduce paid services, apps, paid bots, company features etc.
snapchat covered a new market of communications and captured almost the entire young adult market. also it's already monetized. not sure telegram can compare atm.
I tried https://appear.in recently for a short call with a student and it worked well. A friend and fellow freelancer also uses it, he said. One good point about it is if you need to do a quick ad-hoc call - it is browser-based (probably uses WebRTC), and also does not need to you create an account or sign in. Plan to try it more in future, as well as TeamSpeak which I also mentioned in this thread. I had installed Wire too, both on PC and Android phone, but not tried it yet with anyone.
Closed source, not end-to-end encrypted by default, end-to-end only device to device (so I can't swap seamlessly from a desktop to a mobile session).
Not even the protocoll is open, so I am bound to their clients.
Sadly it was the only nice alternative when the snowden stuff was published. That means those of my peers who made it away from skype/fb/whatsapp are now on telegram.
Most seamless end-to-end encrypted solution I've come across. And it's still in beta. Every piece is open source (I'm running my own server), it's federated, supports history sync as a first-citizen feature, individual read receipts for group messages. The UX is not as polished as Telegram, but it's improving rapidly and is more than usable as a daily driver.
iMessage has end to end encryption and supports multiple devices. Each device uses its own keypair and when a message is sent, it is sent encrypted for each of the recipient's devices.
iMessage does not allow for any out-of-band key verification. It's correct that that Apple (and anyone compromising them) is in a position to change the recipient's key or add new ones without the sender noticing anything's going on. I think iMessage limits this to new messages. (I believe syncing is done through iCloud, which doesn't use E2E-crypto but is optional.)
It would still be possible to implement this in a secure way (including out-of-band key verification) by having the "original" key (the one you've compared out-of-band) sign keys for new devices and have the server deliver that signature (which the sender can then verify). I don't know if there are any implementations of this.
Wire? I used it for a year with friends and family. I have never in my life experienced a buggier app on Android. My friends and family said the same about it.
They seem to focus on bringing new features (like an alien voice FX feature) when they should try to fix the basics first.
The worst thing that happened to me was that UI told me I was in a chat with Alice, but I soon realized I was actually chatting with Bob. So much for E2E...
Now we use https://riot.im. I'm kind of surprised a federated solution offers a decent UX and is less buggy.
Never experienced anything like that on Riot. I mostly call from Android to other Android and iOS phones though.
I'd say we had a 40% chance of actually connecting a call with Wire. Suddenly there was an update to the app and calling didn't work _at all_ until the next update came (this happened more than once).
A close relative finally gave up and yelled something along the lines of "who the f* uses this POS app", and I couldn't really argue. :)
e2e on Riot/Matrix is in beta. I've had some experiences with someone else in a group chat only being able to read messages on one of their devices, and this is apparently not uncommon.
I'm a firm believer that Matrix is the future. But right now I wouldn't recommend it to anyone that isn't an early adopter.
We're not aware of any crashes at all on Riot/Desktop (especially as it's an electron app, so crashes will be due to chromium bugs). Please can you make sure it's filed on https://github.com/vector-im/riot-web/issues? thanks!
How come https://riot.im (Matrix) manages to sync between devices AND have E2E, while also being federated?
That's not what you get when you have a secure system, that's what you get when you design a system that can collect (and possibly monetize) the data of millions of users.
I believe that making sync work with E2E bring either security issues or more burden on the user; I would like them in telegram, but I also like the "if you send this message you exactly the device it go to, not an old laptop i forgot in the office, just my phone". it is meant to be secure on a device level.
That's not what I meant. Yes you can have sync and E2E. With different trade-offs.
Telegram is secure from device to device, not from account to account. If I send you a secure message from my iPad I don't have to worry about the web session I opened a week ago on someone else laptop.
Signal and WhatsApp both support multi-device encrypted chats. Signal is better than WhatsApp in this respect as your primary device doesn't need to be online for it to work.
Signal multi-device support is very limited. Doesn't support multiple mobile devices. Primary device must be a phone, all others must be desktop computers with Chrome.
How come https://riot.im (Matrix) manages to sync between devices AND have E2E, while also being federated? How come I can use both WhatsApp and Signal on both my computer and phone (and they stay in sync)?
It looks like in [1] that each device registered to a user has a device_key and when an encrypted message is sent, they user's public devices keys are requested and the message is encrypted for each device. New devices can't see old messages.
The message isn't encrypted for each device; the message is encrypted once for the room, as part of a 'session' of messages - and then the key data for that session is shared with the devices who are allowed to read it. Thus you can share old session key data with other devices if you want, meaning that new devices /can/ see old messages, although we're still working through the UX for that. (Currently the only way to do it is by import/export session key data in settings and transferring it between devices).
Thanks—so there's another layer of encryption over the ever changing (Megolm) key that encrypts the room, if I understand this. Looks like I simplified too much.
Sort of. Just to clerify: the first layer (Olm) provides a secure channel between pairs of devices, used mainly to share Megolm encryption state between them.
The second layer (Megolm) encrypts each sent message once per room, using a ratchet described by session key data. The session key data is shared 1:1 between the appropriate devices (past and future) over Olm.
Most people who I know use Telegram(me included) use it because it's frankly the nicest(fast, looks good) Messenger out there, not because of its security features. Personally I don't use the secret chat functionality; I would use Signal if I wanted to communicate securely.
As I already said, if I was concerned about intel agencies capturing my messages I'd use proper OSS encryption via Signal, not Telegram.
There simply are situations where I do not care whether my messages are encrypted or not, in which case I use the app that works the best for me, which in this case is Telegram.
They had their chance to win my confidence. When Telegram was released, many people said "this looks weird in so many ways. You should really dump that and rewrite it to rely on well-understood primitives" to which the telegram devs answered rather mockingly and started a bullshit crypto contest.
6 months later, a russian guy showed that the server could MITM every newly started or renegotiated secret chat.
Sure, they manned up to their promises and gave him something like $80k, but it is a rather telling story about how good they are at crypto.
No app wil ever accomplish consistent good voice quality over the internet. Ever. For that it's too much of an unreliable network. You may try some calls over Signal, think Hey! This works well! until you hit a moment where the route between endpoints is flaky, attribute it to Signal while using another app for that same call at that particular point in time would have given the same result.
Only when QoS will be honored by all internet routers will we reach something that is consistently reliable.
The NN approach sounds interesting, but there are no technical details and it might be hype-based marketing.
Is anyone familiar with solid published work on applying ML/AI to optimize network control (or, as done here, optimize application parameters depending on network conditions).
Funnily enough, 10 years ago as a required entry step before being able to do a thesis I scribbled something[0] about distributed components with probes (some automatic, some with user feedback exactly as suggested here) and knobs driven by some fuzzy logic feedback loop, to be e.g applied to codecs and buffer size in an A/V streaming scenario† (possibly bidirectional). Concluded by saying you could get better, self-improving results by using genetic algorithms and/or AI such as NN. Was basically laughed at during defense and dismissed as being way too sci-fi. Got sick of such constant condescending attitudes and dumped research, pursuing my career as a software engineer. Had I pursued I could have been the author on such a paper you're looking for! Pretty sure I could have patented the shit out of this anyway but that's not how I roll regarding software patents. Now I lost the LaTeX source and Java code as well as the resulting PDF, and can't even download the thing as a memento since it's behind some stupid paywall.
† turned out MS launched instant play adaptative 1080p streaming some years later on Xbox 360, which was exactly that.
I tried to use it around the end of 2016 to chat with friends and it was nearly impossible to use. We would try to add a contact but the other person would not appear online, despite having the app open in front of us.
Messages would frequently not be delivered, or take exceedingly long times to be delivered (hours). Notifications of a new message were also quite hit and miss.
Overall I liked the functionality of Wire, but the reliability was terribad.
> Thanks to this modification, it becomes possible to prevent eavesdropping (MitM attacks on DH) with a probability of more than 0.9999999999 by using just over 33 bits of entropy in the visualization. These bits are presented to the users in the form of four emoticons. We have selected a pool of 333 emoji that all look quite different from one another and can be easily described in simple words in any language.
That would be low if we were considering a long-term key. It seems fine for a one-shot authentication token? Eve is going to have to MitM a lot of calls before she guesses this token correctly.
I think a while ago someone on HN suggested emoji as a joke as a more information-dense and internationalized alternative to numeric or alphanumeric verification codes. I don't know about security, but if this uses all 1,088 emoji from Unicode 9.0, then four emoji have about 40 bits of information.
My problem with Telegram is I want to use it but they wont let me. I use a budget phone service (freedompop) which apparently is technically voip, but I did not know until I tried to register for Telegram with it. They refuse to send me text verification. Wont work with my google voice number either. WhatsApp does not have this problem. And what if I want to use Telegram on desktop only? Why do I need to verify a phone number?
I have the same problem with Project Fi. Every time I try to register they claim my number is a 'voip' number. Duh! Pretty much all numbers are 'voip' at this point.
It worked with my Google Voice number just now. Could they have changed the policy? I did sign up with my iPad (with cell service) first then iPhone, so it was probably more open to not using the device's phone number.
The UI for trimming and setting the quality of sent videos is really neat. It's still annoyingly hard in 2017 to send videos from one mobile to another without needing to completely trash the quality via MMS or upload an often-gigantic file (captured in 1080p or higher) to an intermediary like YouTube or Facebook (and then wait for backend processing).
This is awesome.. I have been trying to video chat with somebody more overseas. Whatsapp video, facebook video, skype, seems like the only thing that works for us right now is Duo.
Bad thing: this tech is trapped in Telegram which is quite political of an app. I wish they'd break it out into something like duo.
Very good. Great even.
But there is a problem. Whatsapp has already won the chat/calls app war. Watch it grow massivly in the next year, i promise.
Mostly due to incompetence of MS and Google.
To me Whatsapp is terrible. I can only use it on Mobile in any meaningful way, so it's actually worse than SMS for me. Eg, i get a better UX of seamless multi-device SMS via Hangouts, than i do with Whatsapp.
Frequently i get kicked off of Whatsapp because my phone has been idle for too long. Frequently my messages are out of order between the web client and the android client. Semi-frequently Whatsapp hangs when sending messages, sometimes dropping them (i assume due to my phone going idle).
I wouldn't recommend anyone to Whatsapp.. for UX, at least.
Line is so dominant in Japan,Taiwan,Thailand, and HongKong and kept themselves independent and hugely profitable. Kakao Talk in Korea. WeChat in China. Even in the US its going to be all SnapChat soon. Whatsapp is way way behind in features it is prime for disruption. Why would Whatsapp have huge growth waiting for it? What's their particular plan?
I happened to be reading a comparison of Telegram and Whatsapp this morning [1]. I've never used Whatsapp, is it really this bad or is the reviewer clearly a massive Telegram fanboy/girl?
The same goes for Telegram. The android client hasn't seen any updates to it's github repo since sep 2016.
And, it is quite easy to verify that WhatsApp's encryption is doing what we think. A friend of mine managed to reverse engineer their protocol in 2012 in less than 24 hours, by himself. And there is quite a big chunk of the computer security market that would disagree with the claim that something has to be open source to be verifiably secure.
No it's not. The fruit is: use a sideloaded Signal which you built yourself if you really need to be secure. If you're not, Signal is still better than Telegram or Whatsapp.
Well, there is some truth to it, but as a user of both I prefer whatsapp since:
1. most of the features that whatsapp lack are features I find annoying in Telegram.
2. Whatsapp is encrypted by default, which Telegram is not. I don't think I have ever used a secret chat, despite having oven 50 people with whom I regularly talk to over Telegram.
The client being open source is somewhat of a stretch. They have released many new versions, yet the github repo hasn't been updated in 7 months.
I've read the list, and although I have faith in its veracity (except for the "value" column) and Telegram appears to have a bunch of extra features, I'm sticking with WhatsApp. They both have the features I need.
Note that they're both listed in the table as having "End-to-end encrypted chats" (value: "medium"?!)
There are a few factual errors in the list: The Telegram clients seem to be open source, but the server is proprietary. WhatsApp does have a native client for a few platforms; nobody knows about it because everyone just uses WhatsApp Web. WhatsApp has animated GIFs.
For an independent and serious comparison check https://www.securemessagingapps.com that focuses mostly on the security/privacy aspects of various messengers.
In a world full of bloated Electron HTML5 / JS "desktop apps", I'm very happy to see Telegram on Windows is a native app (Qt). It feels so incredibly responsive compared to everything else.
The funny thing is that Qt apps used to be derided for bloat (15MB of DLLs! 15MB!) but the rise of Electron has made Qt seem featherweight by comparison.
I've been involved in a project that went from standard Win32 controls to Qt, and while I was very much against Qt at the time (such bloat!), I can't deny how easy it has made cross platform UI work. With many apps being written in HTML/JS, a C++ Qt framework is still magnitudes faster than a JS interpreter.
I have zero experience with Qt but have heard that it has problems with High DPI presentations. Now It seems that they did something in that regard in Qt 5.6, but do you have anything to say or an idea about the maturity of it?
Qt classic (C++) apps run flawlessly on my 4K desktop (150% scale in Windows).
QML/QtQuick apps only support integer scaling for whatever ridiculous reason ("fuck your monitor we need to be pixel perfect" or whatever) so they're either tiny or huge.
Yeah, I remember years ago when I was pondering writing a desktop app in Python and thinking "Python? It would be so bloated!", and nowadays nobody gives a shit about being able to load more than four programs at once.
Life's a little different now than in the old XP days. Disk space and ram aren't as limiting as before and the slow redraw times of qt and other cross-platform libraries have been taken care of by GPU hardware acceleration, faster ram, and faster CPUs.
These complaints were valid back then and our opinions didn't change because of things like Electron, as much as our hardware is so much more powerful. I remember dreading running Java desktop apps and now I can barely see the difference between them and native win32 apps. Heck, running an app on a virtualized OS on top of my native OS is often fairly performant nowadays.
They have a beautiful native macOS app as well. Also, excellent support for groups, including group URLs you can stick on a github page. Great program all around.
When you say "desktop" version, do you mean the cross-platform one that offers downloads for Win/Mac/nix, or the specifically Mac version that has a whole lot less features (at this point) than the cross-platform version?
Judging from recent updates it's still alive. The version in AppStore might be stale (not sure) but if you install the version from site (https://macos.telegram.org) you'll get frequent update.e
But I must admit that amount of clients is confusing.
A very well-known cross-platform GUI library. If you google qt, the top hits are the official website and Wikipedia. Without clicking any link, the descriptions would have given you an answer.
It is compared to Electron; I don't know how WPF compares though, IIRC the 'de facto' way to make windows native apps nowadays also involves some web technology?
I'm still curious to hear Moxie/OWS' take on the Wire issue, where they supposedly demanded $2.5mln for implementing the Signal Protocol (which is open source) and using source code where the documentation lacked (which is open source).
But the most annoying problem with any internet voice chat is not so much the quality but the latency. Landline phones have noticeably lower voice quality but one can still enjoy a conversation perfectly well. High latency, on the other hand, absolutely ruins the experience.
I always see these services talking about "crystal clear quality", but never latency, which is a shame. Maybe there is simply nothing they can do about it. I've noticed latency get worse and worse on the Internet since I started using it in the 90s and nobody seems to talk about it.
There are so many more sources of latency on every layer on the modern internet and it's a damn shame. I remember when interleaving got enabled on my ADSL and latency to everything doubled overnight. Then there are NATs, and all kinds of filtering shit that ISPs insist on. Sigh...