Isn’t that for U.S. law? Given that the law in the post is a Canadian law, I think it would be better to have a Canada-specific source.

[…] the fraud usually has to be something a reasonable person could believe. […]

Could you cite a source for that?

A likely comparatively barebones (but sufficient for my needs) solution that I use is Obsidian with Synching.

What specific features are you looking for?

As the defense industry consolidated, TI sold its defense business to the Raytheon Company in 1997 for $2.95 billion. […] ^[1]

Ha, punishable on summary conviction (it’s mentioned in the post’s cited law).

Canada had anti-fraudulent witchcraft laws.

I’ll update the title accordingly. I think it’s important to specify what you’ve stated, for clarity.

Also, imo, regular anti-fraud laws, and regular tort law can take over for the nonexistence of this specific law. For example, if someone is advertising a business, even if it’s something of an occult nature, and then they don’t deliver what they promise, I’d argue that that’s standard false advertisement.

Can you ping the Jellyfish server from the laptop? Can any other device access the Jellyfish server?

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

Based PSA of the “appeal to authority” logical fallacy!

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?