Migadu is a decent option if you don’t want to self-host.

I’d suggest 35,000 low-earth-orbit satellites but Elon is already working on that.

It’s no use. “VPN” means gateway/MITM service, just like “crypto” means digital tulip mania.

Today’s episode brought to you by our friends CoinSkank™ and EchelonVPN.

The article does not explain the primary design purpose of a VPN – providing an encrypted tunnel into or between two private subnets.

For example, your home subnet is typically all 192.168.nnn.nnn addresses – a class of addresses which the wider internet does not route, and which your router/modem does not allow the wider internet to access unless explicitly permitted.

Say you have a NAS on your home network, and you want to access it from your laptop while at a cafe; you could set up a VPN between your laptop and your home router, and it can make your home network appear as your local network to your laptop, giving you access to your NAS.

Or between two office locations of a business – their database servers, accounting systems, printers, etc can all be freely accessible between offices without being exposed to the wider internet.

So it sounds like an ID will not be a requirement.

Sure, but gov ID is permitted as an option if another non-ID option is also available.

Simply choose between submitting your government ID or, say, switch on your front facing camera so we can perform some digital phrenology to determine your eligibility.

The ban and age verification requirements apply to pretty much all services which allow communication of information between people, unless an exemption is granted by the minister.

There is no legislated exemption for instant messaging, SMS, email, email lists, chat rooms, forums, blogs, voice calls, etc.

It’s a wildly broadly applicable piece of legislation that seems ripe to be abused in the future, just like we’ve seen with anti-terror and anti-hate-symbol legislation.

From 63C (1) of the legislation:

For the purposes of this Act, age-restricted social media platform means:

• a) an electronic service that satisfies the following conditions:
  • i) the sole purpose, or a significant purpose, of the service is to enable online social interaction between 2 or more end-users;
  • ii) the service allows end-users to link to, or interact with, some or all of the other end-users;
  • iii) the service allows end-users to post material on the service;
  • iv) such other conditions (if any) as are set out in the legislative rules; or
• b) an electronic service specified in the legislative rules; but does not include a service mentioned in subsection (6).

Here’s all the detail of what the bill is and the concerns raised in parliament.

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.

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.

You could have a look at the messages ntfy is passing around using its trace function: https://docs.ntfy.sh/troubleshooting/

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.

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.

yeah. rat lungworm.

a private DNS server that only has records from your local services would at least prevent apps from reaching out as long as they aren’t smart enough to fall back to an IP address if DNS fails.

Yes, this. It’s important that your local DNS server does not even forward queries from the isolated subnet to external DNS, because these queries (and responses) can contain information. (“DNS tunneling”).

What will this mean for Lemmy instances? XMPP servers? Email servers?

What if a 15 year old runs their own personal Mastodon server? LoL this is gonna be yet another entertaining Australian government shitshow.

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.

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

Could go old school and build your own:

Page 66: https://www.worldradiohistory.com/AUSTRALIA/Electronics-Australia/EA-1992-07.pdf

Page 126: https://www.worldradiohistory.com/AUSTRALIA/ETI-Australia/90s/ETI-1990-01.pdf

You have to trust the servers with your metadata, and that the servers have their inter-server communication locked down, but at least you can choose/operate servers.

Some clients are a bit flaky with their e2e encryption defaults or from a UI perspective it is easy to send an unencrypted message (in a new chat for example) before noticing that was how it was set.

There are a few XEPs the server needs which enable things like OMEMO, efficient mobile data/battery use, offline and multiple device deliverability, file transfers, etc. Audio/video calling has various requirements as I think xmpp only facilitates the setup of the call.

XMPP lacks good clients and suffers from fragmentation of protocol standards implementation

• For Android: Conversations is excellent, also on F-Droid if you don’t want to use the Google store.
• For iOS/MacOS: Siskin or iOS/MacOS: Monal.
• For Linux/Windows: Gajim or Linux: Dino.

“Protocol fragmentation” is not a valid complaint about XMPP – it’s like complaining that ActivityPub is fragmented; but that’s not a problem: you use the services (Mastodon, Lemmy, Kbin, etc) built with it which suit your needs, mostly interacting with that sector of the federation (eg, Lemmy+Kbin), but get a little interoperability with other sectors as a bonus (eg, Lemmy+Mastodon).

When human shields are used, the attacking party must take into account the risk to civilians. 191 Indiscriminate or disproportionate harm to civilians remains unlawful and the civilian population can never be targeted.

So, from this I understand that every time Israel makes an accusation of “human shields”, it’s a direct admission of guilt of war crimes in that they are knowingly targeting civilians.