Earlier quoted context omitted.
It allows Google to easily circumvent any end-to-end encryption since it's a rootkit.
How? What mechanism? Does it access the plain text from the keyboard before the app encrypts it?
It could do that.
I don't trust Signal
181–190 of 473 posts
Re: I don't trust Signal
#182Earlier quoted context omitted.
I am happy to see I am not the only person in the world that feels like this about Signal. The interesting fact is that I "Ctrl+F" this page for Wire and I have seen nothing, even though this comment is about something that made me switch over Wire from Signal: to date, that's the unique instant messaging that has FOSS'ed both the server and the clients. (OK, the article also says about Matrix.) I admire Wire for a n…
An open-source server is certainly a step up from Signal, but since Wire doesn't support federation (either in their ToS or in practice) I'd favour Matrix.
> An open-source server is certainly a step up from Signal
https://github.com/signalapp/Signal-Server.
You are spreading a lot of incorrect or misleading information about Signal in this thread. That makes it difficult to assume that you're arguing in good faith here.
Re: I don't trust Signal
#183> Truly secure systems don’t require trust. This is a chat app so, by definition, security requires trusting at least one other person. Also, I think experience shows that secrets can often be least trusted to those who have some interest in/use for them, with the secret owner often being the least trustworthy of all. So I'd say that if you trust yourself you're already probably trusting one of the weakest links in w…
> Trustless security does not exist, and attempting to achieve it by adding more technological layers and more complexity reduces rather than enhanced security. How so? If you can minimize trust to the point where you have to trust someone to only properly design federated or peer-to-peer open protocol and trust that others will participate and oversee the process it's one thing, as there is no control or power to go…
I understand your argument, but it cannot be shown to be more valid than the complete opposite: the less centralized a system is, the more complex it is in terms of protocols, and you need to trust many more people to design it correctly than you would need to trust to operate a centralized system. In fact, it could be argued that beyond some complexity level, an unbreakable design is virtually impossible, even in principle.
Your argument about an appealing target could also be used to show the exact opposite: decentralized systems are much harder to upgrade, and so they become attractive targets which you need to break much less frequently (especially considering that the internet backbone itself is pretty centralized), and so it makes even very expensive cracking more affordable. The argument about open-source applies pretty much equally to the centralized and decentralized case.
Re: I don't trust Signal
#184Signal is not for state-proof encrypted communication. Not large states like the USA or Russia. If you think it is, you've been misinformed. For state actor proof communications you need to evaluate every action you take and think: "What are the assumptions that I'm making here?" One assumption is that you're not currently on anyone's radar. Are you willing to bet the entire enterprise on this assumption? How certain…
> Signal is not for state-proof encrypted communication. Not large states like the USA or Russia. If you think it is, you've been misinformed. Ok, but in that case what does Signal offer that any random messenger with transport encryption doesn't? If your threat model doesn't include state actors then you can probably trust a) the HTTPS certificate infrastructure b) an international corporation like Facebook, so you…
1. The HTTPS infrastructure is downgradeable and relies on DNS and a multitude of certificates. And not all the ciphers are safe. Yes it can be done securely-ish, but unless you're layering another level of encryption over HTTPS it isn't fully secure. Layering is what the CIA does, according to the Snowden leaks.
2. As for the rest of it: Cool man, that sounds like you want a normal chat app that is more usable and less secure. I use Messenger too for things that don't matter.
Re: I don't trust Signal
#185Some version of this post seems to circulate every few months or so. This one is more direct in its accusations of Moxie acting in bad faith. I think this is disingenuous. Moxie has been very clear[0] about the tradeoffs that Signal has made and the reasons for them. It's fine to be dissatisfied with those choices. It's another thing entirely to accuse Moxie of dissimulating. Personally, I'd like to see Signal replac…
I am not willing to support Signal if they are unwilling to federate the system. Sure, it doesn't allow them the flexibility they'd like to have to move forward but in a way it won't be their fault if federated servers aren't keeping themselves up to date when there's a major protocol change and they get temporarily splitted from the pool.
Your „in a way“ is totally opposed to what normal users see. They will blame OWS when their Signal client that hasn‘t been updated in two years won‘t work.
Re: I don't trust Signal
#186Some version of this post seems to circulate every few months or so. This one is more direct in its accusations of Moxie acting in bad faith. I think this is disingenuous. Moxie has been very clear[0] about the tradeoffs that Signal has made and the reasons for them. It's fine to be dissatisfied with those choices. It's another thing entirely to accuse Moxie of dissimulating. Personally, I'd like to see Signal replac…
I am not willing to support Signal if they are unwilling to federate the system. Sure, it doesn't allow them the flexibility they'd like to have to move forward but in a way it won't be their fault if federated servers aren't keeping themselves up to date when there's a major protocol change and they get temporarily splitted from the pool.
It doesn’t matter whose “fault” it is — the issue is the practical effect that will result. This is exactly his point with the SMTP and GitHub analogy from the “moving ecosystems” post. Why do you think the split would be “temporary”?
As long as “email” is a thing, as in “just send me an email”, and it’s a federated set of randomly updated servers, “email” will never have end-to-end encryption, because the first version of SMTP didn’t have it, and the user will still expect to send messages to a server running that version.
Similarly, if “Signal” is going to be a thing, as in “contact me on Signal”, the entire network effectively has to operate at the level of the least up-to-date server — otherwise it’s not one network, and the product is therefore unreliable. But there’s no way to enforce that all the federated servers update themselves in any amount of time.
Re: I don't trust Signal
#187Google, APK ... if you're concerned about security, you would use Apple iOS only.
If you're concerned about security you don't use a smart phone and don't use your phone as a computing device. I know it's a lot to ask of people and so most will simply ignore the massive, unfixable (at least yet), security and privacy issues (ie, 5 years of your location 24 hours a day tracked, stored, and sold to whoever wants to pay).
But really, smart phones are bad. Even dumb cell phones are bad. And if you care about security you'll use a real computer without a closed, bug-ridden (an maybe even backdoor-ridden) baseband modem that can read/write to your entire user OS RAM.
All this bikeshedding about the minor security issues on top is a waste of time. That Signal requires a phone number to use is all you need to know. It's not secure.
Re: I don't trust Signal
#188Some version of this post seems to circulate every few months or so. This one is more direct in its accusations of Moxie acting in bad faith. I think this is disingenuous. Moxie has been very clear[0] about the tradeoffs that Signal has made and the reasons for them. It's fine to be dissatisfied with those choices. It's another thing entirely to accuse Moxie of dissimulating. Personally, I'd like to see Signal replac…
I am not willing to support Signal if they are unwilling to federate the system. Sure, it doesn't allow them the flexibility they'd like to have to move forward but in a way it won't be their fault if federated servers aren't keeping themselves up to date when there's a major protocol change and they get temporarily splitted from the pool.
Try to look at it from a user perspective, though. It's not a question of whose fault it is when something doesn't work, it simply doesn't work.
Signal is successful in large part because it provides complex functionality (secure messaging) in a package that "just works". Federation complicates that significantly.
Re: I don't trust Signal
#189> P.S. If you’re looking for good alternatives to Signal, I can recommend Matrix. Yes, if you're looking for alternatives to Signal, you should totally use a solution that hasn't rolled out end-to-end encryption by default[0]. /s ...and that only two clients have implemented so far, out of 50ish that they list on their website. [0] https://matrix.org/docs/guides/faq.html#what-is-the-status-o...
Last time I've tried Matrix (this spring) with a group of peers, my E2E rooms were full of random "failed to decrypt" and lots of out-of-band communications "hey, are my messages working for you today?" Yes, we had one Synapse server running on a resource-constrained machine that sometimes "fell behind" the rest of the network. I believe that is what had caused such issues. Still, the fact things easily break with se…
That mirrors my experience with the matrix.org homeserver. It has not improved much over all the months.
Re: I don't trust Signal
#190Earlier quoted context omitted.
How? What mechanism? Does it access the plain text from the keyboard before the app encrypts it?
It could do that.
Google certainly doesn‘t need the Play services to do that. If you assume Google to be malicious in that way, no app on your Android phone can be secure.