5 ms·

Sure, if self hosting is the most important criteria for you, you can't really beat XMPP. Same goes for a richer ecosystem of 3rd party clients. But those two

Sure, if self hosting is the most important criteria for you, you can't really beat XMPP. Same goes for a richer ecosystem of 3rd party clients. But those two are completely unrelated to security. I mean a self hosted solution can be secure, but it's weird to say that Signal can't compete with XMPP on security because it's not self hostable.

grayhatter 2y ago
> but it's weird to say that Signal can't compete with XMPP on security because it's not self hostable. No it's not. If I could conditionally control if your messages are delivered, and when. Even if I can't see the contents, that's a huge security vulnerability!
- hmmm-i-wonder 2y ago
  You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365
  - grayhatter 2y ago
    > You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. this is the first I've heard this, got a source to prove this is actually true? > Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365 That's not how threat models work, it's not 'more' risk. It's additional work. The risk is the same, signal has to do it, or 'you' have to do it. The risk and level of effort is the same. The only thing that changes is the direct responsibile party. Depending on configuration, it might reduce the risk if you can lower the number of parties you have to trust. I.e. I can verify my servers are up to date, but I have to just trust me bro, that signal's servers are always up to date.
    - some_furry 2y ago
      That's kind of the point of Sealed Sender. If you block delivery of a message, you have no idea who it's for or from.
      - grayhatter 2y ago
        from signal > Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token. I'm probably going to need to read the white paper to actually understand this, because currently I'm confused as to how this doesn't result in knowing the destination. Surely I can reverse the delivery token if I'm in control of the servers? but I was thinking network based disambiguation edit; seems there's (maybe was?) a number of ways to disambiguate targets, users, and contact graphs https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/ https://www.ndss-symposium.org/ndss-paper/improving-signals-...
        some_furry 2y ago
        I should be more precise: Signal's server doesn't know who sent the message, since that information was Sealed. Signal's server does know where to deliver the message to, based on a 96-bit random value generated client-side by the recipient (the delivery token). But it cannot know which user has which delivery token. To understand that, you need to look at the zero-knowledge credentials section of the code. They could randomly drop messages sent to a specific targeted user's delivery token and block messages sent to that targeted user, but they have no way of knowing which user they're targeting. (Also, the client could just enroll a new one if this ever happened and Signal was somehow court-ordered to block delivery to a specific delivery token.)
        grayhatter 2y ago
        Is signal not able to tag and reduce the sealed envelope to a "final" destination network address? I.e. is a sender able to prove that it's impossible for signal servers to do this?

grayhatter 2y ago

> but it's weird to say that Signal can't compete with XMPP on security because it's not self hostable. No it's not. If I could conditionally control if your messages are delivered, and when. Even if I can't see the contents, that's a huge security vulnerability!

hmmm-i-wonder 2y ago
You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365
- grayhatter 2y ago
  > You can't control when "someones" messages are delivered, only when "all" messages are delivered. I.E Signal servers control general availability, not selective availability. this is the first I've heard this, got a source to prove this is actually true? > Moving to a self-hosted service most likely introduces more risk at this point assuming you can keep the service and all related infrastructure up to date and monitored 24/7/365 That's not how threat models work, it's not 'more' risk. It's additional work. The risk is the same, signal has to do it, or 'you' have to do it. The risk and level of effort is the same. The only thing that changes is the direct responsibile party. Depending on configuration, it might reduce the risk if you can lower the number of parties you have to trust. I.e. I can verify my servers are up to date, but I have to just trust me bro, that signal's servers are always up to date.
  - some_furry 2y ago
    That's kind of the point of Sealed Sender. If you block delivery of a message, you have no idea who it's for or from.
    - grayhatter 2y ago
      from signal > Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token. I'm probably going to need to read the white paper to actually understand this, because currently I'm confused as to how this doesn't result in knowing the destination. Surely I can reverse the delivery token if I'm in control of the servers? but I was thinking network based disambiguation edit; seems there's (maybe was?) a number of ways to disambiguate targets, users, and contact graphs https://www.ndss-symposium.org/ndss-paper/improving-signals-sealed-sender/ https://www.ndss-symposium.org/ndss-paper/improving-signals-...
      - some_furry 2y ago
        I should be more precise: Signal's server doesn't know who sent the message, since that information was Sealed. Signal's server does know where to deliver the message to, based on a 96-bit random value generated client-side by the recipient (the delivery token). But it cannot know which user has which delivery token. To understand that, you need to look at the zero-knowledge credentials section of the code. They could randomly drop messages sent to a specific targeted user's delivery token and block messages sent to that targeted user, but they have no way of knowing which user they're targeting. (Also, the client could just enroll a new one if this ever happened and Signal was somehow court-ordered to block delivery to a specific delivery token.)
        grayhatter 2y ago
        Is signal not able to tag and reduce the sealed envelope to a "final" destination network address? I.e. is a sender able to prove that it's impossible for signal servers to do this?