> What "proprietary blobs" does Signal have?

As they say in the Github readme, FCM and Google Maps.

FCM doesn't technically require a blob — it's just that Google wants you to think it does. I reverse engineered their library and it turned out to be a criminally over-engineered wrapper around two broadcast receivers. So, the Mastodon app is proudly the first app ever to both support FCM push notifications, and be 100% open-source.

FCM = Firebase Cloud Messaging, a messaging and notification service run by Google. https://en.wikipedia.org/wiki/Firebase_Cloud_Messaging

I reverse-engineered the notification infrastructure in Android, but for me it was the desire to be able to use customer-provided Google API keys ("google-services.json").

The protocol itself was easy, but my problem was that Google Play Services have a special permission to exempt itself from power management. And more importantly, grant that permission temporarily to the individual apps when they have a notification. I don't think I ever found out how to work around this.

>As they say in the Github readme, FCM and Google Maps.

Thanks, I didn't notice that. Reading this, I'm kind of surprised that Signal doesn't offer an OpenStreetMaps build as it seems like it'd be more inline with their philosophy.

The app doesn't even recognize geo:.. links, which makes degoogling rather hard.

Oo, do you have a link for your implementation? I will soon be looking at creating a library to support FCM (android push notifications) in Android apps written in Rust. And having a simpler interface with the OS (esp. if it therefore doesn't require building a non-syste library) would be incredibly helpful.

Looks like this is the first commit where it was added: https://github.com/mastodon/mastodon-android/commit/a0cbf0fa...

Thanks! It looks like that repo is GPL though, which I respect but isn't going to work for my usage (where I'm trying to build a generic UI toolkit that can be used by all sorts of applications including closed source ones).

It's just two broadcast receivers (one for receiving the push token, another for receiving actual notifications), and one broadcast sender to ask GSF to give you a token. This code is so trivial it's not even worth separating into a library.

Here's how you request a push token:

    Intent intent = new Intent("com.google.iid.TOKEN_REQUEST");
    intent.setPackage("com.google.android.gms");
    intent.putExtra("app", PendingIntent.getBroadcast(context, 0, new Intent(), PendingIntent.FLAG_IMMUTABLE));
    intent.putExtra("sender", FCM_SENDER_ID);
    intent.putExtra("subtype", FCM_SENDER_ID);
    intent.putExtra("scope", "*");
    intent.putExtra("kid", "|ID|1|");
    context.sendBroadcast(intent);

Here are the two receivers:

    <receiver android:name=".PushNotificationReceiver" android:exported="true" android:permission="com.google.android.c2dm.permission.SEND">
        <intent-filter>
            <action android:name="com.google.android.c2dm.intent.RECEIVE" />
        </intent-filter>
    </receiver>
    <receiver android:name=".api.PushSubscriptionManager$RegistrationReceiver" android:exported="true" android:permission="com.google.android.c2dm.permission.SEND">
        <intent-filter>
            <action android:name="com.google.android.c2dm.intent.REGISTRATION"/>
        </intent-filter>
    </receiver>

The first one is where you get notifications. The parameters you sent from the server will simply be your intent extras.

The second one is where you get push tokens. There will be a "registration_id" extra string which is your token. It may start with "|ID|1|" (the "kid" parameter from the request, not quite sure what it does), in which case you need to remove that part.

You want to refresh your push token every time your app gets updated and also just periodically if you haven't done it in a while. I do it every 30 days.

This is also what UnifiedPush lib to use FCM does (https://codeberg.org/UnifiedPush/android-embedded_fcm_distri...)

Which is documented in this gist: https://gist.github.com/mar-v-in/2a054e3a4c0a508656549fc7d0a...

Coming from the npm world, I see enough code for at least two libraries.

But seriously, write this as a blog post, more people need to know about this, and I'd like to have something "authoritative" to send references to.

Here is a blog post to use the play services, without the proprietary lib and API: https://unifiedpush.org/news/20250131_push_for_decentralized...

And there is this gist for the app side, if you need something to share: https://gist.github.com/mar-v-in/2a054e3a4c0a508656549fc7d0a...

Their comment would technically be proprietary code since there's no license alongside it, but grishka wrote the original implementation of the reverse engineered code in that mastodon commit in the first place. So I'd imagine it's free game to use it as a reference (IANAL)

Grishka expresses that the code is trivial. Trivial inventions are not covered by patents. I believe, therefore, that a license for trivial code is not necessary.

But if someone knows better I would appreciate any correction. Legal matters are seldom clear or logical. Your jurisdiction may vary, etc etc.

In case there are any doubts, consider this code and its description public domain.

But then I'm not sure how much code is enough to be considered copyrightable. Is "2*2" copyrightable? Clearly not, because it's too trivial. Where is the line?

A long standing question, I think Joel mentioned such a question once on the Stackoverflow blog.

Thanks, Grishka.

Patent != copyright. You can patent an algorithm (e.g., Adaptive Replacement Caching, which was scheduled to go into public domain this year but unfortunately got renewed successfully) but when it gets to the level of an actual specific implementation, it's a matter of copyright law.

It's why black-box clones where you look at an application and just try to make one with the same externally-observable behavior without looking at the code is legal (as long as you don't recycle copyrighted assets like images or icons) but can be infringing if you reuse any of the actual source code.

This was an issue that got settled early on and got covered in my SWE ethics class in college, but then more recently was re-tried in Oracle v Google in the case of Google cloning the Java standard library for the Android SDK.

I have no idea how copyright applies here. StackOverflow has a rule in their terms of use that all the user-generated content there is redistributable under some kind of creative commons license that makes it easy to reuse. Perhaps HN has a similar rule? Not that I'm aware of, though.

This is a copyright question not patent one.

If you need something permissively licensed, I believe microG also has implementation of the notification protocol: https://github.com/microg/GmsCore/blob/cb9be8f682d7649dae23b...

It's Apache 2.

Please consider supporting https://unifiedpush.org/ in addition to/instead of FCM.

Maybe the first but not the only one. Ltt.rs (an email client using JMAP) does this as well. BTW you can also directly deliver WebPush notifications to FCM servers. No need for a proxy/rely run by the app developer.

Ltt.rs has support for both UnifiedPush and FCM and is fully open source. The code difference between UP and FCM is very very minimal since - as I said - both are just WebPush endpoints.

Firebase, GMS (Google Mobile Services). The Alphabet Corporation is part of many security and privacy conscious users' threat model, and these users aren't generally thrilled about leaking even limited message metadata like timing to their adversary, particularly when that adversary is known to cooperate with global passive adversaries.

There are actually two builds of Molly: Molly and Molly-FOSS. IIRC Molly uses regular Firebase, which can be faster and more reliable but comes with the above tradeoffs, while Molly-FOSS uses UnifiedPush.

Your point about exercising caution with forks of encrypted messaging apps is a great rule of thumb, and in general, social proof should NOT substitute for competent software security specialists reading and evaluating source code, but given you seem to trust GrapheneOS, it's worth noting that they've formally endorsed Molly: https://xcancel.com/GrapheneOS/status/1769277147569443309

> Your point about exercising caution with forks of encrypted messaging apps is a great rule of thumb, and in general, social proof should NOT substitute for competent software security specialists reading and evaluating source code

Also a great point :) And thank you for the reference.

UnifiedPush not works if you not use Molly exclusively on one device. So of you sync between Signal on Win desktop and Android device, your battery drain faster.

OTOH it's nice to have an alternative client. If E2EE messenger system is going to lock itself down hard, trying to "protect" itself from the user even harder than third party adversaries, then I personally see no point - might as well use Whatsapp.

I miss the times IM software respected, or at least didn't fight hard to defeat, the end-user's freedom to computing on their own device, which includes viewing and sending messages through whatever interface they see fit, including indirectly as part of a script/automation. But that was all before E2EE era, hell, before mobile dominance.

  > might as well use Whatsapp.

  - still scrapes metadata
  - run by company who's entire objective is to profile you

Stop being so ridiculous. You can criticize Signal (and there's plenty to critique) but that's just silly. What, should we also just use telegram where E2EE is off by default?

You know signal is open source, right? That's why Molly exists. They can run their own servers too.

Now I wish you could do both. Talk in both signal and the decentralized molly servers. I wish signal had a mesh like feature since it's way harder to snoop on conversations if you have to be physically near. I even wish Signal made the signal sticker site accessible from inside the app. There's tons of things they should do but let's not pretend that just because they're not perfect that we should use apps from a company whose motto might as well be "be evil".

> What, should we also just use telegram where E2EE is off by default?

There are plenty of others, all with their pros and cons.

Ultimately,the network effect is usually the hardest parameter to overcome.

Ironically, the only person who mentionned wanting to use signal instead of whatsapp in my network circle is my 71y old mother.

You should listen to your mother.

edit: lol, i assumed you were the OP. ignore me

> - still scrapes metadata

> - run by company who's entire objective is to profile you

And? Pick your poison. Being profiled by Meta isn't high enough on my threat board to be worth switching to E2EE as a countermeasure; in fact, I only use E2EE because Meta forced it on me with Whatsapp (new network effects) and by enabling it in Messenger (old network effects).

But that's besides the point. The point is, I did not expect such an alignment of outcomes between user-hostile corporations and grassroots OSS developers, as both fight to saturate the IM space with network effects-driven apps that disenfranchise end users "because security".

I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification? All more ways to protect the integrity of the network and ensure the user isn't accidentally stripping E2EE by doing something silly like perusing their messages in ways not prescribed by the developer?

> What, should we also just use telegram where E2EE is off by default?

I don't like it because it made other choices that led to their larger network being infested with scammers and all kinds of shady types, but at least the client itself doesn't suck :).

You can't send messages on WhatsApp w/o giving Meta read access to all of your contacts. Nice of you to give up your friends.

You're being pretty disingenuous and we've talked enough over the years for me to know you know you are being too. So why?

  > I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification? 

No, why would you think so? They were very against the Europe encryption issue[0]. You can also go check Meredith's Twitter[1] or Moxie before her. Their stance on things have been consistent and clear.

But does Signal comply with government warrants? Yes, absolutely. But they don't get many requests because they designed their program to assume Signal is an adversary to the user[2]

  > I don't like it because it made other choices that led to their larger network being infested with scammers and all kinds of shady types, but at least the client itself doesn't suck :).

Does it? Or have you made an assumption? I get a spam messenger on Signal maybe twice a year. Over SMS about 10 times a week (though a bit more than half are auto blocked), over phone I get at least 5 calls a week but sometimes I get that in a day, over WhatsApp I get a few a month. So I don't really buy your argument, but I'm only a sample size of one. But I also know there's no technical reason for your argument either. I'm also pretty sure we've had this conversation in the past, so what's up? You're one of the most active HN users[3], you're easy to remember.

[0] https://signal.org/blog/uk-online-safety-bill/

[1] https://x.com/mer__edith

[2] https://signal.org/bigbrother/

[3] For anyone interested https://news.ycombinator.com/leaders

>> I imagine Signal is also more than happy about remote attestation and upcoming Android developer verification?

> No, why would you think so? They were very against the Europe encryption issue[0]. You can also go check Meredith's Twitter[1] or Moxie before her. Their stance on things have been consistent and clear.

Never was a fan of Moxie, and I'm not going to read Twitter backlog right this moment to confirm what Meredith thinks, but my reasoning here is pretty simple: remote attestation and developer verification are tools that enable what Signal seems to want, which is to be its own walled garden with only one app from one official source - this is necessary for them to deliver on the promises of privacy and security they make.

>>> What, should we also just use telegram where E2EE is off by default?

>> I don't like it because it made other choices that led to their larger network being infested with scammers and all kinds of shady types, but at least the client itself doesn't suck :).

> Does it? Or have you made an assumption? I get a spam messenger on Signal maybe twice a year. (...)

Here I meant Telegram, not Signal. I don't get any spam on Signal at all, but then hardly anyone in my circles uses it. WhatsApp, maybe few times a year. Telegram, all the time, and I only keep it because my local Hackerspace moved over to it from IRC, + it's actually useful for some automation here and there.

People have different preferences; not everyone sees privacy from powers that be as the only requirement. I for one care more about my freedom of computing on my own device; I'm not that worried about my shitposting remaining private. I don't like the push for E2EE messaging in its current form, because I see incentives of both megacorps and OSS devs align against my own. I speak up, because messaging is inherently network-effects based, and I don't want to end up in a situation where all communication goes through end-user-opaque black boxes, regardless of whether they're corporate or community-made.

> I'm also pretty sure we've had this conversation in the past, so what's up?

I know your username and remember us having some back-and-forth on various topics, but I don't recall this particular one.