QUIK SMS implements turning “blank liked message” into the proper format, but that still doesnt allow sending emoji reactions.

I was pretty sure that RCS was centralized and requires using the existing infrastructure, which requires some contract with Google or other providers.

Either way, no open source Messenger (that I know of) exists which supports RCS.

GrapheneOS. It gets updates and security patches quickly, it fully removes dependency on Google services (unlike any of the others you mentioned), and it is heavily deblobbed of proprietary blobs. It is rock solid. Here is a comparison table from a trusted third-party: https://eylenburg.github.io/android_comparison.htm

All of those apps will work, just install Sandboxed Google Play. Install company apps either in a Private Space or a separate user to isolate them. I recommend putting all Gapps (play store apps) in a Private Space.

That is why I said sending them. You can’t send reactions that people can also see without RCS. QUIK SMS converts received reactions into the proper format but still can’t send them.

Sending them requires the proprietary RCS protocol. Only google messages and a couple others can do it. Infrastructure for RCS is owned by Google, Apple, and some carriers IIRC

Note: iode is often a month or more behind on Android security patches.

QKSMS has been dead for years. QUIK SMS is a revival QKSMS: https://f-droid.org/packages/dev.octoshrimpy.quik.fdroid

Here is the link to UAD-ng: https://github.com/Universal-Debloater-Alliance/universal-android-debloater-next-generation/

Funnily enough OpenRC is probably the slowest of the inits offered by Artix. The current best in both features and stability are Dinit and s6. Dinit is far more user friendly. Both boot ~20% faster than the others, and much faster than systemd. Generally though, simplicity without expense to features is what Dinit and s6+66 excel at.

Gentoo wiki page comparing inits: https://wiki.gentoo.org/wiki/Comparison_of_init_systems

From the Dinit developer: https://github.com/davmac314/dinit/blob/master/doc/COMPARISON

Yes, just get the Nvidia version of Secureblue/Bazzite and you are good.

I personally adhere to the idea of avoiding installing too many overlayed packages. Most i have installed in like five (with dependencies) at once. If you are comfortable with still using mostly Flatpaks and (only) a few overlayed packages, then Atomic may still be for you.

I really do recommend Secureblue.

I see this misconception all the time about Fedora Atomic distros. You can actually install any normal package available through the included repos, or add your own repo (rpm-ostree install $pkg). DNF can be used to add a repo from a URL and then you just use rpm-ostree install $pkg . It is really that simple.

The reason you aren’t supposed to is that it makes the system diverge from the default image by overlaying the package. Still though, Fedora Atomic is just Fedora but container images for updates.

deleted by creator

Vivaldi is also proprietary. Not a good privacy browser.

Flatpak apps cant use namespaces. Flatpak (the software) uses namespaces but Flatpak apps can not.

Yes, I understand Flatpak does some seccomp syscall filtering. It still isn’t enough to consider a secure sandbox where the threat model is that the app is untrusted. Bubblewrap is generally considered a weak sandbox and isn’t “secure by default”, allowing for easy footguns.

LXC/Incus does support proper VMs but it isnt as common.

Neither are really designed to run untrusted apps.

I guess I just don’t understand your question. Explain in more detail.

1. Who is the threat actor? (State, APT, Hackivist, etc)
2. What is their goal (what do they want)? (Money, data, persistent access, blackmail)
3. What tools do they have?

Really think about the Ws (who, what, where, when, how).

If you want to protect against an “advanced” threat actor, you can not do that without multiple layers of isolation, including but not limited to virtualization, MAC (SELinux), namespaces, seccomp.

All protections are meaningless without a clear understanding of what assets you are protecting, the threat you face, and they want from you.

Distrobox is design to be the opposite of confined. Its goal is integration. The container is stripped away as much as possible to allow for sharing host resources.

As it says on the Distrobox website:

Security implications

Isolation and sandboxing are not the main aims of the project, on the contrary it aims to tightly integrate the container with the host. The container will have complete access to your home, pen drive, and so on, so do not expect it to be highly sandboxed like a plain docker/podman container or a Flatpak.

I would also argue calling “plain docker/podman container or a Flatpak” being “highly sandboxed” is also quite wrong and a misuse of those technology.

It uses Docker/Podman which is not a security sandbox. The purpose is app containers, not a security boundary. It shares the sane kernel as the host, which makes kernel vulnerabilities a source of container escapes. Docker (the default) runs as root and could be a source of privilege escalation. Best case is use gVisor or SELinux. Still not a secure sandbox.

Similar problems with Flatpak. Not a secure sandbox. Doesn’t Barely filters syscalls (and in a general way instead of per-app), barely reduces attack surface, granting frequently required permissions often significantly reduces the strength of the sandbox, shares a kernel with the host (and no application kernel like gVisor or sydbox), weak use MAC (like SELinux). Most of this can also be said of the previous 2 container software (and also LXC/LXD/Incus).

Also, don’t use browsers with Flatpak, they have a significantly weaker sandbox because it is missing a layer of sandboxing (namespaces). This makes attack exponential more likely by reducing the need chain another major vulnerability to execute a successful sandbox break.

What you want is a VM. It is designed to be a secure sandbox but needs some configuring.

I would probably go with Artix because it is arch based and therefore you will get updated packages instead of perpetually outdated Debian packages. Then maybe switch out the kernel for the CachyOS kernel and you should be good.

/e/OS doesn’t care take security seriously. They are usually 1-2 months behind on Android security patches, leaving users vulnerable to literally (literally) dozens of critical and many more high severity vulnerabilities. Every other Android ROM is better about this. LineageOS and GrapheneOS are the best about updating quickly.

Honestly, I saw it in a video recently that i cant remember. It showed some screenshots of the engineer’s Twitter taking about it.