• Dessalines@lemmy.ml
    13·
    19 days ago

    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/

    • Kalcifer@sh.itjust.worksOP
      1·
      1 day ago

      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
      1. Unified Push spec. Unified Push. Accessed: 2024-11-22T05:07Z. https://unifiedpush.org/developers/spec/android/
        • “Developers/Specifications/Android”. §“Resources”
  • nutbutter@discuss.tchncs.de
    81·
    19 days ago

    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.

    • Kalcifer@sh.itjust.worksOP
      1·
      1 day ago

      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
      1. Unified Push spec. Unified Push. Accessed: 2024-11-22T05:07Z. https://unifiedpush.org/developers/spec/android/
        • “Developers/Specifications/Android”. §“Resources”
    • dracs@programming.devEnglish
      5·
      19 days ago

      For Signal/Molly, it’s less that the notification is encrypted as I understand it. It’s more the notification content is just “Hey! Stuff happened” for Signal. The app then reaches out directly to the Signal servers to see what’s new. So the message content is never sent via the push notification service (UnifiedPush or Google’s service).

        • dracs@programming.devEnglish
          2·
          19 days ago

          I’m self hosting both too. MollySocket’s docs are pretty clear that it never gets an encryption key for your account, so it can’t read your messages. It only gets/forwards alerts that something happened on your account AFAIK. So I’m not sure what data it has that’s worth encrypting.

            • dracs@programming.devEnglish
              1·
              18 days ago

              The UnifiedPush server is intended to be a single source your phone can keep a persistent connection open to, rather than needing a connection per service/app (this is how Google’s Firebase notifications work too).

              As Signal doesn’t support UnifiedPush, MollySocket keeps a permanent connection open to Signal’s servers to listen for new activity and forward them to your UnifiedPush server. This saves your phone keeping a permanent connection open to Signal’s servers and draining your mobile battery more.

  • umami_wasabi@lemmy.ml
    4·
    19 days ago

    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.

  • rcbrk@lemmy.mlEnglish
    3·
    19 days ago

    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.

      • rcbrk@lemmy.mlEnglish
        1·
        22 hours ago

        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.

        • Kalcifer@sh.itjust.worksOP
          1·
          10 hours ago

          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
          1. “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.
          2. “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.
          3. “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/.
          • rcbrk@lemmy.mlEnglish
            1·
            6 hours ago

            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.

  • toastal@lemmy.ml
    2·
    19 days ago

    I still want to know if MQTT already did this & UnifiedPush is just a startup trying to reimplement the same concept

    • kevincox@lemmy.ml
      2·
      19 days ago

      IMHO UnifiedPush is just a poor re-implementation of WebPush which is an open and distributed standard that supports (and in the browser requires, so support is universal) E2EE.

      UnifiedPush would be better as a framework for WebPush providers and a client API. But use the same protocol and backends as WebPush (as how to get a WebPush endpoint is defined as a JS API in browsers, would would need to be adapted).

      • toastal@lemmy.ml
        1·
        18 days ago

        Sounds like you need a browser tho. UnifiedPush & MQTT work without a browser with WebPush support.

        • kevincox@lemmy.ml
          2·
          18 days ago

          There are three parts to the whole push system.

          1. A push protocol. You get a URL and post a message to it. That message is E2EE and gets delivered to the application.
          2. A way to acquire that URL.
          3. A way to respond to those notifications.

          My point is that 1 is the core and already available across devices including over Google’s push notification system and making custom push servers is very easy. It would make sense to keep that interface, but provide alternatives to 2 and 3. This way browsers can use the JS API for 2 and 3, but other apps can use a different API. The push server and the app server can remain identical across browsers, apps and anything else. This provides compatibility with the currently reigning system, the ability to provide tiny shims for people who don’t want to self host and still maintains the option to fully self host as desired.

  • rcbrk@lemmy.mlEnglish
    2·
    19 days ago

    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).