I don’t understand how exactly this differs from something like Tor.

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]?

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?

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.

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

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?

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]

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]

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.

The app that wants to provide the notifications would then be said to use UnifiedPush, right?

I’ve never used AirVPN, but I’ve used Mullvad for a few years and I rarely ever have any issues with it. I won’t deny that I have few complaints, but the complaints that I do have are quite minimal. I wouldn’t hesitate to recommend Mullvad based on my own experience.

Very clever use case!

Not really as those are public things.

Would you mind citing an example of exactly what you are referring to? I feel like I’m presuming a lot of things in your statements here.

Dhcp is more of a issue.

I don’t know if it’s “more”, or “less” of an issue, but all these things are worthy of concern.

That would certainly also be worthy of concern.

have the machine pretend you’re in UTC.

That is a possible solution, though not exactly the most convenient, imo. That is, if I understand you correctly that you are talking about setting the OS timezone to be UTC.

could be defeated by doing an analysis of when the commits were made on average vs other folks from random repositories to find the average time of day and then reversing that information into a time zone

This is the first thing I thought of upon reading the title

It’s also in the post body.

Any given time zone there are going to be millions if not billions of people.

One more bit of identifying information is still one more bit of identifying information.

Git also “leaks” your system username and hostname IIRC by default which might be your real name.

This is only part of a fallback if a username and email is not provided [1].

A fake name and email would pretty much be sufficient to make any “leaked” time zone information irrelevant.

Perhaps only within the context where one is fine with being completely unidentifiable. But this doesn’t consider the circumstance where a user does want their username to be known, but simply don’t want it to be personally identifiable.

UTC seems like it’s just “HEY LOOK AT ME! I’M TRYING TO HIDE SOMETHING!”

This is a fair argument. Ideally, imo, recording dates for commits would be an optional QoL setting rather than a mandatory one. Better yet, if Git simply recorded UTC by default, this would be much less of an issue overall.

if you sleep like most people, could be defeated by doing an analysis of when the commits were made on average vs other folks from random repositories to find the average time of day and then reversing that information into a time zone.

I mentioned this in my post.

It’s better to be “Jimmy Robinson in Houston Texas” than “John Smith in UTC-0”

That decision is contextually dependent.

How do you mean?

Fair point. I think “leak” is likely the wrong term to use here. “Exposes” is probably a better one. I’ll update the post promptly.

Ah, right. I forgot that they’re based in Sweden. That’s understandable if it’s simply a lack of familiarity with the language, but, still, I would expect a company like Mullvad to at least have one native-equivalent English speaker to look over their public facing English stuff. None of this is the end of the world, ofc — I’m just mildly surprised.

There are a surprising number of grammatical errors in that blog post. Did anyone proof read it, I wonder?

Nearly 90% of their servers are blocked to do common internet tasks .

Perhaps your browsing habits are severely impacted by Mullvad being blocked, but that doesn’t seem to be the universal case. I’ve had the occasional hiccup with a few sites that block VPNs (Mullvad’s IPs), but “90%” is quite an exaggeration when compared to my personal experience.

For annotating PDFs:

• Xournal++
• Rnote

For arranging PDFs:

• PDF Arranger

That’s a rather self-centered statement, imo. Just because you may not be bothered by the idea, does not mean that it does not have merit for others. That line of thinking is in a similar vein to saying “We don’t need freedom of speech because I have nothing to say.”.

It’s all about reducing the surface area for an attack — if you do become compromised, it’s one less thing to have to worry aobut. It would be preferable to not have to worry about your data and someone bribing you with some video footage.