Recent searches
Search options
PSA: We've received questions about push notifications. First: push notifications for Signal NEVER contain sensitive unencrypted data & do not reveal the contents of any Signal messages or calls–not to Apple, not to Google, not to anyone but you & the people you're talking to. 1/
In Signal, push notifications simply act as a ping that tells the app to wake up. They don't reveal who sent the message or who is calling (not to Apple, Google, or anyone). Notifications are processed entirely on your device. This is different from many other apps. 2/
What's the background here? Currently, in order to enable push notifications on the dominant mobile operating systems (iOS and Android) those building and maintaining apps like Signal need to use services offered by Apple and Google. 3/
Apple simply doesn’t let you do it another way. And Google, well you could (and we've tried), but the cost to battery life is devastating for performance, rendering this a false option if you want to build a usable, practical, dependable app for people all over the world.* 4/
So, while we do not love Big Tech choke points and the control that a handful of companies wield over the tech ecosystem, we do everything we can to ensure that in spite of this dynamic, if you use Signal your privacy is preserved. 5/
*(Note, if you are among the small number of people that run alt Android-based operating systems that don't include Google libraries, we implement the battery-destroying push option, and hope you have ways to navigate.) 6/
@Mer__edith any thoughts on adding ad-hoc Bluetooth mesh capabilities to Signal? Would be nice to have a fallback at least locally when off-network
@Offbeatmammal @Mer__edith It makes things a bit complicated. Have you tried out Briar?
@robert @Mer__edith that's what I use at the moment, but seems to be Android only :(
@Offbeatmammal @Mer__edith This is something I genuinely would find useful on a daily basis, as I have a long commute by train with no wifi and unreliable cellular. it would be nice to have a reliable way to send messages to my SO sitting next to me (if I wanna share files, or genuinely send texts for various reasons) even without internet, which really has no reason not to work, since we really are within Bluetooth range, and purpose-built things like Nearby Share already allow communication between our phones at this range.
and although there definitely are some solutions for this already, it would be nice to have something that also works via the internet, still preserves privacy, and kinda most importantly for me, is just comfy to use (as Signal genuinely is)
@Mer__edith Battery Destroyer sounds like the #kaiju that will save us all from #Tesla
@Mer__edith Google services already does a lot to increase battery drain in the background so I'd consider not having it running all the time a decent trade for security over convenience.
@cienmilojos @Mer__edith
The logic behind its existence is sound. You do not want 30 background services in constant contact with 30 different servers because it kills the battery. With Google services there is only one service in contact with one server, but that only works if everyone sends their notifications to the same server. Why they don't just offer end to end encryption is beyond me though.
@Mer__edith Would love to see unifiedpush implemented. Google free push with less battery destroying.
@lgehr
Same for me.
I already use unified push for several services and it would be really nice if signal supported it, too.
@Mer__edith
@Mer__edith OK, aber wie wäre es wenn man eine entsprechende Schnittstelle einbaut, um z.B. UnifiedPush nutzen zu können. Damit könnte man jeden selbst entscheiden lassen was er nutzt. Der Verbrauch bei dem Signal Clon liegt gerade einmal bei... 1,88%/h ! Mit UnifiedPusch ! Wo liegt also wirklich das Problem?
Auch gerne in Englisch...
OK, but how about installing a corresponding interface so that you can use UnifiedPush, for example. This would allow everyone to decide for themselves what they use. The consumption of the Signal Clon is just... 1.88%/h! With UnifiedPusch! So what really is the problem?
@noname @Mer__edith While it mayb be 1.88% for your phone, it could be much higher for phones with a smaller or older battery.
There are millions of smartphone users who do not have electricity at home (and some don't even have a home). For these users, every hour of battery life counts.
@newstik @Mer__edith
Therefore an implementation that can be switched on or off. So that everyone can decide for themselves how they would like it
@noname @Mer__edith A wonderful idea in an ivory tower. For maybe 20k users.
I think it's best to reduce to the max for the next 20 million.
@newstik
If during communication - time, participants and the corresponding program or app are announced (assuming EVERYTHING is there) then THAT IS metadata. Or what do you think such data consists of? Even if you write for Heise, you should make sure that you can provide evidence of what you have written.
@noname The point is that the participants are not announced when Signal triggers a notification.
The fact that you have activated Signal (if you do) is already known to those who want to know. That is not a secret.
The only new information is that there is a ping to wake up the app. That is metadata, but of very little insight.
@newstik Just saying... How do you know what data is coming in?
@newstik
There is a bunch of metadata that is made available when Signal links your Signal account to your Google device ID (which is needed to send push notifications):
- If your device has a Google account signed in (most do to install Signal from the Play Store) your Signal account will be linked to your Google account
- If you connect your phone to any wifi network, your Signal account will be linked to that wifi's IP address, often revealing your exact location to authorities
@newstik
- If you have any other apps installed that use push notifications, those would be linked to your Google device ID and thus your Signal account as well. Authorities can then link any data they get from those other apps also to your Signal account (and thereby phone number and identity).
@larma Yes of course. Signal is not for anonymous communication, and doesn't claim to be.
What's the additional information an intelligence service could learn from a Signal push message or push service token?
@newstik @noname @Mer__edith Signal actually already decided to support Google-free devices, the problem is their implementation. Signal provides direct download links and does not require Play Services. Using #UnifiedPush would be a big improvement in what they already support. So we should focus on real world solutions that exist right now: keep Google push for those with Play Services, and use an existing FOSS solution for those without.
@Mer__edith Thank you for your openheartness. Perhaps for what its worth. On Pixel 7a without google my phone with signal my batteryblasts a day and a half. I would say pretty good job oft yours! My humble thanks 
@Mer__edith This probably very much depends on the device and usage intensity, but the "battery destroying" option on grapheneos on pixel6a is actually very mild for me, and even with a bunch of other apps doing push not through google services I get around 2 days of battery life. And thanks for your work! :)
@ar @Mer__edith I also run GrapheneOS on a Pixel 6. With Android 14 you now have a more detailed view of battery usage per app within 2h periods. Signal consumes about ~70 % for each period. However I honestly don't know how to interpret these values but they're much higher compared to other apps. This gives me an average lifetime of one day.
I'm maybe going to test Molly (not the drug 
) with Unified Push.
Just a note: Threema Libre is also contantly running in background but consumes a lot less with ~2-4 %.
@Mer__edith Thanks for that clarification and for the good work!
BTW, for the ones who'd like to try out the battery/privacy trade-off, would it be technically feasible to add in parameters a toggle switch, between use of Play Services notifications and homemade notifications, keeping Signal in the background all the time? From what I've read, on install, Signal checks if the PS are ON and uses them if so, otherwise doesn't. Do we have to uninstall PS, then Signal, to remove usage of PS notif?
@Mer__edith if Signal would implement #unifiedpush I'd be so happy!
@Winterstar @Mer__edith exactly, implement Unified Push and let us (the users) choose which push server we want to use.
@madcap @Winterstar @Mer__edith
Yes I'd love to have Unified Push as an option!
@Mer__edith How does it end up being battery-destroying? Shouldn't it just be waiting on a socket that has no data until there's a notification to be processed, with the TCP keepalive set on the socket options so kernel rather than userspace deals with stupid NATs that would otherwise drop it?
@dalias
There are a couple of options for notifications.
The most battery saving design is to have your app being woken up whenever a notification is received. This way, you app does not use battery while there is nothing for it to do. The dominant solution in this space is integrated into Google Play (proprietary). The opposite site of the spectrum, and the solution Signal chose, is for the app to require permission to stay awake all the time polling for notifications.
@Mer__edith
@ck @Mer__edith You're explaining this at several levels of simplification below what would be relevant to me...
@ck @Mer__edith Specifically, I'm asking what kind of polling they're doing, and why, when the standard correct way to do this kind of operation is sleeping (in the confusingly named poll function) waiting for input on a socket, where the kernel is responsible for waking you only once input is available. There are hideous NAT connection dropping issues related to this, but solvable with a mix of TCP keepalive (also kernel side, so virtually free) and waking & reconnecting on closed sockets.
@dalias Essentially, Android apps are not native Linux programs. They run on top of a virtual machine that abstracts away the operating system capabilities to a degree deemed necessary by Google.
Specifically, when your app is sent to sleep by the VM because of inactivity, your socket will time out. Android is a Linux in name only and the abstractions put in place by Google do not support (or rather: not allow) what you suggest.
@ck That's not true at all. For example see the ConnectBot ssh client, which keeps ssh connections open in the background just fine. There is no "VM", but there is nasty auto-killing which you either need to suppress via an explicit backgrounding action (which shows a persistent notification unless the user opts to hide it) or you need to tell the user to disable "battery optimization" (actually pessimization) for your app and deal with the fairly rare remaining bg kills.
@dalias Precisely, the background action is used to keep the socket alive because the app will not be sent to sleep (battery optimized). This is also what Signal does for their websocket connection which is used to listen for push notifications. The thing is that this background notification is not free in terms of battery usage. Using a service like FCM to wake up you app would safe on this background service, thus saving on battery.
@ck It absolutely is free - provided your program is not doing anything idiotic. The Android notion of "sent to sleep" is not needed to *actually* sleep, which is a POSIX notion and a much better design. A task which is blocked on poll() does not use any more battery than one that doesn't exist at all, and it uses *less* than one that Android has "sent to sleep" because there is zero overhead to restart it on the event when it arrives.
@dalias
The vexing part is that @signalapp (seemingly categorically ) refuses to cooperate with the rest of the FOSS world to integrate with open solutions, which already exist. Instead, their spokespeople like
@Mer__edith prefer to talk down to people who, for whichever reason can't or don't want to run proprietary Google services on their Android phone.
@ck @dalias @signalapp this is a very rude comment that misunderstands our choices and commitments. I, also, do not *want* to run corp software. But in a world where a few companies own and/or otherwise control most of the infra we all rely on, INCLUDING choosing which FOSS options receive support (via hiring their maintainers, funding via Linux Found etc), it's an unhelpful fantasy to paint operating in this ecosystem, shaped by these forces/actors, as a "choice" made out of obstinacy/stupidity
@ck @dalias @signalapp There's also a reckoning to be had within the FOSS community IMO, which in the 1990s took its eye off market actors even as it remained vigilant about government surveillance/overreach. The acceptance of corporate tech (and implicitly its surveillance business model), led by folks like ESR via the break from Free software to "open source," did a lot to get us here.
@Mer__edith @ck @dalias @signalapp
On the other hand, one could argue that it was the absolute ideological dogmatism of RMS and his followers that led to corporates to go their own way.
@julf @ck @dalias @signalapp Sure. Yes. I would argue that assholes abound, and that this--and how RMS was allowed to keep his crown for so long in spite of his rigid, ungenerous dogmatism and shitty behavior--needs to part of said reckoning.
@AngelaScholder @julf @ck @dalias @signalapp Richard Stallman
@Mer__edith @julf @ck @dalias @signalapp That helps, thanks.
@AngelaScholder
The ESR mentioned above is Eric S Raymond author of the Cathedral And The Bazaar and right wing ideologue.
@Mer__edith @ck @dalias @signalapp
Corporate surveillance *is also* (indirect) government surveillance. And with a bit of luck, it's not a government you are able to vote for.
@VincentTunru @ck @dalias @signalapp Yes, this is true.
@Mer__edith @ck @dalias @signalapp The world has paid such a high price for the founding ideology of the FOSS movement's lack of political consciousness around capitalist dynamics. "Markets produce just outcomes / markets naturally punish bad actors / small businesses will save the world" in all its forms (FOSS by no means alone) led directly to today's tech surveillance/policing/military-industrial oligarchies - against which we must build broad, powerful coalitions of ordinary people.
@jplebreton I would argue they were aware of the dynamics and were 100% pro-capitalism. The GPL, in particular, is very much a capitalist tool, and there isn’t much energy around fixing it.
Some of the old guard have made it very clear, open source is, and was, capitalist. Especially when the ideas of a communist public license or an anti-capitalist license come up.
@jollyrogue @jplebreton @Mer__edith @ck @dalias @signalapp @be
Do you have an example or link to a communist public license?
@marcusgreen @jollyrogue @jplebreton @Mer__edith @ck @dalias @signalapp @be
Have a look here and the "More reading & licenses" part at the bottom of the website:
https://anticapitalist.software/
@jollyrogue @jplebreton @Mer__edith @ck @dalias @signalapp @be do you have some more details on why you consider GPL a capitalist tool?
@frox Sure. It’s been a while, but these are some off the top of my head.
A long time ago, early ‘80s, RMS used to sell tapes of Emacs code, and this frames the outlook of the GPL license. He used to do fairly well with this from what I’ve read.
The GPL defines distribution as external distribution, and corps, like Google, have used this loophole to modify the code without having to distribute their changes. The APGL is better about this, but there are still ways around the license.
The GPL doesn’t specify the code released to the public has to be complete or buildable by the public. Parts can be left out, and the tooling to build the project doesn’t have to be public. VS Code is a good example of this. The code in the repo is not a complete project. It’s “open source”, but getting an exact copy of the binary as shipped by MS is not possible by building VS Code from the code repo. Granted the industry needs to do better about creating reproducible builds, and that muddies the waters a little bit.
Next, GPL allows for code which is available on request. I’ve personally seen a “open source” company use this to restrict access to their GPL code, and OpenBSD used to razz Linux distros about having a public CVS server. Plus the recent moves by RH, in regards to RHEL sources, is exactly how the GPL is supposed to be used.
The FUD around the GPL makes it sound scarier than what it is. It’s really pretty mild, and it’s more copyright of center than copyleft.
So applying such a criticism to Free Software licensing is nonsensical. Obviously is solely focused on user Freedom, as it is indeed the only thing it could meaningfully address.
And even then, while the ideology stands on its own, the licenses exist solely as hacks to repurpose part of a malicious system to hinder other actors within that system for the benefit of users.
@lispi314 @ck @dalias @Mer__edith @signalapp You've completely misinterpreted what I said. There's a reason I mentioned the movement and nothing about licenses; I actually agree that licenses are an ineffective instrument beyond a narrow domain of usage. It's the advocacy and policies of the FOSS movement as a whole that have failed to live up to its rhetoric and contributed to the current dysfunctional order, and we need explicitly non-ancap/non-libertarian core tenets to fight that.
The movement which did get significantly off the ground is the *Open Source* movement that was expicitly pushed and promoted by corporations and their supporters specifically because it misses the point. Indeed Open Source is not truly liberatory and indeed it *doesn't* center user freedom at all. User freedom is so little of a consideration it has no mention in any of the criteria (https://opensource.org/osd/) used to recognize whether a license is Open Source.