5 ms·

Honestly I feel less secure with sandboxes Android apps that I do on desktop Linux. On Linux I use my distro's curated repository (ex to install cozy, an ebook

by amstan 3y ago

Honestly I feel less secure with sandboxes Android apps that I do on desktop Linux. On Linux I use my distro's curated repository (ex to install cozy, an ebook reader, or yt-dlp), I don't care that it has access to the rest of my system, the bonus point is that I can have access to its source code. On Android, the first app I see has "In-app purchases" and will probably spy on me. Yes... I agree I guess, on Android (therefore ChromeOS) app stores I definitelly want sandboxing because it's a very adversarial relationship between the users and the apps. Unfortunatelly that means you need to get into sandboxes, throw stuff in VMs and all the other things that will make performance and efficiency suck. I miss the time where my computer ran only software I controlled and it wasn't a free for all where everyone wants to run random code (Javascript from websites is a big one here). All the Specter/Rowhammer stuff is only because you're sometimes running untrusted code. Why do people need to be running untrusted code all the time? /me goes back in the cave

yathaid 3y ago
Just stop with this nonsense. This is such a foolish opinion that is bandied about from a "I know exactly what apps I run, sandboxing is for those noobs" mindset. Did you compile them yourselves? Did you compile the compiler? Let's just accept the fact that Linux comes from a place of "if you run a program you are responsible for what it does". This is contrary to modern users expectations of "just because I run a program it shouldnt be able to siphon all my data", largely driven by mobile apps and their ecosystem. If I autocomplete an ls command on my Mac's terminal it will warn me that iTerm is trying to access the specified folder. There is nothing like that on popular distros. The whole security landscape needs to be re-thought. Maybe someone who knows more than me can talk about bring features from more restricted Linux variants to a more broad audience.
- jolmg 3y ago
  He's just bringing a valid point. Despite the lack of isolation between pieces of software, I too feel more confident about what's running on my Linux distros. That's not to say that "sandboxing is for noobs", but it's an interesting point. It's like how people in very rural areas can feel perfectly safe not locking doors and stuff, sleeping outside, etc., while that would be extremely foolish to do in the middle of certain cities, in certain neighborhoods. Different environments, different dangers, and I think it's fine to enjoy the benefits of a safer environment. Safety in this case is not provided by physical distance between homes but by curation of software done by nonprofit groups and selection of nearly only open source software with easy building of packages and tracking of changes in the source. > Did you compile them yourselves? Did you compile the compiler? There's no such thing as perfect security, and I think you know that. If you think your compiler may be compromised, there's stuff you could do, you just have to evaluate where the paranoia starts and stop before then.
- amstan 3y ago
  Do you trust your OS, compiler it was compiled with, and then trust all the hardware it's running on (which is probably even more insidious and capable of hiding stuff). Let's not pretend that just because there's a sandbox at a higher level of the stack and some kind of user ability to accept/deny operations that things are secure.
  - tiberious726 3y ago
    Eh, defense in depth, if we make a huge mess of overlapping detection systems, good luck inserting a compiler quine to bypass them all.
- tiberious726 3y ago
  > Did you compile the compiler? Do you trust trust? (And no differential compilation isn't an actual solution.)
waplot 3y ago
> the bonus point is that I can have access to its source code Are you actually reading all the code before you run it? Are you re-reading it for each update? If not, then what's the point of bragging about having access to the source? The point of sandboxing is that it's impractical to reliably audit, on a continuous basis, the massive volume of software that the average person runs. It's more economical to apply the least-privileged principle, and only give apps access to the things they need to function.
- jolmg 3y ago
  > Are you actually reading all the code before you run it? Are you re-reading it for each update? If not, then what's the point of bragging about having access to the source? Not every user needs to read everything. We can read pieces of what we use and trust others to also read pieces of what they use. We can also place some amount of trust that there's a body of people that have read code before we started using it, and that it's only the new changes that need the more review. People can also use reputation to make safety in review more economical. Sandboxing is not bad, but it's not the only way that security can be achieved. Having a good social infrastructure also helps.
  - autoexec 3y ago
    Not every user has to read every line of code, but I do sometimes wonder how many open source products have never been read by anyone outside of the people who wrote/maintain it, and for those projects where anyone has reviewed the code, how many of them were really qualified to understand what they were seeing? I still believe that having the code available for review is important, but I don't think it's a reliable means of saving people from insecure or malicious software.
    - jolmg 3y ago
      > I still believe that having the code available for review is important, but I don't think it's a reliable means of saving people from insecure or malicious software. Just having the code available, in and of itself, is probably not. However, the presence of the source is not the only thing you have to provide reliance. For Archlinux, for example, different package repos have different requirements and provide different levels of safety. You can put more trust in packages in core than you can those in extra, and you can trust those in extra more than you can those in the AUR. Anyone can push packages to the AUR, and so can they to other package repos like those of different languages (rubygems, hackage, etc.). Different languages will have different communities and you can get a feel for how trustworthy they are as a whole, based on their requirements, etc. This is like the difference in safety in different cities. You can check the author and get some kind of idea as to how much reputation they're holding. You can also check the package maintainer and get some kind of idea as to how much reputation they're holding. You can check how many other people trust that software, and if there's any particular notable ones. You can see how well established and widely-adopted the development process is formulated in the homepage/github/etc. You can also review the source yourself, and even if you're not some security expert, that doesn't mean your review is absolutely worthless. It's got a score. Put a score on every source of trust, add them up, and check with your risk tolerance. You don't need to do everything. If I decide to walk on a street, I'm not checking the crime statistics there, the internal state of the nearby police department, etc. I'm mostly deciding based on the city/neighborhood I'm in, how populated the street is, the state of the people there at a glance, and that's generally more than enough for most people. > but I do sometimes wonder how many open source products have never been read by anyone outside of the people who wrote/maintain it, and for those projects where anyone has reviewed the code, how many of them were really qualified to understand what they were seeing? In case my point was lost in my ramble, you don't have to base your decision on trusting a particular piece of open source software based on how much you trust the whole body of open source software in existence. You can decide to e.g. trust the official repos of a distro based on how that curation works, so trust the packages in it and not the software outside it (e.g. the AUR or random Github repos), and you can decide to trust based on other signs of your choice like that, too.
kaba0 3y ago
System security doesn’t care about your feelings — any rogue program, or even an npm install can encrypt your whole drive, or install a keylogger. This is not true of android and ios.

by amstan 3y ago

yathaid 3y ago

Just stop with this nonsense. This is such a foolish opinion that is bandied about from a "I know exactly what apps I run, sandboxing is for those noobs" mindset. Did you compile them yourselves? Did you compile the compiler? Let's just accept the fact that Linux comes from a place of "if you run a program you are responsible for what it does". This is contrary to modern users expectations of "just because I run a program it shouldnt be able to siphon all my data", largely driven by mobile apps and their ecosystem. If I autocomplete an ls command on my Mac's terminal it will warn me that iTerm is trying to access the specified folder. There is nothing like that on popular distros. The whole security landscape needs to be re-thought. Maybe someone who knows more than me can talk about bring features from more restricted Linux variants to a more broad audience.

jolmg 3y ago
He's just bringing a valid point. Despite the lack of isolation between pieces of software, I too feel more confident about what's running on my Linux distros. That's not to say that "sandboxing is for noobs", but it's an interesting point. It's like how people in very rural areas can feel perfectly safe not locking doors and stuff, sleeping outside, etc., while that would be extremely foolish to do in the middle of certain cities, in certain neighborhoods. Different environments, different dangers, and I think it's fine to enjoy the benefits of a safer environment. Safety in this case is not provided by physical distance between homes but by curation of software done by nonprofit groups and selection of nearly only open source software with easy building of packages and tracking of changes in the source. > Did you compile them yourselves? Did you compile the compiler? There's no such thing as perfect security, and I think you know that. If you think your compiler may be compromised, there's stuff you could do, you just have to evaluate where the paranoia starts and stop before then.
amstan 3y ago
Do you trust your OS, compiler it was compiled with, and then trust all the hardware it's running on (which is probably even more insidious and capable of hiding stuff). Let's not pretend that just because there's a sandbox at a higher level of the stack and some kind of user ability to accept/deny operations that things are secure.
- tiberious726 3y ago
  Eh, defense in depth, if we make a huge mess of overlapping detection systems, good luck inserting a compiler quine to bypass them all.
tiberious726 3y ago
> Did you compile the compiler? Do you trust trust? (And no differential compilation isn't an actual solution.)

waplot 3y ago

> the bonus point is that I can have access to its source code Are you actually reading all the code before you run it? Are you re-reading it for each update? If not, then what's the point of bragging about having access to the source? The point of sandboxing is that it's impractical to reliably audit, on a continuous basis, the massive volume of software that the average person runs. It's more economical to apply the least-privileged principle, and only give apps access to the things they need to function.

jolmg 3y ago
> Are you actually reading all the code before you run it? Are you re-reading it for each update? If not, then what's the point of bragging about having access to the source? Not every user needs to read everything. We can read pieces of what we use and trust others to also read pieces of what they use. We can also place some amount of trust that there's a body of people that have read code before we started using it, and that it's only the new changes that need the more review. People can also use reputation to make safety in review more economical. Sandboxing is not bad, but it's not the only way that security can be achieved. Having a good social infrastructure also helps.
- autoexec 3y ago
  Not every user has to read every line of code, but I do sometimes wonder how many open source products have never been read by anyone outside of the people who wrote/maintain it, and for those projects where anyone has reviewed the code, how many of them were really qualified to understand what they were seeing? I still believe that having the code available for review is important, but I don't think it's a reliable means of saving people from insecure or malicious software.
  - jolmg 3y ago
    > I still believe that having the code available for review is important, but I don't think it's a reliable means of saving people from insecure or malicious software. Just having the code available, in and of itself, is probably not. However, the presence of the source is not the only thing you have to provide reliance. For Archlinux, for example, different package repos have different requirements and provide different levels of safety. You can put more trust in packages in core than you can those in extra, and you can trust those in extra more than you can those in the AUR. Anyone can push packages to the AUR, and so can they to other package repos like those of different languages (rubygems, hackage, etc.). Different languages will have different communities and you can get a feel for how trustworthy they are as a whole, based on their requirements, etc. This is like the difference in safety in different cities. You can check the author and get some kind of idea as to how much reputation they're holding. You can also check the package maintainer and get some kind of idea as to how much reputation they're holding. You can check how many other people trust that software, and if there's any particular notable ones. You can see how well established and widely-adopted the development process is formulated in the homepage/github/etc. You can also review the source yourself, and even if you're not some security expert, that doesn't mean your review is absolutely worthless. It's got a score. Put a score on every source of trust, add them up, and check with your risk tolerance. You don't need to do everything. If I decide to walk on a street, I'm not checking the crime statistics there, the internal state of the nearby police department, etc. I'm mostly deciding based on the city/neighborhood I'm in, how populated the street is, the state of the people there at a glance, and that's generally more than enough for most people. > but I do sometimes wonder how many open source products have never been read by anyone outside of the people who wrote/maintain it, and for those projects where anyone has reviewed the code, how many of them were really qualified to understand what they were seeing? In case my point was lost in my ramble, you don't have to base your decision on trusting a particular piece of open source software based on how much you trust the whole body of open source software in existence. You can decide to e.g. trust the official repos of a distro based on how that curation works, so trust the packages in it and not the software outside it (e.g. the AUR or random Github repos), and you can decide to trust based on other signs of your choice like that, too.

kaba0 3y ago

System security doesn’t care about your feelings — any rogue program, or even an npm install can encrypt your whole drive, or install a keylogger. This is not true of android and ios.