I never used it, but I would assume yes after reading the frontpage and the doc. At no point there is a PSK set between sender and reciever, not I see any signs for key exchange between devices.
This is not a definitive answer though as I didn’t read the source code of Nfty, nor the UnifiedPush spec.
Regarding encryption of the push message, from https://unifiedpush.org/developers/spec/android/ :
Push message: This is an array of bytes (ByteArray) sent by the application server to the push server. The distributor sends this message to the end user application. It MUST be the raw POST data received by the push server (or the rewrite proxy if present). The message MUST be an encrypted content that follows RFC8291. Its size is between 1 and 4096 bytes (inclusive).
What’s interesting, and is confusing me about this, is that Ntfy does not adhere to this [1]. I’m not sure how this can be.
References
- “End-to-end encryption (E2E) between clients (Android app, CLI, web app)”. binwiederhier. ntfy/binwiederhier. GitHub. Published: 2021-12-29T02:07:36Z. Accessed: 2024-11-22T05:04Z. https://github.com/binwiederhier/ntfy/issues/69.
It doesn’t matter. Even if the ntfy message was plaintext, that plaintext content would be a UnifiedPush “Push message” which is the RFC8291-encrypted raw POST data.
So, for example, if one were to register Unified Push notifications with Matrix using Ntfy, the creation of the encrypted Unified Push notifications would be done by the Matrix Unified Push Gateway which then gets handed off to Ntfy? Is there a way to confirm that the received notification is indeed encrypted?
You could have a look at the messages ntfy is passing around using its trace function: https://docs.ntfy.sh/troubleshooting/
I enabled logging in the Ntfy app, and, upon receiving a message in Element X, it showed the Matrix notification push message in plain text in the logs. If Ntfy indeed doesn’t know anything about Unified Push and is just the medium through which a Unified Push message travels, then I would think that it wouldn’t be the service decrypting the message, yet it is decrypted in the logs.
Yeah, I was doing some more reading and I think it might only be the newest version of the UnifiedPush spec which requires the message to be encrypted.
- https://codeberg.org/UnifiedPush/specifications/pulls/1
- https://github.com/binwiederhier/ntfy-android/pull/98
- https://codeberg.org/iNPUTmice/Conversations/issues/428
I noticed that the examples given on https://codeberg.org/iNPUTmice/up/src/branch/master/README.md are unencrypted.
Yeah, I was doing some more reading and I think it might only be the newest version of the UnifiedPush spec which requires the message to be encrypted.
The question I would then have is: Who would be responsible for updating their system to support this (ie the Unified Push encryption)? Say if we, for example, look at Matrix. Would Matrix need to modify their notification API? Would the Matrix gateway in Ntfy need to be modified? Would some other component of Ntfy be modified? Would the distributor app need to be modified? Would the end-user application need to be modified?
Yes, I believe all the messages are in plain text, and it’s up to the server not to log it.
It is possible to e2ee the message content yourself tho.
Edit: it looks like ntfy.sh specifically keeps messages cached in memory for a few hours befor discarding them. https://docs.ntfy.sh/config/
Isn’t this contradicting the Unified Push spec? It states:
Push message: This is an array of bytes (ByteArray) sent by the application server to the push server. The distributor sends this message to the end user application. It MUST be the raw POST data received by the push server (or the rewrite proxy if present). The message MUST be an encrypted content that follows RFC8291. Its size is between 1 and 4096 bytes (inclusive). [1]
References
- Unified Push spec. Unified Push. Accessed: 2024-11-22T05:07Z. https://unifiedpush.org/developers/spec/android/
- “Developers/Specifications/Android”. §“Resources”
- Unified Push spec. Unified Push. Accessed: 2024-11-22T05:07Z. https://unifiedpush.org/developers/spec/android/
Yes, they can read the data. But apps like Molly (Signal Fork) send encrypted notifications. So, the time and some other metadata may be read by the server, but the content and contact won’t be visible in plain text.
Yes, they can read the data.
Isn’t this contradicting the Unified Push spec? It states:
Push message: This is an array of bytes (ByteArray) sent by the application server to the push server. The distributor sends this message to the end user application. It MUST be the raw POST data received by the push server (or the rewrite proxy if present). The message MUST be an encrypted content that follows RFC8291. Its size is between 1 and 4096 bytes (inclusive). [1]
References
- Unified Push spec. Unified Push. Accessed: 2024-11-22T05:07Z. https://unifiedpush.org/developers/spec/android/
- “Developers/Specifications/Android”. §“Resources”
- Unified Push spec. Unified Push. Accessed: 2024-11-22T05:07Z. https://unifiedpush.org/developers/spec/android/
I think a lot of comments have missed that ntfy.sh does not use UnifiedPush, the ntfy server is a UnifiedPush provider and the ntfy app is a UnifiedPush distributor.
The app that wants to provide the notifications would then be said to use UnifiedPush, right?
Not really. “Use” isn’t a well defined word in this context.
The ntfy server/client and the protocol it uses is merely the conduit for the UnifiedPush protocol. Sort of like how tls or ssl are a conduit for http.
In its typical primary use, ntfy is unrelated to UnifiedPush.
So, in this image, if the application server, the push server, and the distributor app have nothing to do with Unified Push, then where exactly does it come into play? What exactly is it doing? I was of the belief that Unified Push standardized the notification communication protocol with the application server, replacing things like Google Firebase (which, iiuc, is equivalent to the push server in the above diagram, and the distributor app being built into the phone — ie Android). What’s also confusing me in all this is what exactly a push gateway is doing. Ntfy, for example, implemented a Matrix Gateway [1][2], but I’m not exactly sure the point of that if it’s not doing anything with Unified Push (Matrix uses it’s own push API [3])
References
- “Consider Including a Matrix Gateway endpoint as part of ntfy”. MayeulC. binwiederhier/ntfy. GitHub. Published: 2022-06-16T16:55:41Z. Accessed: 2024-11-23T00:25Z. https://github.com/binwiederhier/ntfy/issues/319.
- “Matrix gateway” (#326). binwiederhier. binwiederhier/ntfy. GitHub. Published: 2022-06-16T16:55:41Z. Accessed: 2024-11-23T00:25Z. https://github.com/binwiederhier/ntfy/pull/326.
- “Push Gateway API”. “Matrix Specification” (Version: 1.12). Matrix. Published: 2024. Accessed: 2024-11-23T00:23Z. https://spec.matrix.org/v1.12/push-gateway-api/.
I mean ntfy’s primary purpose is not dependent on UnifiedPush – all UP functionality could be removed and ntfy would still work as intended.
Ntfy server knows how to be a UP gateway, and relays those messages to the ntfy app, which knows how to be a UP distributor.
As far as I understand it, a client app using UP to recieve push notifications does perform a registration step with the UP gateway (via the distributor app which communicates with the gateway via its own transport), which sets up and responds with the api endpoint details, which the client app relays to its servers, which can then send UP notifications via the specified gateway.
As far as I understand it, a client app using UP to recieve push notifications does perform a registration step with the UP gateway (via the distributor app which communicates with the gateway via its own transport), which sets up and responds with the api endpoint details, which the client app relays to its servers, which can then send UP notifications via the specified gateway.
So, if there was to be encryption done by UP, it would be handled by the gateway? For example, for Matrix, it would then be handled by the Matrix gateway in Ntfy [1]?
References
- “Matrix gateway” (#326). binwiederhier. binwiederhier/ntfy. GitHub. Published: 2022-06-16T16:55:41Z. Accessed: 2024-11-23T00:25Z. https://github.com/binwiederhier/ntfy/pull/326.
