skullgiver

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.

I think this is the more worrying part if true. The backend is licensed under the AGPL, so this would technically be a violation of their terms

The AGPL doesn't require you, the author, to do anything. As the copyright holder, you decide the license your code falls under. You publish code with a license so others can use it. You can always do with your own work on your own computers as you wish, assuming you don't also use other (A)GPL code that forces you to release your own.

Many companies sell GPL software this way; the (A)GPL version is free to use, but if you don't want to share your alterations and any code you integrate the (A)GPL code with, you pay money to get a non-AGPL licensed copy. Qt does this, for instance, so car manufacturers can design their closed source vehicle dashboards and open source projects can use Qt to build a Linux desktop.

Phones come with pretty easy encryption APIs that use hardware encryption stores to do the encryption work. You can copy the entire data folder to the same phone after a factory reset, but the messages won't decrypt. It's a useful extra encryption feature that's pretty tough to crack (as in, governments will struggle) but trivial to implement.

Desktop operating systems lack this. I believe Windows can do it through Windows Hello but that requires user interaction (and Windows isn't sandboxed anyway so it doesn't protect you much if you're running malware are the same time). Don't know about macOS, but I assume it's the same story. Linux lacks support for security hardware entirely and doesn't even try (see: the useless Keychain API copy).

What desktop operating systems do protect you from, though, is offline attacks. Someone needs to know your password to log in and grab the keys, even if they know your disk's encryption key. Not even your Bitlocker recovery key will suffice to get your keys out of a locked Windows Hello key store. Linux can implement this ad well, in theory, but nothing seems to actually implement any of it.

Leveraging modern key store mechanisms would protect Signal on macOS and Windows. On Linux you'd still be in the same shitty situation, though if they were to implement the key store API, someone could at least eventually make something secure in the future.

Ah, in that case I would definitely recommend taking a look at Tailscale!

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.