> A lot of sites out there are still not supporting IPv6 because ... you'll never guess, but dealing with DDoS on IPv6 where your attackers can rotate through addresses quickly is not easy.
So now everyone should acquire as many IPv6 addresses as possible so they can spread their services over many /64s so if their server gets compromised and put on a blacklist somewhere they can just burn that /64 and move on to another?
Making this argument whilst ignoring the trade-offs of federation (that Signal has historically addressed) is somewhat disingenuous and a little fundamentalist.
do you have any breakdown on the trade-offs? Most HN commentary focuses on FUD around the signal founder rather than technical reasons why it shouldn’t be federated and would love to understand them better
You can sort of convolute a reason why 401 Unauthorized is valid, based on the fact that most systems which control access to resources have a (often implicit) policy that users for whom the identity is not known are not allowed to access anything.
Therefore the request is unauthorized because the server wasn't able to authenticate the user. But that's still not consistent with 403 though, so it's not very satisfying.
But this also speaks to one of the nubs of the terminology issue. "Actors" are authenticated, "Actions" are authorized.
Yeah, I think if they were renaming these response codes today, they’d name them something more like “401 Not Authenticated” and “403 Not Authorized”, but it’s too late for that. And I personally think you can say that either an actor or an action is “not authenticated.”
> Good luck getting the personal phone number of an EU Commissioner. You can't vote for who decides things in the EU. You can vote for MEPs but they don't decide things.
Replace "EU commissioner" with "government minister" and you've just described the UK, where we also don't elect the people who decide things (the cabinet).
> Law enforcement asks signal if they have an account for a phone number, signal saying "yes, here's when they created it".
Law enforcement says that the suspect chatted with some username/told people to contact him by his Signal username, then they go to Signal and request the linked phone number, which is then linked to the ID shown when the card was bought.
This only works as long as the username is active/unchanged. It would probably be better if usernames were never linkable to phone numbers, but if your threat model requires a persistent, non-ephemeral username to remain anonymous when targeted by law enforcement that has access to your telecom records and warrants... that's going to require a pretty high level of opsec.
The UX on usernames in Signal might be non-ideal. It might be helpful to have a toggle that regularly cycles your username if that's important for your threat model.
reply