LINE E2E are "Partial Claimed" their E2E encryption only encrypts text and GPS location and other are not encrypted.[0]
Messenger systems compared by security, privacy, compatibility, and features
141–150 of 242 posts
Re: Messenger systems compared by security, privacy, compatibility, and features
#142Earlier quoted context omitted.
Your points are valid but you didn't mention that OMEMO [1] implements Double Ratchet for XMPP. You can find a list of clients which support OMEMO on https://omemo.top [1] https://en.wikipedia.org/wiki/OMEMO
That's a fair point, but the fact that there's yet another protocol, not mentioned on the XMPP E2E wiki, kinda plays into the point itself: XMPP has E2E maybe with a bunch of random protocols and the stars (and the people you talk with) need to align _just right_ for all of it to work. I think it would be fair to say that everyone uses WhatsApp and I know what they get, and at this point only XMPP people use XMPP (ex…
The nice thing about wikis is that they're editable :) thanks for pointing out that page though, I've updated it a tiny bit (and will do more if I can figure out media wiki's table syntax).
That is, assuming you meant: https://wiki.xmpp.org/web/XMPP_E2E_Security
Re: Messenger systems compared by security, privacy, compatibility, and features
#143Earlier quoted context omitted.
XMPP is a protocol; it doesn't have a user experience. Sure, it may have been difficult to adapt for mobile, but that doesn't mean it inherently has a poor experience.
This is silly hair-splitting. If it's "hard to adapt" to mobile then it's the protocol implying poor UX. Fortunately, in XMPP country, we're always just a XEP away!
I think it's a valid distinction. You could make the case that a bad protocol makes implementing a solid UX harder, but you wouldn't say the protocol has "poor UX".
Re: Messenger systems compared by security, privacy, compatibility, and features
#144Earlier quoted context omitted.
Could you elaborate how WhatsApp and Signal are not doing well from a security/privacy perspective? Can you name an alternative that does better under those criteria? I was under the impression that Signal precipitated most modern messaging protocol design and verification. But what do I know: I'm just a relapsed cryptographer :)
Signal's stubborn insistence upon using Google Cloud Messaging (which is mostly notable due to their attempts to shut down third-party clients that remove this requirement) combined with its reliance upon phone numbers for identity is itself a serious problem, but when you combine this with the fact that their servers know "this phone number sent a message to this phone number at this time" (information that is even…
> "this phone number sent a message to this phone number at this time" (information that is even stored, at least temporarily, on their servers in order to implement rate limiting)
This claim appears to be unsupported by both Signal's privacy policy and public evidence. Unless I misunderstand, they've claimed to use IP addresses for rate limiting. Messages only necessarily contain the recipient's identifier for delayed delivery but certainly does not imply they have a store of (src_phone, dst_phone, hires_timestamp) triples. When subpoenaed for user data[0], they claimed to have no responsive records of IP data, let alone src, dst _and_ hi-res timestamps altogether. Are you saying that has changed, they're lying in their response to the subpoena, they were lying in their privacy policy, or something else?
The issue of long-term identifiers for offline delivery is well-understood (e.g. Rottermanner05) but also not actually a Signal problem. In that light: what do you propose we do instead? (You can probably see the response coming already: let's just say metadata protection is, ahem, complicated.)
[0]: https://signal.org/bigbrother/eastern-virginia-grand-jury/
Re: Messenger systems compared by security, privacy, compatibility, and features
#145Earlier quoted context omitted.
I do agree reproducible builds are the only solution to have practical evidence a given binary came from given source code. F-droid does this, which is why I personally don't consider any clients that are not willing to undergo that rigor. "AOSP" support in this context implies f-droid and implies reproducible builds, but maybe I should break that out more clearly.
This is not responsive to the core of my argument that nobody who actually audits and analyzes this stuff will tell you that source availability is necessary or even useful for figuring out if a particular application does what it says it does, unless you’re building the entire thing yourself off a trusted buildchain. Even if you have repeatable builds you still audit what the thing actually does.
Even with repeatable builds there are some ways to exploit the system, for example sending a targetted binary to audience that does not check the binaries, or sending a malicious update that exports all your history when you won't notice it (at night?) and then sending a good update to cover up.
Mozilla has done some research to close these issues [0] but until this is enforced on a system level reproducible builds won't solve the underlying problem.
Re: Messenger systems compared by security, privacy, compatibility, and features
#146This is neat but it has plenty of flaws. I wish the definitions were spelled out. It says Signal isn't "anonymous", which I assume means "uses a phone number to find peers". And it has the usual feature matrix problem: sure XMPP "does E2E". But what does that mean? It supports S/MIME. Do you want S/MIME? (You don't.) It supports OTR, TS and SCIMP too: but you need to be an expert in messaging schemes to understand ho…
Please make comments on individual cells for improvements to be seen/added more easily. This is obviously big research undertaking that got thrown together last weekend :) > Another example: "open server" and "on-premise" says nothing about whether or not you really want to run one of those instances. It just says that hypothetically one could. I know a number of people that run matrix.org servers for personal use an…
In order to comment on individual cells, we appear to first have to have an argument about how audits work. You say WhatsApp can only "claim" certain features as a consequence of it being closed source, but that's because of a misunderstanding about how audits work.
In a backchannel, as a consequence of this HN article, someone (names withheld to protect the guilty, they can identify themselves if they'd like) started looking at Dust and figured out the key store password is a hardcoded, short, ASCII string and the messages are encrypted with unauthenticated AES-CBC. They did not need the source code to do that.
JP Aumasson phrased it more eloquently than I could: https://research.kudelskisecurity.com/2018/10/02/open-source...
Re: Messenger systems compared by security, privacy, compatibility, and features
#147This is neat but it has plenty of flaws. I wish the definitions were spelled out. It says Signal isn't "anonymous", which I assume means "uses a phone number to find peers". And it has the usual feature matrix problem: sure XMPP "does E2E". But what does that mean? It supports S/MIME. Do you want S/MIME? (You don't.) It supports OTR, TS and SCIMP too: but you need to be an expert in messaging schemes to understand ho…
Please make comments on individual cells for improvements to be seen/added more easily. This is obviously big research undertaking that got thrown together last weekend :) > Another example: "open server" and "on-premise" says nothing about whether or not you really want to run one of those instances. It just says that hypothetically one could. I know a number of people that run matrix.org servers for personal use an…
The care Signal puts in that actually makes it a better, more secure messenger is primarily about metadata management. Consider how long it took for them to implement profiles, how much time they took to explain how their contact discovery works, et cetera. These are not trivial matters: they got subpoenaed and had nothing to respond with, because they're tried extraordinarily hard not to.
Re: Messenger systems compared by security, privacy, compatibility, and features
#148It's amusing that this is hosted by a spyware vendor.
Re: Messenger systems compared by security, privacy, compatibility, and features
#149Earlier quoted context omitted.
> Use WhatsApp to talk to normal people. Use Signal for nerds. This has been my go-to advice for a while now too! The key driving point is that amazing crypto is 100% useless if the person you're talking to doesn't use it, or uses it incorrectly. The only sticking point with the above advice is the nerds who think they understand crypto but don't and insist on you using some crazy app :/
Consider that security you can't possibly verify is just marketing. Maybe try listening to those nerds and try out some open alternatives with security that is possible to verify. You might be surprised to find both tools are pretty low on the list in respect to security and privacy compared to tools with smaller marketing budgets.
What good messenger is better than Signal but just has a smaller _marketing budget_?
Re: Messenger systems compared by security, privacy, compatibility, and features
#150Interesting comparison Irvick. Enjoying the resuling conversation too. More detail on meanings and methodology would be helpful as some other HN folks suggest.
Stealthy.im isn't mentioned (I develop that presently).
Stealthy makes use of decentralized identity in the blockchain and a decentralized storage system called GAIA. Regular chat is E2E encrypted using ECIES. Currently released for Android and iOS.