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
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.
If you block delivery of a message, you have no idea who it's for or from.
> 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-...
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.)
I.e. is a sender able to prove that it's impossible for signal servers to do this?
See https://signal.org/blog/sealed-sender/ and https://eprint.iacr.org/2019/1416 if you'd like descriptions for the protocols I'm trying to describe in HN comments.
The "most likely" part does a lot of carrying here, and you made my point. The additional work self-hosting is not trivial in this space. Assuming you can either personally dedicate a LOT of time, or personally pay staff people to keep up vs a dedicated team working on this means that the threat model is inverted now.
I self-host a number of services, I'm very pro self hosting. I'm _VERY_ aware there is always a trade off between "I want this to work", "I don't have time to fix this regularly because I have a Job and Family and hopefully other hobbies besides self-hosting a service" and "I need to constantly update and apply changes that sometimes do not gracefully fall into automation or introduce breaking changes".
Now consider that communication is one service and add on self-hosting other services, and the additional updates and knowledge to support it.
Outside of the small group of people that dedicate themselves to hosting and managing their services, which excludes most USERS (its in the name) the threat model is indeed inverted.