[Solved] All things being equal, which is more privacy-friendly: snap pkg or .deb pkg?

[m4c-attack]

In this instance, neither are a part of the official Debian repo, but they are both available via the reputable company's website.

The company initially only had a snap app, but within the last few weeks released a .deb version which I jumped at as a Debian user

I have installed the .deb and and completely removed the snap (along w/ snapd)

However, after thinking about it for a while, I'm second guessing myself from a privacy perspective. Canonical is more business-friendly so less 'locked down' from a privacy perspective than flatpaks, but am I correct in assuming that .deb files are mostly unrestricted, assuming that my install is a tacit agreement of their privacy practices?

Can someone let me know whether my privacy concerns are better/worse/the same between the two install methods? Let me know if I'm off-base. The only other thing that comes to mind is manually locking down specific aspects via apparmor

[sunrat]

You'd have to read the source code to be sure of any privacy implications. Snap generally has a poorer record from a security perspective and is wasteful of system resources with it's requirement of a separate runtime which is about 1GB afaik.
I'd pick the .deb every time over a snap. I have zero snaps currently and don't plan to ever.

[Uptorn]

Snap requires an entire separate framework. Whereas .deb packages can already be received by any Debian or Debian derived system, what with having dpkg and all. As somebody who cares greatly about digital privacy, I would never clutter my system with any of those snap or flat frameworks. blech

[m4c-attack]

I appreciate the responses so quickly! I want to preface by saying that I think that I might have done a disservice to responses in two areas:

• By mentioned that the company that created the snap/.deb packages was reputable, I meant that I know they are not pushing malware or trying to access my bank records. However, as for most companies in 2024, I don't trust that they won't use my system to scrape as much aggregated/anonymized data about me as legally possible.

• By posting this question in the beginner's section, I think I might have gotten some knee-jerk answers based on the title as opposed to slightly more layered question within the thread

I did some digging after starting the thread and reached a completely different conclusion than the advice given, so I'll share and leave it open for any feedback or ways I might be off based before I close out the thread.

I'm not a huge fan of Canonical and their business model, but casting that aside, after reading a few articles, there seems to be a consensus that .deb files (outside of the official repos) are less secure. Deb files give perpetual access to the user directory while containerization creates an additional layer/firewall between the app and user data which improves security and (in)directly privacy as well:

Existing Linux formats like DEB and RPM typically have full access to your system at installation and maintain access to any file in your user directory. This means you have to really trust the apps you install, plus their updates because an app can easily compromise your system and your data.

Flatpaks and Snaps seek to address this by isolating apps from your system files and your personal data. Apps can ideally only access the parts of your computer they need to function, such as a specific folder or your webcam.

Source: https://www.makeuseof.com/why-flatpaks- ... r-formats/

The main difference between snap and .deb packages is that snaps are sandboxed and self-contained, while .deb packages are not.

Sandboxed means isolated (to some extent) from the rest of the system; for example, snaps usually can't access files outside your home directory, unless specifically configured to do so. So you should install a snap version of the application if the application does a job that is relatively independent from the system as a whole - for example software for video editing or numerical calculations, or a game. Everything that is closely integrated with the system (for example a screenshot utility, or an alternative file manager) works best with .deb packages.

Source: https://askubuntu.com/questions/1441718 ... n-packeges

Snaps also run in strict mode by default which is more secure than the standard mode for .deb files:

Confinement is defined by general levels and fine-tuned using interfaces, and there are three levels of confinement; strict, classic and devmode.
Strict
This confinement level uses Linux kernel security features to lock down the applications inside the snap. By default, a strictly confined application cannot access the network, the users’ home directory, any audio subsystems or webcams, and it cannot display any graphical output via X or Wayland.

Devmode
This is a debug mode level used by developers as they iterate on the creation of their snap. With devmode, applications can access resources that would be blocked under strict confinement. However, the access to these resources will be logged, so the developers can then review the software behavior and add interfaces as required. This allows developers to troubleshoot applications, because they may behave differently when

Classic
This is a permissive level equivalent to the full system access that traditionally packaged applications have.

Classic confinement is often used as a stop-gap measure to enable developers to publish applications that need more access than the current set of permissions allow. The classic level should be used only when required for functionality, as it lowers the security of the application. Examples of classic snaps would include development environments, terminals or build tools that need to access or execute arbitrary files on the host system.

Source: https://snapcraft.io/docs/classic-confinement

Elaborating further on strict mode:

Strict

​​This is the default confinement for all apps. It gives the application read and writes permissions only in its install folder and if a home plug or interfaces are available for the app, users are also capable of accessing the home folder.

Strict confinement gives you the following readable and/or writable paths:
​

/snap/<snap>/<revision> (read-only, snap install path).
/var/snap/<snap>/<revision> (read/write, per-revision data).
/var/snap/<snap>/common (read/write, common data).
/home/$USER/snap/<snap>/<revision> (read/write, per-revision user data).
/home/$USER/snap/<snap>/common (read/write, common user data).​​

Source: https://www.linuxandubuntu.com/home/sna ... b-package/

Given this, my current perspective is that outside of FOSS & packages in the official repos, snaps appears to be a better option than .deb files re: privacy protection, especially for for-profit software.

Personally, this is one of those moments where I had to put my irritation w/ Canonical to the side and accept that their product is generally more secure if it's for non-system packages

[panpan]

Snap Trap: The Hidden Dangers Within Ubuntu’s Package Suggestion System

https://www.aquasec.com/blog/snap-trap- ... on-system/

[CwF]

...and then you add in the oversight factor of a tested and vetted repository and the superior format is clearly deb. There is no explanation necessary for any software from a 'reputable' source that is different from any other foreign source.

There is no pro/con of the formats that matters, the difference is in delivery.

Curated repository wins.

On top of that Snap are a kludge, a fat one at that, and one geared towards capitalization, that's all.
For a paid application, fine solution. I don't think there are privacy differences at all when you clamp down the worry to 'what is legal' - delivery doesn't matter, you clicked yes.

[m4c-attack]

Snap Trap: The Hidden Dangers Within Ubuntu’s Package Suggestion System

https://www.aquasec.com/blog/snap-trap- ... on-system/

Thanks for sharing. I looked through the article. `command-not-found` redirects and Typo-squatting on packages are improbable but possible given that there's rarely parity across any two app stores, but to re-iterate my original question, my question/concern is about what the data that is being shared w/ the app that I'm using.

...and then you add in the oversight factor of a tested and vetted repository and the superior format is clearly deb. There is no explanation necessary for any software from a 'reputable' source that is different from any other foreign source.

There is no pro/con of the formats that matters, the difference is in delivery.

Curated repository wins.

Appreciate the response. Just to restate the first line of my question, I am concerned about a package from a third party repo, not from the official repo.

On top of that Snap are a kludge, a fat one at that, and one geared towards capitalization, that's all.

Do you disagree with the articles I shared that show that installing .deb files from outside the Debian repo are a greater security risk than a containerized solution like flatpak or snap? It is possible that Canonical is a money-hungry company AND that they have a platform that is more secure when handling packages outside of the official debian repo...

For a paid application, fine solution. I don't think there are privacy differences at all when you clamp down the worry to 'what is legal' - delivery doesn't matter, you clicked yes.

This is where we fundamentally disagree. Just because I accepted the ToS, that doesn't mean I cannot fight to protect my privacy.

That is why I use firejail and blocked the internet for WPS Office when it tried to connect for no reason.
That I why I use Tracker Control on my Android phone to block apps trying to phone home.
That is why I use Firefox Multi-Account Containers so that the cookies I do concede are segmented and don't paint a full picture.

This thread was asking the question about what tools does Debian provide to protect privacy for non-official repo .deb installs, and objectively, that protection is not as complete as the modern containerization approach in snaps/flatpaks. As a Debian user, I can accept this, stop downloading 3rd party .deb files, and then immediately return to appreciating the various other positives that Debian provides.

[wizard10000]

snap's backend is closed source, dpkg isn't.

As far as snap vs. deb? On four Debian machines here I have exactly one snap installed because my choices were snap or docker and I'm not doing docker for one application. I could have compiled the app from source but then I'd have to do that every time it got upgraded so I (reluctantly) chose snap.

[Uptorn]

So you're assuming that the software you need to run is going to be malicious. If you suspect that they will use their software to scrape user data, then is that really a "reputable" piece of software? And just because some malicious behavior is now the norm doesn't make it excusable.

From a security perspective, the assumption isn't a bad assumption to be making. That is why we use mandatory access control solutions. Make an Apparmor profile for the untrusted program.

[CwF]

I often come to these opinions of mine through my own thinking and process. So if I missed something I'll apologize, but I try hard to eliminate minutia that falls below other overriding factors. This means some technical right/wrong is often irrelevant (to me) since I won't get there anyway. In this case there is a higher element in considering the safety of the methods - Can I take it apart and inspect it or modify it?

In the case of a .deb, yes. For snaps and flatpacks I have no idea. Years ago I took apart exe's and msi's too. As far as compiled code without source, if I obtain it unvetted, then it will live in a test machine or virtual machine until I'm satisfied.

I haven't tried snap or flatpacks due to another rule I try to follow. I don't replace perfectly rolling wheels until they no longer roll, aka reinventing the wheel. The slow adoption rate of gray beards is a separate discussion. I first look at the motivation of the change, not the technicals. Up until I reconsider, I will regard snap and flatpack motivation to be monetization - even with perfected technicals.

Why have we excluded appimages? Well, what's the motivation - to include advanced libraries. Good reason. Can I take them apart for inspection, kinda. Let's skip that and vet it ourselves then, so I do. Not surprisingly I use a few. They are the original alternate delivery method as far as I know. When they are tidy, and pass testing, I'm all aboard. Why then the push to not use them to solve ALL the bleeding edge delivery issue? Good question. Already answered.

Also note - Do I expect a Debian user to be saddled with the responsibility to vet their software mix themselves? I do.
Any user that thinks they should have no responsibility of any kind integrating their software choices should probably use Ubuntu. That is the reason derivatives exist. I don't believe it is a worthy goal for Debian proper to worry about complete end-user OOBE. Debian is the premier 'builder' OS. Ubuntu is a 'jobber' OS with 'end user' flavors fulfilling the completed OOBE need. When one of those flavors has commercial success with an immutable base utilizing a software store featuring flatpack or snaps, fantastic! That has no bearing on Debian proper,

Do you disagree with the articles I shared that show that installing .deb files from outside the Debian repo are a greater security risk than a containerized solution like flatpak or snap?

So if you follow where I place Debian in the chain, I dismiss the concern about evil debs. The responsibility is ours.

[m4c-attack]

Appreciate all of the comments everyone. It is definitely a reminder that Debian isn't overly opinionated, but there are a variety of unique perspectives on acceptable risks. There are people who only use packages in the official repo, people who don't use containers, people who don't use anything created by Canonical, etc.

For me, my perspective on risk and privacy suggests that I should refrain from third party .deb files and shift to snaps/flatpaks instead. This will take up more space on my device but given my desire for privacy, this will give me built-in control beyond what Debian offers (for 3rd party .deb files). I contemplated setting up apparmor on the .deb file instead, but I tried it on a theme-changing script that had simple queries like pinging wttr.in, and that apparmor profile was overly extensive, so I can only imagine what a fully-featured software package would trigger. I will create an apparmor profile for the snap instead, w/ the expectation that the containerization will reduce the size of the apparmor profile

Thanks yall!