Signal’s defaults are pretty good about that. Push notifications are both opt-in and the information they send can be selected by the user. You can have it say “new message” and that’s it. Or the senders name. Or the whole message.

I agree that it’s not intuitive that that’s a leak to most people, but push notifications are kind of wonky how they work.

No matter how good the protocol or client encryption, your privacy is only as good as your own physical security for the device in question.

Given that if you lose your private key, there is no recovery, I would be surprised if there were real back doors in the clients. Maybe unintentional ways to leak data, but you can go look for yourself: https://github.com/signalapp/Signal-Android

They have one for each client.

The register simply says “nothing to see here” 😂

Wait til your table with all the checksums gets messed up on an “older” btrfs install. Happened to me on a VM because I didn’t know copy-on-write should be disabled for large frequently partially updated files. It also slowed that VMs IO down a lot.

Like most file systems, BTRFS is great if you know the edge cases. I recently moved to ZFS on my new work system, which has been a great change in terms of in-line snapshots and the like.

If EXT4 meets your needs, that’s awesome. If you understand how to use a different FS well or are willing to learn (and risk), I would also encourage other options as well.

Sounds like they could have been lazy and simply disabled/blocked your dns lookups, or stopped providing your route to 0.0.0.0/0. VPN provides new dns provider and a route to the internet at large, and you’re back in business.

Uh, I might be wrong here, but isn’t the whole purpose of split tunneling to allow you to send only necessary traffic through a given tunnel? Then the rest of your traffic goes whatever the default path is?

This seems more like a feature than a CVE. Maybe I’m missing something.