iRo
My feedback
4 results found
-
636 votesiRo
supported this idea
·
-
754 votesiRo
supported this idea
·
-
1,321 votesiRo
supported this idea
·
-
1,883 votes
An error occurred while saving the comment iRo
supported this idea
·
As a paying Proton member, I am increasingly disappointed with the current state of Proton’s Linux applications. Linux support has become essential—Windows has long mutated into a data-harvesting platform under the guise of an operating system, fundamentally contradicting the principles of privacy and user control. Precisely because Proton has made security and privacy its core mission, I expect Linux not to be treated as a secondary platform.
What is concretely missing is a complete suite of Proton desktop applications delivered via a dedicated RPM repository for RPM-based distributions such as openSUSE, Fedora, or RHEL clones. Why a repository — and not just Flatpak or manual downloads?
A native package repository offers decisive advantages:
- Package Signatures and Chain of Trust: A properly managed repository ensures that every package is signed with a GPG key that the user must explicitly import and verify. The package manager (zypper, dnf, etc.) cryptographically checks the validity of the signature with every installation and update. If a package has been tampered with or loaded from a compromised mirror, the signature check fails, and the installation is refused. This is a fundamental security mechanism that manual .rpm downloads or unsigned Flatpaks cannot offer with the same reliability.
- Automatic Updates: Updates are deployed via the standard package management system — no manual downloading, no forgetting critical security patches.
- Dependency Resolution: The package management system resolves library dependencies consistently, avoiding system incompatibilities and "dependency ****."
- System Integration: RPM packages integrate cleanly into the existing desktop environment — systemd services, .desktop files, icon themes, and MIME-type associations work out-of-the-box.
- Reproducibility and Auditability: Package sources can be controlled in enterprise environments via local mirrors and custom pinning rules—a benefit that Proton, given its focus on institutional users, should take into account.
Wayland support must not be an afterthought. Wayland is the standard compositor in Fedora, openSUSE Tumbleweed, and increasingly in other distributions. Applications that still strictly require X11 are functionally restricted on modern desktops — whether through missing screen recording capabilities in screen sharing, broken input methods, or flawed rendering. Proton applications must support Wayland natively.
It is truly time for Proton to deliver here. The community has been waiting for years. And those who take privacy seriously should prefer the platform that not only promises privacy but guarantees it technically and architecturally — and that platform is Linux.