Librewolf would need to ask permission to a folder (for the standard downloads folder for instance) or it would need to show two save prompts when downloading two files (isn't that what it does already?)

The "two files" thing only applies to applications that ask access for one file (say, an mp4) and also want a second file in that same directory (say, a matching .srt). That can be worked around by selecting multiple files in the file picker, but that does pose for an annoying restriction. I don't see how a browser would be affected by this, though, as browsers don't tend to also send secondary files when you upload something.

but if I want to use it to open a file that isn't in "downloads" I have to use flatseal to give it extra permissions

There has been a portal to prevent this issue for years now. The fix isn't to patch around issues in Flatseal, it's for developers or Flatpak packagers to fix their security policies and code.

As an added benefit, KDE users get thumbnails in their file picker because they're no longer stuck with the old GTK one but instead can use their native file picker portal. A win for everyone!

I think they're a move in the right direction.

Just looking at the weird scaremongering around Signal from the past few days ("a chat app stores keys as files that you can read) shows a trend that I've been seeing more the past years: people have gotten so used to the Android/iOS sandboxing system that they've either never been taught or have forgotten how normal programs work.

Flatpak and the necessary desktop portals are very much a work in progress when it comes to user friendliness, but they're what the world has been moving towards for a while now.

I don't know why a journaling app needs full system access and access to system settings, and the permission Flatseal requests is a dangerous one if you pay attention to these things. Looks like they're doing their job to me.

Yeah, I'll always appreciate the original but I really like the drawn version. Can't find the actual source anymore, sadly, too many reposts online have diluted image search.

If you use the .local syntax, and the device name stays the same, I think the domain name based fingerprint should prevent the "do you trust this fingerprint" problem.

If you want to avoid the question all together, you could set up an SSH certificate authority (quick guide here, less dense guides are available on the internet). By signing the servers' host keys, you can prevent the trust on first use prompt entirely, even for servers you may not have logged into before.

The value for the end user, the way Apple and Google do it, is that it works on every phone. It was always intended to be the next generation of MMS messaging. RCS, as designed, never had companies like Google run their own servers, but Google had to because many carriers never bothered to set up RCS in the first place.

Who benefits today? Everyone sharing chat groups with iMessage people. I avoid iMessage but millions of people are stuck with text messaging or ostracised for breaking group messaging (because SMS and MMS are terrible).

Furthermore, RCS isn't just text messaging. The standard also contains digital payments and video calls. It's an open (to carriers) alternative to iMessage that has features ready to go that Signal doesn't even implement yet.

Communication is literally what phone numbers are for.

Yes, because other federated protocols (email, XMPP, Matrix) don't have the same features modern messengers have and don't interoperate with other protocols well. I don't think XMPP OTR or OMEMO are RFC standards either, they're just extensions on top of XMPP.

Some XMPP people are part of the conversation and Matrix is already moving to adopting MLS, so clearly "just use x" wasn't an option, even for them.

Authy just leaked a list of phone numbers. No actual 2FA data was breached. Even if it were, attackers would need your backup encryption password to access any 2FA keys.

You may get more phishing texts, but that's about it.

mDNS solves this. It may actually work out of the box. Try ssh'ing into your-device-name.local. If that fails, check your devices' names and if they have Avahi/Bonjour/mDNS enabled.

Something like Tailscale will set up a VPN with hostnames and IP addresses for you (and you can host your own entry server if you don't want to use the cloud stuff). That'll work across networks. It'll also add overhead and it's probably overkill for your use case, though.

As opposed to what? Encrypt them with a key that's stored elsewhere on the device? Without user prompting (which any malicious app could also do, of course) storing these keys encrypted is very hard. You could use whatever key chain API your platform provides, but that's just plain text passwords with extra steps. On Windows and Linux it wouldn't improve security in any way, on macOS it might also not (I don't know how Keychain access is done on macOS but I doubt it's impossible to get the key from there if you have local file execution).

Desktop applications aren't sandboxed, and the ones that are will only be protected against other sandboxed applications. I'm not sure if encrypting local message databases protects anyone in practice. It just adds half an hour of chatgpt aided programing to the job of the malware devs while the users lose access to their own data.

RCS has been around since the early 2010s and absolutely nobody used it until Google did. You had to download carrier specific apps, which then only worked with other people who downloaded their carrier specific apps, because nobody bothered to write unofficial ones. Carriers have been shutting down their RCS servers for years because their customers didn't care. Google is the only reason anyone uses RCS, if it weren't for them we'd still be on SMS/MMS.