So what's left?
-
So you don't have any evidence.
And that Signal shares phone numbers and connection timestamps is well established by court documents
They do not share phone numbers. Phone numbers are the identifier, meaning if anyone wants the timestamps, they need to have it already.
The only timestamps shared are when they signed up and when they last connected. This is well established by court documents that Signal themselves share publicly.
I don't need evidence for water being wet
-
I don't need evidence for water being wet
I can observe that water is wet. I cannot observe that the NSA is collecting mountains of metadata from Signal servers.
-
I can observe that water is wet. I cannot observe that the NSA is collecting mountains of metadata from Signal servers.
You can observe that your Signal client connects to IPs that belong to AWS, which is the same thing.
-
You can observe that your Signal client connects to IPs that belong to AWS, which is the same thing.
LOL no it's not.
-
LOL no it's not.
$10b US defense cloud contract re-awarded to AWS
Microsoft won, Amazon complained. Amazon won, Microsoft complained. Amazon won... again
(www.theregister.com)
-
Yeah it's like appealing to authority and social pressure all in one. We already discussed it. Bah.
-
The argument has always been, if when chat rooms are public, anyone can join and start logging the chats, encryption does nothing.
It has the ability to connect over TLS, but that's about it.
I loved using it for its simplicity, except when using all the different flavours of nick registration (Q, NickServ, ...).
My friends created a telegram group and invited in a couple of bots that do stupid things like posting images or vulgarities when they detect certain words, or perform actions on request.
I tried to convince them to get rid of the bots but they're in the "we have nothing to hide" camp.
-
The clients are pretty slick now too, such as Cheogram or Monocles
I wouldn't call either of those, or any other XMPP clients "slick" and it's my biggest complaint about the protocol.
What would make them slick?
-
The argument has always been, if when chat rooms are public, anyone can join and start logging the chats, encryption does nothing.
It has the ability to connect over TLS, but that's about it.
I loved using it for its simplicity, except when using all the different flavours of nick registration (Q, NickServ, ...).
There is some nuance here. It would be nice to not have your identity publicly linked to your IP address, which is not always the default on IRC.
That's the main privacy concern I know about I guess.
-
What's the protection in the clients assuming compromised infrastructure, like e.g. in https://notes.valdikss.org.ru/jabber.ru-mitm/ ?
https://www.devever.net/~hl/xmpp-incident
This article discusses some mitigations.
You an also use a platform like simplex or the tor routing ones, but they aren't going to offer the features of XMPP. It's better to just not worry about it. This kind of attack is so difficult to defend against that it should be out of the threat model of the vast majority of users.
-
Significant improvements to certificate pinning and validation have been added to all major XMPP clients as a result of this incident, but it should also be clear that hosting a server on infrastructure under control by an antagonist government (see also Signal) is a very bad idea and hard to mitigate against.
So Signal does not have reproducible builds, which are very concerning securitywise. I talk about it in this comment: https://programming.dev/post/33557941/18030327 . The TLDR is that no reproducible builds = impossible to detect if you are getting an unmodified version of the client.
Centralized servers compound these security issues and make it worse. If the client is vulnerable to some form of replacement attack, then they could use a much more subtle, difficult to detect backdoor, like a weaker crypto implementation, which leaks meta/userdata.
With decentralized/federated services, if a client is using other servers other than the "main" one, you either have to compromise both the client and the server, or compromise the client in a very obvious way that causes the client to send extra data to server's it shouldn't be sending data too.
A big part of the problem comes with what Github calls "bugdoors". These are "accidental" bugs that are backdoors. With a centralized service, it becomes much easier to introduce "bugdoors" because all the data routes through one service, which could then silently take advantage of this bug on their own servers.
This is my concern with Signal being centralized. But mostly I'd say don't worry about it, threat model and all that.
I'm just gonna @ everybody who was in the conversation. I posted this top level for visibility.
@Ulrich@feddit.org @rottingleaf@lemmy.world @jet@hackertalks.com @eleitl@lemmy.world @Damage@feddit.it
EDIT: elsewhere in the thread it is talked about what is probably a nation state wiretapping attempt on an XMPP service: https://www.devever.net/~hl/xmpp-incident
For a similar threat model, signal is simply not adequate for reasons I mentioned above, and that's probably what poqVoq was referring to when he mentioned how it was discussed here.
The only timestamps shared are when they signed up and when they last connected. This is well established by court documents that Signal themselves share publicly.
This of course, assumes I trust the courts. But if I am seeking maximum privacy/security, I should not have to do that.
-
So Signal does not have reproducible builds, which are very concerning securitywise. I talk about it in this comment: https://programming.dev/post/33557941/18030327 . The TLDR is that no reproducible builds = impossible to detect if you are getting an unmodified version of the client.
Centralized servers compound these security issues and make it worse. If the client is vulnerable to some form of replacement attack, then they could use a much more subtle, difficult to detect backdoor, like a weaker crypto implementation, which leaks meta/userdata.
With decentralized/federated services, if a client is using other servers other than the "main" one, you either have to compromise both the client and the server, or compromise the client in a very obvious way that causes the client to send extra data to server's it shouldn't be sending data too.
A big part of the problem comes with what Github calls "bugdoors". These are "accidental" bugs that are backdoors. With a centralized service, it becomes much easier to introduce "bugdoors" because all the data routes through one service, which could then silently take advantage of this bug on their own servers.
This is my concern with Signal being centralized. But mostly I'd say don't worry about it, threat model and all that.
I'm just gonna @ everybody who was in the conversation. I posted this top level for visibility.
@Ulrich@feddit.org @rottingleaf@lemmy.world @jet@hackertalks.com @eleitl@lemmy.world @Damage@feddit.it
EDIT: elsewhere in the thread it is talked about what is probably a nation state wiretapping attempt on an XMPP service: https://www.devever.net/~hl/xmpp-incident
For a similar threat model, signal is simply not adequate for reasons I mentioned above, and that's probably what poqVoq was referring to when he mentioned how it was discussed here.
The only timestamps shared are when they signed up and when they last connected. This is well established by court documents that Signal themselves share publicly.
This of course, assumes I trust the courts. But if I am seeking maximum privacy/security, I should not have to do that.
Consider that your the french intelligence services and you need to setup secure communication for the french government.
- Would you use signal out of the box? Clearly not.
- Would you copy signal and setup your own servers and clients, same source, different end-points? Probably not.
If you said yes to either of the above, what if you were not a ally of the US, maybe Russia, China, DPRK.... Does that change your answer?
What capabilities does the runner of a centralized service have?
- See all traffic
- Can block traffic
- Can slow traffic
- Can record all traffic
- Timing analysis of metadata
Does this mean Signal is a bad product? No not at all. But it does mean its very well positioned for intelligence harvesting. Add in storing private encryption keys in the cloud SVR relying on intel SGX security... and well... you get everything even decrypted messages.
The US controls Signal, the US controls Intel - Thus the US can get any code they want signed into SGX enclaves, thus the enclaves are pointless if your threat model includes the US as a adversary
Does this mean the protocol should be thrown away? No. Does this mean Signal shouldn't be used (depends on use case)? No. Signal has value, but its not the ultimate form of privacy and security.
I support projects like Briar because there is till much improvement needed in this space.
Notice: I'm not telling others to "educate yourself", if I didn't want to talk to people I wouldn't be here, or I'd link to the proper discussion. I dislike people who come to social places and act antisocially
-
So Signal does not have reproducible builds, which are very concerning securitywise. I talk about it in this comment: https://programming.dev/post/33557941/18030327 . The TLDR is that no reproducible builds = impossible to detect if you are getting an unmodified version of the client.
Centralized servers compound these security issues and make it worse. If the client is vulnerable to some form of replacement attack, then they could use a much more subtle, difficult to detect backdoor, like a weaker crypto implementation, which leaks meta/userdata.
With decentralized/federated services, if a client is using other servers other than the "main" one, you either have to compromise both the client and the server, or compromise the client in a very obvious way that causes the client to send extra data to server's it shouldn't be sending data too.
A big part of the problem comes with what Github calls "bugdoors". These are "accidental" bugs that are backdoors. With a centralized service, it becomes much easier to introduce "bugdoors" because all the data routes through one service, which could then silently take advantage of this bug on their own servers.
This is my concern with Signal being centralized. But mostly I'd say don't worry about it, threat model and all that.
I'm just gonna @ everybody who was in the conversation. I posted this top level for visibility.
@Ulrich@feddit.org @rottingleaf@lemmy.world @jet@hackertalks.com @eleitl@lemmy.world @Damage@feddit.it
EDIT: elsewhere in the thread it is talked about what is probably a nation state wiretapping attempt on an XMPP service: https://www.devever.net/~hl/xmpp-incident
For a similar threat model, signal is simply not adequate for reasons I mentioned above, and that's probably what poqVoq was referring to when he mentioned how it was discussed here.
The only timestamps shared are when they signed up and when they last connected. This is well established by court documents that Signal themselves share publicly.
This of course, assumes I trust the courts. But if I am seeking maximum privacy/security, I should not have to do that.
They do have reproducible builds for android though? https://signal.org/blog/reproducible-android/
They can't for iOS because it's just not a feature there
Else, there's Molly you can use, but yea, Signal doesn't like it
-
They do have reproducible builds for android though? https://signal.org/blog/reproducible-android/
They can't for iOS because it's just not a feature there
Else, there's Molly you can use, but yea, Signal doesn't like it
Signal's reproducible builds are broken: https://github.com/signalapp/Signal-Android/issues/13565
-
Signal's reproducible builds are broken: https://github.com/signalapp/Signal-Android/issues/13565
Indeed, sorry. Crazy this still hasn't been addressed. It's a really important security check
-
Techcrunch reports that AI coding tools have "very negative" gross margins. In other words, they are losing money on every user.
Technology1
-
-
AOL will end dial-up internet service in September, 34 years after it's debut — AOL Shield Browser and AOL Dialer software will be shuttered on the same day
Technology1
-
-
-
The Debian project is proud to release Debian 13 "Trixie", a major update that brings new features, updated components, and numerous other improvements
Technology1
-
-
European Commission has a "Wifi4EU" initative, provides 93k high-speed private access points across the EU, free of charge.
Technology1