Don't Stand Out.
When you say "Each user can choose a different notification service" you aren't enhancing privacy you are standing out.
When you say "Each group of users can have their own servers" you aren't enhancing privacy you are standing out.
So yeah, it's only for "total normies" in the sense that if you insist on standing out from those "total normies" that's a problem.
Signal is taking advantage of the inherent camouflage of crowds, once you insist on standing out that's gone and you can't get it back.
Using the preinstalled Google services effectively turns your smartphone into spyware. In the standard Android that comes preinstalled on most smartphones, Google services run with system privileges and can collect all kinds of data including location data. If Signal exclusively supports this, it reinforces dependence on Google and discourages people from using versions of Android that don’t include Google’s spyware.
Then don't do that?
Install vanilla LineageOS or GrapheneOS with no GApps. Then install Signal from https://signal.org/android/apk/
The whole point is that it's unusable without Google services due to battery drain. Meta got it right with WhatsApp and a battery-efficient WebSockets implementation for notifications without Google services, but Signal's implementation is poor.
This is an exaggerated take. I've been running Signal on LineageOS for years across at least 5 different phones in exactly this manner with no Google services installed. I'm currently using a Motorola G84 and charge every 2 days with moderate usage; Signal is my primary communication method with family.
The G84 has a very good battery by default though, judging from its predecessor. It can take some additional strain. Something weaker will suffer more.
I have run Signal on LineageOS or GrapheneOS for nearly a decade, no Google services, and I have always had satisfactory battery life, i.e. ~2 days of normal use.
I bought a PinePhone, so I definitely know what truly unoptimized battery life looks like, lol.
This was never an issue with my Pixel. Using my pixel with graphene without google play services resulted in better battery life than stock.
Signal on GrapheneOS with no Google anything here, and it works great.
That doesn't address the criticism that this thread started with:
Unified Push, which works flawlessly on Molly, could easily be implemented in the regular client.
It's a moot point, as Signal isn't going to support self-hosted notification servers any more than it'll support self-hosted communication servers.
Signal works without GMS or any alternative, at the cost of more phone wakeups. This is much more preferable to everyone whose WiFi or data service you use see you connect to "push.myownname.com", or for you to rely in some rando gatekeeping your message delivery.
> everyone whose WiFi or data service you use see you connect to "push.myownname.com"
Mozilla has one. Hell, Signal _themselves_ could host a UnifiedPush server. Not an excuse to say 'you use Google or our app uses 10x the battery'.
OK, that's a fair point.
But not providing one does seem to follow with their "be a normie as much as possible in order to not stand out" mantra, even if (to me) providing that extra service for non-GMS users seems harmless. Maybe it's not, I don't know.
Anyway, however much more battery it uses, from my experience, it hasn't been an inconvenience, the phone still lasts a couple of days without charging.
There is no reasonable reason why they shouldn't support it. Having my cell phone battery drain faster is a much bigger drawback for me than simply hosting my own push server at home.
I'm not sure if the comment above you is correct, but if it is (meaning Signal would benefit from the anonymity of every client being the same/similar, like TOR), then this would go against that.
That being said, I've never heard this mentioned as a benefit of Signal, and I figured the main benefit was y'know robust and proven E2E encryption.
This argument doesn't make sense, Signal is fundamentally not an anonymity tool. It's a privacy tool.
They intentionally store very little data about their users but their "mailbox" model explicitly means that the server (or an attacker) can figure out who is talking to whom. And that's fine! Signal isn't trying to be an anonymity network, so while stuff like sealed sender are nice features it's important to remember that anonymity breaks are explicitly not part of the Signal threat model.
"Don't stand out" only makes sense as advice for anonymity tools to avoid bifurcating the anonymity set -- it doesn't make much sense when you're taking about a service which links your account to your phone number and thus every server request is explicitly identifying you.
One of the goals of Signal is that they do not know who is talking to whom. Sealed sender and all that. This can possibly break down in certain scenarios with some server-side correlation. But they certainly do have a design goal that the social graph is entirely private.
I am aware of sealed sender, I even mentioned it in my comment. ;)
My point is that by construction they are not an anonymity tool, no centralised server can be. They can add features to make it less easy to track users but that's not the same as providing anonymity, and it's important to not confuse the two.
To give an example: my email provider has a feature to auto-encrypt all inbound emails to a PGP public key. Is this a nice feature to make it harder for someone to read my past emails if someone gets access to their infrastructure? Sure. Does this make my emails end-to-end encrypted? Absolutely not. In a similar vein, Signal making social graph correlation harder is a welcome feature but is not the same as making it anonymous.
Yes, I know you're aware of them :) And maybe I'm splitting hair here--I agree with you that Signal isn't as robust wrt anonymity as, e.g. Tor.
Signal explicitly considers anonymity/a private social graph to be a design goal. Their documented considerations of things like sealed sender and use of Intel SGX's remote attestation clearly demonstrate this.
Yes, these measures are imperfect. Like you say, it's a centralized service and has weaker anonymization properties because of that. However, because of its design, to de-anonymize Signal users requires the server operator to do continual, non-trivial work as long as they want to de-anonymize users.
In other words, deanonymization attacks against Signal users works just like any other kind of attack: the question isn't whether it can be done, but whether the attacker has the resources to do it. Presumably you'd consider Tor to be an anonymity tool. Yet, even though they're distributed, deanonymization attacks against certain users can succeed, given enough resources. (I don't mean to imply that Signal is equally resistant as Tor!)
Note: big fan of the work you all are doing at Amutable! I'm following the news eagerly. Best of luck!
Sure, I guess it's more a question of degree.
I still think the original point I was replying to ("don't stand out") doesn't apply to systems with "soft" anonymity like Signal. Even more importantly, arguing that specific features like custom servers or non-Firebase notifications are problematic because they "stand out" is particularly silly -- those features are the exact kind that are already fingerprintable by virtue of Signal's inbox design. Even if the social graph is somewhat anonymised, Signal does not attempt to hide that you are using Signal. (You could argue custom servers leak some data about your social graph but I'm not sure it is much worse than the theoretical leaks we spoke about earlier. And it's kinda notable that when Moxie argued against federated servers as a concept, that wasn't among the arguments he made.)
> When you say "Each group of users can have their own servers" you aren't enhancing privacy you are standing out.
You're also hedging against mandated government backdoors.
A single organisation like signal can easily compelled to add a backdoor (or leave the territory) like the EU is trying to do. Going after thousands of servers individually is a whole different problem.
>You're also hedging against mandated government backdoors.
Let's see the law that allows compelling backdoor into Signal then. AFAIK https://en.wikipedia.org/wiki/Bernstein_v._United_States established code as speech, meaning compelling backdoor is compelled speech, which goes against the first.
https://en.wikipedia.org/wiki/Code_as_speech goes into this in more detail and mentions https://en.wikipedia.org/wiki/Apple%E2%80%93FBI_encryption_d... where the defense was used.
GP already mentioned the EU as an example.
Yes or Canada
And also, do we really trust the US government on this after Snowden?
The rule of law is over.
The reverse is true, if more app support unified push then those using it will stand out less.
There just is a contention between software freedom and privacy that people don't want to acknowledge sometimes. Signal is firmly on one side of the divide, and their software is open source because it is the convention to have the source public and auditable, not because they are interested in user freedom and respect.
It's not that they're not interested in user freedom and respect. They just have different ideas about what's important. If Signal federates, that will bring to the table all sorts of 3rd party clients who will have say in how Signal does things, yet no duty to comply with the Signal's spec sheet and deploy timely protocol updates and features. Any clients not keeping up are damaging the brand, as was in the case of Matrix clients' poor support for E2EE. Then there's the aspect that the larger the organization managing the spec becomes, the easier it is to infiltrate and clog with bikeshedding.
Signal's strength is its security agility and thoughtful feature design, not federation and availability.
But that is my point, there is a contention and they made their call. It is not wrong for them to do so, there are just plenty of people who prefer the other side.
Stand out from what? Are you seriously arguing that the only things keeping Signal from being banned are that it somehow camouflages itself?
Other users. Anonymity only works if you don't paint a unique identification on your mask.
That said, I would like all users to look degoogled.
Signal isn't anonymous. The server has access to your IP addresses and the server can at will build social graphs about the users.
Where Signal's safety in numbers happens is in normalization of end-to-end encryption. Users who want to protect their message content are not standing out from the rest, unlike in e.g. Telegram where the vendor sees with whom you enable secret chats.
> The server has access to your IP addresses and the server can at will build social graphs about the users.
How could it build a social graph? I think most messages are P2P unless the user activates relaying?
Discovery is important and a hard problem, worth making some trade-offs for. Signal published a good blog post about this, including this passage:
> In order to turn the address book on a device into a social graph for Signal, the Signal client needs to be able to determine which of the device’s contacts are Signal users. [...] The obvious problem with this method is that the hash of a user identifier can almost always be inverted. [...] This method of contact discovery isn’t ideal because of these shortcomings, but at the very least the Signal service’s design does not depend on knowledge of a user’s social graph in order to function.
Src.: https://signal.org/blog/private-contact-discovery/
edit: Also, Signal is not peer-to-peer. It is a centralized, client-server architecture.
When they say "social graph for Signal", afaik they don't mean 'on Signal servers' but 'social graph on your phone'. It's a personal social graph that exists on the end-user device.
I don't remember how the hash issue is dealt with, however.
> Signal is not peer-to-peer. It is a centralized, client-server architecture.
It's not a P2P mesh, but Signal's servers are involved only for certain functions. I think communication tx is P2P - to send a message via server (used to hide sender IP address from onlookers and the recipient), you need to enable relaying. Possibly finding the recipient still relies on the server - if I want to send a P2P message to Abel, to what IP address do I send it?
The official signal.org blog post I linked does actually explain how it works. They write that the client sends parts of hashed phone numbers to Signal:
> The client transmits those truncated hashes to the service. The service does a lookup from a set of hashed registered users. The service returns the intersection of registered users. The obvious problem with this method is that the hash of a user identifier can almost always be inverted. Regardless of whether the identifier is a phone number, a user name, or an email address, the “keyspace” of all possible identifiers is too small.
Also: Signal messages are currently never P2P. They always pass through Signal servers, which see (but apparently not retain) your IP and timing metadata. The Signal WebRTC calls are partially peer-to-peer, that is what the relaying in the Signal settings panel is about.
>I think most messages are P2P unless the user activates relaying?
No they're all routed through the servers. It's only the calls that can be sent P2P and you have to opt in for that. The issue is that leaks your IP address to the contact who may not be trustworthy, so it's not used by default.
(Not to object the degoogeling, but:) To create a Signal account, you have to validate a phone number. So Signal is currently largly about privacy, not anonymity.
FWIW I wouldn't know why to message someone if I didn't know who they were. The same goes for them not knowing who I am. What would we even talk about?
The service operated by the incorporated 501c3 has full visibility into who else a user messages and when. This is not good for privacy.
What the non-low-value users are generally looking for is the option to not opt-in to discard anonymity with any potentially involved third parties such as server operators and network operators, and left at the discretion of the users solely.
Other systems have already solved this. One user can be not anonymous while another can choose to not opt-in to not be anonymous.
The users still know who the user on the other side is.
Ahh okay, that makes more sense! Sorry for the snark.
Not sure I follow or understand your argument. There's so many things with which eg Telegram stands out, but it still appeals to normies.
They could still implement these things in the app and put them behind a switch for users who care about independence more than one specific type of anonymity. Explain the tradeoffs on the settings screen.
The only valid reason to be against an optional feature is the maintenance burden, I don't think it's too much here but I also can't speak for the Signal team.
Anyone who has worked with SQL databases and graph databases can't buy this goofy "camouflage" idea.
If you don't know how computers work, yeah it sounds great. But those who do know how computers work see it for what it really is: a bucket of shit.
[dead]
[dead]