Epic. The same company whose store client / launcher has been caught snooping around hard drives and collecting user data from unrelated software. The same company whose “online services” code is often included in games they distribute, collecting an excessive amount of information from computers that run them. The same company whose CEO has proudly and loudly bashed Linux for years.
No thanks.
Those aren’t free games. They’re surveillance tools.
Can you detail specifically why it isn’t sufficient? Because I thought you could restrict which directories a Flatpak software could access down to the level of single, specific directories?
You can restrict casual directory access if you’re careful, and well-informed, and diligent about the (often overly generous) permissions chosen by each Flatpak’s maintainers, and those chosen by runtimes and base applications, and about changes over time.
However, files and directories are only a small fraction of what hostile code can exploit. There are also d-bus services, abstract sockets, shared memory areas, display server protocols, and device nodes, for example. In the fingerprinting and tracking department, we have things like hardware peculiarities and installed font lists. If you’re concerned not only about privilege escalation and data exfiltration, but also about collection of your biometrics, then you should consider keystroke timing, mouse movement patterns, voice samples, and the like. These are just examples, not exhaustive lists.
More fundamentally, Flatpak sandboxes are made of Linux namespaces, which have a long history of vulnerabilities and exploits. They’re pretty good at containing buggy software, but software that wants to circumvent them can find a way, and if its developers are sufficiently skilled, will find a way.
The only thing I really use them for is to disable internet for open source applications that I trust aren’t malicious, but might still have telemetry in them.
However don’t let perfect be the enemy of good. Flatpak permissions are a step forward, at the very least defining a permission framework. Initially, permissions were defined but every app had all permissions, since app devs were lazy. Now, app devs are being better about defining what permissions are needed. In the future I imagine that Linux and Flatpak will lock down the security, making the permissions more concrete.
Epic. The same company whose store client / launcher has been caught snooping around hard drives and collecting user data from unrelated software. The same company whose “online services” code is often included in games they distribute, collecting an excessive amount of information from computers that run them. The same company whose CEO has proudly and loudly bashed Linux for years.
No thanks.
Those aren’t free games. They’re surveillance tools.
It’s a flatpak, review permissions and deny as much as needed.
Flatpak’s sandboxing is not sufficient to protect against hostile software.
And even if it were, I would not be inclined to run software from Epic.
Can you detail specifically why it isn’t sufficient? Because I thought you could restrict which directories a Flatpak software could access down to the level of single, specific directories?
You can restrict casual directory access if you’re careful, and well-informed, and diligent about the (often overly generous) permissions chosen by each Flatpak’s maintainers, and those chosen by runtimes and base applications, and about changes over time.
However, files and directories are only a small fraction of what hostile code can exploit. There are also d-bus services, abstract sockets, shared memory areas, display server protocols, and device nodes, for example. In the fingerprinting and tracking department, we have things like hardware peculiarities and installed font lists. If you’re concerned not only about privilege escalation and data exfiltration, but also about collection of your biometrics, then you should consider keystroke timing, mouse movement patterns, voice samples, and the like. These are just examples, not exhaustive lists.
More fundamentally, Flatpak sandboxes are made of Linux namespaces, which have a long history of vulnerabilities and exploits. They’re pretty good at containing buggy software, but software that wants to circumvent them can find a way, and if its developers are sufficiently skilled, will find a way.
So Flatpak’s “security measures” are basically completely useless, is what I am to understand?
The only thing I really use them for is to disable internet for open source applications that I trust aren’t malicious, but might still have telemetry in them.
However don’t let perfect be the enemy of good. Flatpak permissions are a step forward, at the very least defining a permission framework. Initially, permissions were defined but every app had all permissions, since app devs were lazy. Now, app devs are being better about defining what permissions are needed. In the future I imagine that Linux and Flatpak will lock down the security, making the permissions more concrete.
It’s a step by step process.
Then I’ll keep installing software I need but don’t necessarily trust using Flatpak 👌
Yes. I’m happy it’s a FlatPak, but I’m still not 100% sure I understand and trust flatpak’s sandbox to put Epic Games Launcher on my PC.
I’m way more likely to trust it as a FlatPak than any other way.
But I think I’m still at no, because it’s Epic.