[HN Gopher] Why Isn't Telegram End-to-End Encrypted by Default (...
___________________________________________________________________
Why Isn't Telegram End-to-End Encrypted by Default (2017)
Author : aabbcc1241
Score : 85 points
Date : 2021-01-11 20:12 UTC (1 hours ago)
(HTM) web link (telegra.ph)
(TXT) w3m dump (telegra.ph)
| kitkat_new wrote:
| Seems they have yet to meet the Matrix Protocol.
| t-writescode wrote:
| Matrix is a protocol. Servers are horrible to set up and you
| have to find federations to join.
|
| Telegram, Signal and others are centralized, so you join one,
| you're a member of all.
| kitkat_new wrote:
| Actually setting up a server is not difficult. Check out
| https://www.youtube.com/watch?v=dDddKmdLEdg for setting one
| up with video conferencing.
|
| Finding a server is not difficult - in the worst case you
| take the default server.
|
| And given the server is not locked down, you have access to
| all other servers (and their users) as well. So I don't
| really get where you are going with this.
| t-writescode wrote:
| > Actually setting up a server is not difficult.
|
| And yet you point me to a YouTube video, rather than a link
| on their website.
|
| The documentation itself strongly encourages setting up
| your own server to have your own user information and then
| federating into a system, and yet, the documentation
| doesn't seem to describe, in friendly terms, how to do
| that.
|
| It might be easy to set up, but I've had trouble
| discovering all of that in their documentation.
| kitkat_new wrote:
| > And yet you point me to a YouTube video, rather than a
| link on their website.
|
| So you can _see_ it
|
| > and yet, the documentation doesn't seem to describe, in
| friendly terms, how to do that.
|
| mind to expand that?
| olah_1 wrote:
| > and yet, the documentation doesn't seem to describe, in
| friendly terms, how to do that.
|
| I've gotten mixed signals from matrix people on this.
|
| On one hand, they discourage people that aren't skilled
| in sys admin work to set up a server. On the other hand,
| they emphasize the simplicity of setting up a server and
| want as many as possible.
|
| I tend to think that the mixed signals are due to the
| fact that they sell matrix in a SAAS business model[1],
| so they want it to be difficult in some ways, but easy in
| others.
|
| [1]: https://element.io/matrix-services
| [deleted]
| mcint wrote:
| Bait-and-switch topic in the opening paragraph. Insists that what
| people ask for, e2e chat, isn't what they actually want or should
| want.
| pampa wrote:
| And he is right. If you want e2e use signal, threema, or
| OTR/OMEMO.
|
| The majority of telegram users want convenient messaging, group
| chats, news channels and voice group calls. Think slack with a
| fast native app.
| scubbo wrote:
| > news channels
|
| I love getting glimpses of how other people use certain apps.
| I can't imagine _wanting_ news in my messaging app - that's
| what my news app is for! Very valuable reminder that our own
| perspective is not always widespread.
| t-writescode wrote:
| I mostly see the news feed tool used for art.
| rajinikantham wrote:
| If you're interested in these, you should take a look at
| https://en.wikipedia.org/wiki/WeChat#Features !
| solstice wrote:
| The only thing missing from signal among the things you
| listed is news, no?
| rhn_mk1 wrote:
| Does wanting any of this automatically mean wanting e2e is
| wrong or invalid?
| alwaysdoit wrote:
| No, but it's automatically the right tradeoff for everyone.
|
| Security measures are always a tradeoff between convenience
| and security. Not everyone's tradeoffs work out evenly.
| Sometimes backups are a more important risk to mitigate
| than government surveillance.
| [deleted]
| tomp wrote:
| no, it says that what people ask for, e2e chat, isn't what
| people _get_ (because of unencrypted cloud backups).
| Tepix wrote:
| Even with e2e encrypted chats, the servers could store the
| encrypted conversations if the devices do not have enough storage
| to have all them stored locally.
|
| Device Backups: it's an important point that users need to be
| educated about. But it's also a distraction just like talking
| about the privacy of keyboard apps or unwanted link previews
| while composing/reading messages.
| srhngpr wrote:
| Genuine question, and I'm certainly no expert in this - just a
| curious end-user, aren't the backups that WhatsApp creates and
| uploads to iCloud/GDrive kind of encrypted? As in, I can't simply
| download the backup file and access the messages and media?
|
| My understanding is that in order to restore/access said messages
| and media, you would need the SIM/phone number that created the
| backup file and would have to register again with WhatsApp to
| receive a decryption key from WhatsApp servers. So doesn't this
| mean in effect that even though it's not super secure, the backup
| file stored on iCloud/GDrive is also protected from Apple and
| Google's prying eyes?
| tomp wrote:
| If WhatsApp has the decryption key, it's not end-to-end
| encrypted.
|
| If Apple has your decryption key, then iCloud uploads aren't
| encrypted (and Apple seems to have the decryption key, as they
| offer "reset password" functionality).
| srhngpr wrote:
| The backups aren't E2E encrypted, WhatsApp even tells you
| this in the backup settings page in the app. But if they hold
| the decryption key and the only way to get it is via
| registering with a WhatsApp server via SMS verification, then
| doesn't that imply that Apple and Google don't have the key
| and can't read or restore the messages?
| Ashoat wrote:
| My understanding is that WhatsApp backups are plaintext. It's
| true that Apple/Google can't recover your WhatsApp account with
| just the plaintext, but I believe they _can_ read the messages.
| srhngpr wrote:
| Thanks for replying! This is concerning if true. Is this
| documented or proven anywhere? I had heard something similar,
| but can't seem to find any reliable source that confirms the
| messages are in plaintext.
| [deleted]
| coolspot wrote:
| WhatsApp backup is unencrypted on both iOS/iCloud and
| Android/GDrive.
| srhngpr wrote:
| I keep hearing this, but is there an actual reliable source
| that confirms it? If it were that easy, then I could
| technically restore anyone's GDrive backup from WhatsApp on
| my Android phone simply if I got access to the same Google
| account, but I believe this is not possible as you have to
| also verify the phone number via SMS.
| oconnor663 wrote:
| Note that Keybase is end-to-end encrypted and also supports
| persistent message history across multiple devices. This doesn't
| have to be an either-or thing.
| jswizzy wrote:
| Isn't Telegram in Russia and most likel a KGB honeypot
| olah_1 wrote:
| No, Durav made a post about this recently but it was on his
| Telegram channel. Basically they don't have servers in Russia
| and it has been banned there in the past.
| Ashoat wrote:
| This article touches on the core issue holding back E2E
| encryption today. There's currently no way for a sophisticated
| application to implement E2E encryption without accepting
| tradeoffs in terms of the product.
|
| I'm working on starting a new company called Comm and we're
| trying to scale E2E. Some more context here:
| https://site.ashoat.com/comm/comm
|
| (We're currently hiring!!)
| kitkat_new wrote:
| > There's currently no way for a sophisticated application to
| implement E2E encryption without accepting tradeoffs in terms
| of the product.
|
| no?
|
| > I'm working on starting a new company called Comm and we're
| trying to scale E2E. Some more context here:
| https://site.ashoat.com/comm/comm
|
| How about you join forces with MLS
| snvzz wrote:
| The why doesn't matter. (the tl;dr is that they apparently never
| bothered to support some popular features within the context of
| e2ee, and believe people ultimately don't care about e2ee by
| default)
|
| What matters is that:
|
| - It doesn't do e2ee by default.
|
| - It is not an open protocol.
|
| - It is not a properly documented protocol[0].
|
| - It is not open source.
|
| - It has a history of extremely poor cryptography
| practices[1][2].
|
| Thus, we should steer people away from it, and into acceptable
| solutions that meet these fundamental requirements.
|
| Matrix, Signal and Tox come to mind; I have experience with all
| of these, and I can only recommend Matrix.
|
| [0]: https://core.telegram.org/mtproto
|
| [1]: https://news.ycombinator.com/item?id=25726068
|
| [2]: https://news.ycombinator.com/item?id=25641399
| skrowl wrote:
| > - It doesn't do e2ee by default.
|
| When creating a 1 to 1 chat, it's one of the default buttons.
| In Android, you click a {pencil} icon, then "new chat"
| (encrypted in transit and at rest like your bank website) or
| "new secret chat" (end to end encrypted)
|
| > - It is not an open protocol.
|
| The protocol is fully open source and audited.
| https://telegram.org/apps scroll down to source code.
|
| > - It is not open source.
|
| As above https://telegram.org/apps . The client apps are fully
| open source and reproducible.
|
| > - It has a history of extremely poor cryptography practices.
|
| People pointed out the security issues in MTProto v1, and they
| were all addressed in MTProto v2 over 3 years ago.
|
| You may be recalling some FUD spread by the author of what
| eventually became Signal, but none of what you said above is
| factual.
| snvzz wrote:
| >When creating a 1 to 1 chat, it's one of the default
| buttons. (...)
|
| That's a really long way to say e2ee requires special steps:
| Deliberately selecting "new secret chat".
|
| If there's ANY barriers to e2ee such as this one, then
| non-e2ee ends up being used.
|
| That's just how it is, how non-technical people are, and why
| we should steer everybody away from Telegram.
| [deleted]
| faitswulff wrote:
| I don't have a security or crypto background, but I saw an
| interesting bug story about Telegram here, provocatively
| entitled "Cryptography Dispatches: The Most Backdoor-Looking
| Bug I've Ever Seen."
|
| "Now, normally the two sides would compute the shared key as
| (g^a)^b mod p and (g^b)^a mod p. Instead, the original
| version of MTProto computed it as
|
| (g^a)^b mod p XOR nonce
|
| where nonce was an arbitrary, supposedly random value sent by
| the server along with the peer's public contribution.
|
| This was a completely non-standard and useless addition, and
| all it did was let the server perform an undetected Person-
| in-the-Middle attack."
|
| https://buttondown.email/cryptography-
| dispatches/archive/cry...
| emptysongglass wrote:
| Can you do your research before posting statements like these?
| They hurt a messenger that has done a great deal of good for
| protestors and other political rebels.
|
| If I take the kindest interpretation of your statements, they
| are factually wrong in whole but true in part. That is, the
| Telegram server code is closed source, yes. But Telegram
| clients and the protocols they use to "speak" are all either
| open source or documented where source code isn't applicable
| (MTProto 2). What's more is that reproducible builds are
| available for Android and iOS.
|
| There's nothing really wrong with MTProto 2. You appear to be
| pointing to a very long time ago when MTProto 1 was in use.
| MTProto 2 is based on standard crypto primitives and is well-
| documented. No vulnerabilities have been announced by security
| researchers in the years it's been in use. It is ok that not
| everyone uses the Signal Protocol. Not everything needs to
| descend from Moxie.
|
| I run my own Matrix homeserver and it's great. I also have it
| rolled out to all our employees at my workplace. It's an
| excellent choice. I also use Telegram because I appreciate its'
| balance of features and security. All of my family members love
| Telegram and that makes me happy because they're not using a
| Facebook product.
|
| The way Matrix handles keys for E2E by default is not great:
| it's very easy for users to lose the key encryption phrase or
| not care and throw it away. I'm not sure how much better we can
| make E2E by default.
|
| I am completely ok with turning on Secret Chats as I need them
| for chats I know to be disposable. My message history is
| extremely precious to me and Telegram does an admirable job
| protecting it and making it searchable for later reference. It
| truly is a sort of outboard brain for me.
|
| This does not need to be a turf war between Signal people and
| Telegram people. I have expressed many times on the Telegram
| subreddit the need to come together in our use of better tools
| for communication than the incumbents. A person choosing
| Telegram or Signal over WhatsApp and Discord is a huge win for
| all of us.
| hiq wrote:
| > My message history is extremely precious to me and Telegram
| does an admirable job protecting it
|
| How would you know without E2EE? A Telegram sysadmin could
| copy all your messages from non-secret chats and you would
| never know.
|
| The lack of E2EE is also why many (including security
| experts) recommend WhatsApp over Telegram.
| snvzz wrote:
| I do not like it, but I am ok with Signal, as it is open
| source, it is always e2ee and using it really offers privacy.
|
| Telegram, on the other hand, is not open source, nor does it
| do e2ee by default. Having to explicitly select "new secret
| chat" ultimately means the non-technical inclined can and
| will use it wrong, getting no privacy whatsoever.
|
| Therefore, I cannot support the idea that Telegram is any
| better than WhatsApp or Discord.
| pmlnr wrote:
| I've been exploring options with a friend, their requirements:
|
| 1) option for large groups (around 250) This drops Signal out
| which has a limit of 150 on groups:
| https://support.signal.org/hc/en-us/articles/360007319331-Gr...
|
| 2) e2e encrypted (because it sounds good, not because people
| actually understand what it is), including groups. This drops
| Telegram out: no e2e rooms.
|
| 3) handles sending photos, videos, and voice messages. More or
| less kills XMPP, unless people are on the latest-and-greatest
| version of Conversations and maybe ChatSecure.
|
| 4) the maintaining organisation needs to be reasonably big with
| decent privacy.
|
| 5) usable for completely non technical generic population -
| meaning Tox is out as well.
|
| As much as I dislike to admit it, this leaves Matrix, and
| nothing else. My problem with Matrix is that it's so resource
| hungry - both the servers and the clients - is that it's silly.
| Yes, I know "optimization is coming" but even Dendrite eats
| 1.5GB memory easily with a single user joining a few, medium
| sized, federated rooms (yes, I've tried).
|
| Footnote: Threema... no. There is no need for yet another
| competing open source thing, there are enough with Signal,
| Matrix, and XMPP.
| hiq wrote:
| > This drops Signal out which has a limit of 150 on groups
|
| Your own link mentions "Size limit of 1000", where did you
| see 150?
|
| To be fair that's for new groups, maybe the limit used to be
| lower. Or do you mean that in practice it's not usable beyond
| 150 people?
| upofadown wrote:
| >handles sending photos, videos, and voice messages More or
| less kills XMPP, unless people are on the latest-and-greatest
| version of Conversations and maybe ChatSecure.
|
| Are there any popular XMPP clients that _don 't_ support
| "HTTP File Upload" at this point? I went looking for a list
| of those that do and had to give up. They all support it now.
| pmlnr wrote:
| Well... that's complicated.
|
| On it's own, XEP-0363 (HTTP File Upload) and OMEMO both
| work well everywhere, even in my horribly overpatched
| Pidgin.
|
| But if you put the two together, Conversations, for
| example, will encrypt the message and encrypt the upload as
| well.
|
| My Pidgin then will handle the message well, but display an
| url starting with aesgcm:// leading to the still encrypted
| file.
|
| The question is then: is the correct behaviour what of
| Conversations is doing - encrypt the message and upload as
| well? If yes, is OMEMO a requirement to HTTP File Upload or
| the other way around?
| m4lvin wrote:
| Encrypting the message AND the upload seems a no-brainer
| to me, if you want to call it E2EE. If the upload would
| not be encrypted then the (admin of the) server running
| XEP-0363 HTTP File Upload could see the contents.
| pmlnr wrote:
| I agree. The part I don't see is then what plugin should
| handle which part, and how.
|
| Most XMPP clients are plugin based as well. Should the
| OMEMO plugin then look for aesgcm:// urls, download it,
| and decrypt it, or should the http upload plugin look for
| the availability of encryption and try to decrypt?
| yatralalala wrote:
| Have you heard about Wire? Groups up to 500, when they switch
| to MLS protocol then thousands, e2e, Swiss based and it has
| kind of ok UI.
| kitkat_new wrote:
| uninstalled it after I lost all history, because I didn't
| open the app often enough.
|
| Found Matrix, happy with it. It likely will adopt MLS, too.
|
| PS: these days swiss based is a bit of a stretch
| pmlnr wrote:
| > has kind of ok UI
|
| It has a single UI, so it's out. Wire specifically
| disallows anything 3rd party.
| thekyle wrote:
| I'm all for end-to-end encryption, but if you have 250 people
| in the chat I'm not sure it'll be very effective. It only
| takes one of those people to leak the messages.
|
| When you get into groups with hundreds of members I think
| Slack and Discord are probably the dominant chat apps there.
| snvzz wrote:
| Non room members shouldn't be able to read the text in the
| room. That's quite basic.
|
| As far as old messages goes, Matrix rooms do not allow new
| participants to see old history, unless explicitly enabled.
|
| >if you have 250 people in the chat I'm not sure it'll be
| very effective. It only takes one of those people to leak
| the messages.
|
| Ultimately, the system is only good when the members of a
| room deliberately leaking messages is the primary concern;
| It means the system is working as intended, thus privacy is
| a matter of trust on the conversation members, as it is
| away from keyboard.
| pmlnr wrote:
| Neither does XMPP, given it doesn't store it ;)
| kitkat_new wrote:
| > Neither does XMPP, given it doesn't store it ;)
|
| and how is it achieved when you want that? Standard
| feature that is expected by people using Telegram,
| Matrix, Slack, etc.
| pmlnr wrote:
| Not by the people used to WhatsApp. That doesn't do it
| either.
| snvzz wrote:
| But XMPP has the non-trivial problem of e2ee as an
| extension added very late and not the default.
|
| I can't suggest XMPP to non-technical people, because I
| know they'll end up talking to each other with neither
| e2ee nor awareness of lack of e2ee.
| pmlnr wrote:
| Indeed. But ever since Whatsapp started advertising e2e,
| people want it.
| thekyle wrote:
| Well I'm glad to hear that e2e is a feature that's in
| demand. :)
| pmlnr wrote:
| That is not a good approach. Every piece of technology
| has it's place; requiring 2e2 encryption in a group of
| hundreds is a bad requirement.
| Arathorn wrote:
| Matrix's resource utilisation is improving very rapidly at
| the moment.
|
| Dendrite is still in beta, and hasn't been tuned that much
| yet, but every release has had a substantial improvement. In
| other words, if you're not using today's release (0.3.5)
| you're on stale data. For context, dendrite.matrix.org
| (running 0.3.5) has ~5K users on it, and is in ~3K rooms
| spanning 162K users... and its RAM usage is stable at 488MB
| (occasionally spiking to 2GB during traffic spikes). This
| doesn't seem unreasonable at all for a chat server of that
| size. Meanwhile, Synapse has been steadily improving too.
|
| On the client side, Hydrogen (https://hydrogen.element.io,
| https://github.com/vector-im/hydrogen-web) is our next-gen
| client implementation, which gives you full E2EE, complete
| with backup (I have no idea what Durov is banging on about in
| the OP) - and uses 14MB of RAM for an account in 3,000 rooms
| spanning 350K users (i.e. my personal one). This is an 100x
| improvement on Element Web which uses 1.4GB for the same
| account, although there's also a lot of optimisation that can
| be done there too.
|
| If I was going to criticise Matrix, I'd focus more on the
| fact that there are still a lot of papercuts on Element's UX
| which are holding us back. We're painfully aware of this
| though and are trying to fix as rapidly as we can.
| snvzz wrote:
| Hydrogen looks extremely promising due to its low resource
| usage, but urgently needs an easy way to verify its session
| from Element and migrating the keys.
| pmlnr wrote:
| > is improving very rapidly at the moment
|
| > occasionally spiking to 2GB during traffic spikes
|
| That's an improvement? What was it before?
| snvzz wrote:
| >2) e2e encrypted
|
| As you haven't mentioned it: Supporting e2ee isn't enough. It
| must be the default, else the non-technically inclined will
| often end up not using e2ee.
|
| >As much as I dislike to admit it, this leaves Matrix, and
| nothing else.
|
| I'm in the same position. Never been a fan, but I have to
| support it, because that's really the only option, even if
| bloated.
|
| I also tried running a server (synapse) with similar results.
| I have hopes for dendrite, but they've just been dampened by
| your report.
|
| Fortunately, the client side is far more important, and
| there's some options there. Particularly, the web-based
| hydrogen is massively less resource-hungry than the web-based
| element, and nearly there featureset-wise.
|
| >XMPP
|
| I didn't even list that one, because e2ee is not the default,
| and support was added way too late in the protocol's
| trajectory.
|
| >Signal
|
| I mentioned it, but I'm actually not about to use it. The
| reason is that accounts are tied to phone lines. That's a
| non-starter for me.
| pmlnr wrote:
| > it was added way too late in the game.
|
| That is not a thing with XMPP. The very essence of it is
| adding things in, and OMEMO is quite good.
| kitkat_new wrote:
| try having verified e2ee conversations with XMPP - good
| luck.
| pmlnr wrote:
| Doing it actively. Try Conversations.
| kitkat_new wrote:
| how many contacts with how many devices do you have
| there?
|
| can't be many
| snvzz wrote:
| I've been having them for over a decade.
|
| The "only" problem is that it isn't easy, and thus most
| people do not use them at all.
|
| Therefore, I cannot recommend XMPP.
| snvzz wrote:
| I'm well aware of how XMPP works as I've been using it
| from the start.
|
| It is with this knowledge that I cannot recommend XMPP.
|
| e2ee should be at the core. Not as an entirely optional
| extension added decades after.
|
| As I already stated, because I want the non-technical
| inclined to have privacy, I can only support options
| where e2ee is the default.
| Ashanmaril wrote:
| >It doesn't do e2ee by default.
|
| I read the article and he claims it does? It's just that the
| default uses their cloud backup where Telegram has access to
| the private keys.
| Voline wrote:
| If Telegram has access to the keys it is not e2e. People who
| like to play fast and loose with the definition of end-to-end
| encryption are not to be trusted. Looking at you Zoom.
| rodolphoarruda wrote:
| I don't get this:
|
| "These backups are not e2e-encrypted and get decrypted
| whenever(...)"
|
| Are they or are they not encrypted?
| noctua wrote:
| The chats are encrypted and stored encrypted on the cloud, but
| they have access to the key. If they didn't have access to the
| key they couldn't allow some of the functionality that people
| want like being able to see the chats from different devices.
| Telegram has secret chats too which are e2e encrypted and don't
| store anything on the cloud.
| this_user wrote:
| They are probably encrypted in the backend DB with a symmetric
| cipher on the server with a key that Telegram have access to.
| pmlnr wrote:
| E2E chat is an interesting topic. Say I'm using XMPP, my own
| server, talking to a federated one, all over TLS, including S2S.
|
| E2E on top of that, in my personal opinion, is a massive overkill
| for most cases and people.
|
| Related read: https://homebrewserver.club/have-you-considered-
| the-alternat...
|
| It is, however, different, when it comes to a server that I don't
| control in any form. In that scenario, it is rather useful, but
| I'm still a lot more worried about the unencrypted meta
| surrounding it. See email and PGP in this topic, which has always
| been a pain point for many.
|
| Thoughts?
| pampa wrote:
| > Thoughts?
|
| Pick your adversaries and scale your opsec accordingly. Unless
| you are a person of interest in national security matters, just
| the fact that you communicated with somebody does not
| incriminate you.
| kitkat_new wrote:
| Honestly you have no idea about real use cases. Almost no one
| is going to set up a dedicated local server for all of his
| conversations, hosting only conversations in which you are part
| of anyways.
|
| Most people aren't even able to do this.
| pmlnr wrote:
| > Almost no one is going to set up a dedicated local server
| for all of his conversations
|
| 85000 Prosody servers disagree to some level :)
|
| https://news.ycombinator.com/item?id=25713679
| kitkat_new wrote:
| in other words, almost no one compared to at least 2
| billion potential users.
| out_of_protocol wrote:
| Still avoiding the main point - e2e encryption does not prohibit
| syncing, backup etc for said data (without decryption)
| pampa wrote:
| e2e does not prohibit it. But makes it hard or impossible even
| for an advanced user (i tried moving my whatsapp data from
| iphone to android once, not sure of the current status with
| signal).
|
| Telegram is all about convenience, security is just bolt on.
| Everybody says they care about security, but hardly any TG user
| does it, because it is inconvenient. Install it on any any new
| device, confirm your phone number with an sms and whoops, all
| your chats and drunk and stoned pics are back.
| Jtsummers wrote:
| If messaging clients like WhatsApp permitted a Keybase styled
| authentication of additional devices, then migration (so long
| as the original were available) wouldn't be difficult at all.
| And if they permitted backup to a user selected service (for
| instance, Google's for Android versus Apple's for iOS) then
| migration across OSes would become simplified for users.
|
| But the WhatsApp iOS client backs up to iCloud, and the
| Android client backs up to Google, and this creates a
| blocking issue unless the user is willing to jump through
| hoops and use 3rd party tools.
| snvzz wrote:
| Matrix actually does authenticate additional devices, and
| handle all that.
|
| It's already out there, just a matter of adopting it.
| kitkat_new wrote:
| This just is not true. The fact that you are writing this,
| clearly shows you don't know of Element/Matrix.
|
| When you use Matrix, and open a web client, the only thing
| you have to do is 1) logging in and 2) providing a password,
| key file, scan a QR code, OR compare Emojis - and you get
| everything synced.
|
| The same holds for any type of client. I barely see a loss of
| convenience, let a lone something being hard or impossible.
| pampa wrote:
| You are right, I never used Matrix. I guess i have to check
| it out. Missed it. Usable client apps for martix are what,
| 1.5 years old?
|
| Signal seems to have been around for ages. OTP even longer
| kitkat_new wrote:
| > Usable client apps for martix are what, 1.5 years old?
|
| Older, Element (also known as Riot and Vector) should
| already exist for at least 5 years.
| annoyingnoob wrote:
| Maybe I'm missing something, seems like any of these apps that
| might want local storage for some reason could store data in an
| encrypted format. A cloud backup would then be backing up and
| restoring encrypted data. Where the user holds the key in some
| form to unlock the data at the right time.
|
| They bring up a good point that anyone with access to the message
| can leak it, no matter how tight you lock down your side.
| Something ephemeral seems best if you really want security.
| meibo wrote:
| > 1) Users don't want to lose their entire message history when
| they lose/change their phones so apps of this kind never become
| massively popular.
|
| I think this is a key point to consider for Signal and the other
| "good" messengers - there's ways to do secure backups, it just
| needs to be implemented so well that you won't miss the
| convenience of Google Drive backups.
|
| I tend to fall back on anecdotes a lot, but the first thing my
| relatives ask me when setting up a new phone is "will I have my
| texts" - people want to be able to look through the past 10 years
| of conversation and especially media with someone and WhatsApp
| makes this as easy as one click during setup.
| pampa wrote:
| > and WhatsApp makes this as easy as one click during setup.
|
| unless you switch platforms. then you lose it all
| tandav wrote:
| Yes, this happened to me after iOS -> Android switch all
| messages was wiped, you cant load icloud backup on android
| dochtman wrote:
| I've just spent like 10 hours this week trying to figure
| out how to get my Android history into iOS. I finally did
| succeed with one the paid apps, but it's crazy to me that
| Whatsapp hasn't fixed this (and neither has Signal, by the
| way).
| pampa wrote:
| Paid app is the new perl script!
|
| I wonder why there are paid apps an NO, ZERO information
| on how to do it with a text editor, some copyaste and
| javac/xcode. Like DeCSS, from a more civilized age
| tw04 wrote:
| >you cant load icloud backup on android
|
| for free
|
| If you're willing to pay for an app, you can definitely do
| that.
|
| https://www.syncios.com/icloud/how-to-recover-data-from-
| itun...
|
| *I'm not advocating for this specific app, I've never used
| it and couldn't comment on how well it works, just an
| example*
| codetrotter wrote:
| The only mention of WhatsApp on that page is a link to
| https://www.syncios.com/whatsapp-transfer/
|
| Not sure if the WhatsApp transfer is a feature of their
| main product or if it's sold separately.
|
| Either way I'd use the buy button on the page that is
| about WhatsApp to be sure, if I was looking to transfer
| WhatsApp data between iOS and Android.
| yatralalala wrote:
| Wire has backups and is e2e even for groups and all.
| dhsysusbsjsi wrote:
| Amazingly this is why I'm attracted to Signal and have set all
| chats to 1 week auto delete.
|
| To me text chats should be ephemeral.
|
| If I want something to stick around for years, send to email.
| behnamoh wrote:
| Even email is not permanent. There was a discussion a few
| months ago on HN where people were complaining that very old
| attachments just don't load up in Gmail, because they are not
| backed up on the servers.
| kitkat_new wrote:
| Matrix already has solved it. Message history is stored on the
| servers, like in Telegram.
|
| With the difference, that the end user has a secret. This
| secret can be written down/saved and/or be implicitly passed
| through his/her own devices by e.g. scanning a QR code.
|
| This works simultaneously across arbitrary platforms with
| arbitrary many devices including web.
|
| Telegram seems to want to create the illusion that there is
| nothing which can provide the experience of Telegram with
| encryption. It is not true.
| meibo wrote:
| Matrix seems to be the best implementation of this I've seen
| up to now, I agree.
|
| Even just giving you the option to upload to Drive or iCloud,
| while allowing you to keep the key yourself on a note or
| another device, would be a step in the right direction for an
| app like WhatsApp that has no "messages" on the server at all
| after delivery(or so it always used to work, not sure if it's
| still the case - my GDPR export from yesterday literally only
| had my profile picture and contacts).
| olah_1 wrote:
| Look at Ethereum smart contract wallets today[1]. They have
| social account recovery in case you shoot yourself in the foot.
|
| If it can be used for your money, it can be used for your chat
| history.
|
| [1]: https://www.argent.xyz/blog/a-new-era-for-crypto-security/
| tarasmatsyk wrote:
| Here is what puzzles me every time about telegram (which is my
| primary messager so far)
|
| I can get the reasons behind not doing e2e encryption by default
| to reach more audience (msgs history, lack of resources on start,
| special backups)
|
| What I cannot get is why Durov is blaming FB/WhatsApp that much,
| it seems to be the main competitor. As for me the story with
| WhatsApp is clear, it's Facebook and if you like being Zucked -
| go with it. But why so much hate on it?
|
| On the other hand, every time Signal pops up the only answer I
| see: 'because it does only e2e well which is only one feature of
| Telegram' - wrong, Signal does secure messaging and messager has
| to do its job well, that's it. You need a media platform - go for
| Telegram/WhatsApp/Facebook, you need a messager - use
| Signal/Wire/etc
|
| Does anyone else feels this bias towards WhatsApp? I cannot blame
| WhatsApp for being WhatsApp, that's how FB makes money
| ip26 wrote:
| There was & may still be a lot of anger towards WhatsApp. It
| was only after it became the de facto messaging app for most of
| the world that it became a FB property, so I think people felt
| either betrayed, hoodwinked, or simply trapped without a good
| exit. Compare to FB Messenger, which was always a FB product
| from day one, so you always knew what you were getting.
| tarasmatsyk wrote:
| What you say makes sense, on the other hand I am glad
| WhatsApp founder put some money into Signal, he's done an
| amazing job and deserves all the money.
|
| I am from another side of the messagers, as Viber concured
| Easter Europe - Telegram seemed like an obvious choice after
| VK got stolen from Durov. Signal was not that popular, that's
| why I did not start migration earlier
___________________________________________________________________
(page generated 2021-01-11 22:01 UTC)