3 ms·

This is what I don't understand about Stallman. Even if we all agree to use free software, that's only the beginning. The next step is nobody is going to use we

by Flankk 4y ago

This is what I don't understand about Stallman. Even if we all agree to use free software, that's only the beginning. The next step is nobody is going to use web applications anymore. Okay now that we're all liberated from corporate espionage what about how the software is made. You can't trust package maintainers any more than you can trust companies. So we all use GNU/Gentoo. As you said, the compiler may be compromised too. Well you learn the dark art of compiling a compiler. But wait, your entire computer is a black box with no schematics whatsoever. Rinse and repeat.

jstanley 4y ago
This is just a long-winded way of saying "if you can't solve everything, don't solve anything", which is no way to approach problems.
- Flankk 4y ago
  No, you've missed the point. Don't you understand? The software cannot be trusted whatsoever unless you control the entire stack. So you haven't solved anything. Also, if you think a paragraph is long winded then I'm sure you have never listened to Stallman.
  - seanw444 4y ago
    You can't control when an apocalypse happens, so you might as well just not prepare for it. That's essentially the same argument, which is ridiculous. Of course you can. And you should. Just because you can't control the entirety of a system, doesn't mean you can't take steps to minimize risks and exposure, and shrink the attack surface.
    - Flankk 4y ago
      That is a stupid analogy. I'm talking about a machine. You are not in control unless you build the machine yourself. Even if you were provided schematics, you cannot be sure they are accurate. The point is free software does not minimize risk. It's a false sense of security. For things you actually care about, such a surveillance, what if I told you there is a hardware backdoor in your CPU allowing the government to spy on you? Do you realize that is already known? What about the fingerprint scanner. How can you be sure the same is not true of the hardware storing that information?
      - jstanley 4y ago
        I built a CPU myself out of 74xx logic, but I can't be sure that every input on every chip isn't also connected internally to an integrated computer that stores everything it sees and can transmit it to a van at 20 metres range (easily enough for someone to drive up to my house and retrieve the contents periodically). The attacker can then reconstruct everything that happened on the CPU and work out what I've been up to. Or, more likely, throw away almost everything and only look at what was printed to the console, because everything interesting goes to the console anyway. In fact this would be easier-than-average to achieve because the clock speed is low, I don't run the machine for very long or very often, and the density of actual electronics to "free space" on the ICs is very low (more space for shenanigans), and all my schematics are on my github project so even though you don't know which chip is connected to which other, you shouldn't have too much trouble deriving it. So what now? Do we just give up? Is all computing fundamentally impossible? Or do we accept that nothing is perfect and just get on with it?
      - LeFantome 4y ago
        You are not smart enough to understand his analogy. The point is, only my point is valid and anybody that cannot see that is stupid. There, I think replicated the level of snark and useful discourse fairly well.
dane-pgp 4y ago
> The next step is nobody is going to use web applications anymore. Well, we should certainly be wary of falling into the trap known as "Service as a Software Substitute (SaaSS)"[0], but in principle it is possible for a web app to work entirely on the client side and be distributed under a Free licence (and for the browser to enforce that, if the web developer is careful).[1] > You can't trust package maintainers any more than you can trust companies. The point is, if you have the source code, you don't have to trust the package maintainers. Instead you can trust whoever you choose to audit the source code for you, which might be yourself (if you're very skilled, and very untrusting), or it could be the community. I admit that "trust the community" usually means "Assume that someone somewhere will find any critical bugs before they affect you, and assume that developers won't destroy their reputation when they know they'll eventually get caught", but we are slowly moving towards a system of community code reviews for all Free software[2]. (Obviously reproducible builds, and boostrappable builds, are necessary steps to take full advantage of this). > But wait, your entire computer is a black box with no schematics whatsoever. Rinse and repeat. Nope, that's the final step (unless you think the aliens that built this simulation put backdoors into the laws of physics). As for how we trust hardware, fortunately there are projects to make computers out of chips that can be safely reasoned about. You have to ask yourself what your threat model is. Do you think the NSA is hiding a hardware backdoor in every FPGA, which detects when someone is running a compilation process and makes sure to install a software backdoor in any compiler or kernel it detects? What if multiple people on multiple homebrew computers all carried out the same build process and hashed the results, and all the hashes agreed? What if you ran these processes in virtual machines that implement custom architectures that have never been seen before? Eventually you start to run into information-theoretic problems trying explain how such a backdoor can remain hidden and effective. [0] https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s... [1] https://www.gnu.org/software/librejs/index.html https://www.gnu.org/software/librejs/index.html [2] https://github.com/crev-dev/crev https://github.com/crev-dev/crev
- MaxBarraclough 4y ago
  > if you have the source code, you don't have to trust the package maintainers I wouldn't go that far. It's possible for a skilled malicious developer to conceal malicious behaviour in their code, to make it hard to detect and plausibly deniable as a bug. Speaking of which, I've never understood why SELinux is adopted so uncritically considering it was developed by the government agency behind [0]. [0] https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html https://www.schneier.com/blog/archives/2013/09/the_nsa_is_br...

by Flankk 4y ago

jstanley 4y ago

This is just a long-winded way of saying "if you can't solve everything, don't solve anything", which is no way to approach problems.

Flankk 4y ago
No, you've missed the point. Don't you understand? The software cannot be trusted whatsoever unless you control the entire stack. So you haven't solved anything. Also, if you think a paragraph is long winded then I'm sure you have never listened to Stallman.
- seanw444 4y ago
  You can't control when an apocalypse happens, so you might as well just not prepare for it. That's essentially the same argument, which is ridiculous. Of course you can. And you should. Just because you can't control the entirety of a system, doesn't mean you can't take steps to minimize risks and exposure, and shrink the attack surface.
  - Flankk 4y ago
    That is a stupid analogy. I'm talking about a machine. You are not in control unless you build the machine yourself. Even if you were provided schematics, you cannot be sure they are accurate. The point is free software does not minimize risk. It's a false sense of security. For things you actually care about, such a surveillance, what if I told you there is a hardware backdoor in your CPU allowing the government to spy on you? Do you realize that is already known? What about the fingerprint scanner. How can you be sure the same is not true of the hardware storing that information?
    - jstanley 4y ago
      I built a CPU myself out of 74xx logic, but I can't be sure that every input on every chip isn't also connected internally to an integrated computer that stores everything it sees and can transmit it to a van at 20 metres range (easily enough for someone to drive up to my house and retrieve the contents periodically). The attacker can then reconstruct everything that happened on the CPU and work out what I've been up to. Or, more likely, throw away almost everything and only look at what was printed to the console, because everything interesting goes to the console anyway. In fact this would be easier-than-average to achieve because the clock speed is low, I don't run the machine for very long or very often, and the density of actual electronics to "free space" on the ICs is very low (more space for shenanigans), and all my schematics are on my github project so even though you don't know which chip is connected to which other, you shouldn't have too much trouble deriving it. So what now? Do we just give up? Is all computing fundamentally impossible? Or do we accept that nothing is perfect and just get on with it?
    - LeFantome 4y ago
      You are not smart enough to understand his analogy. The point is, only my point is valid and anybody that cannot see that is stupid. There, I think replicated the level of snark and useful discourse fairly well.

dane-pgp 4y ago

> The next step is nobody is going to use web applications anymore. Well, we should certainly be wary of falling into the trap known as "Service as a Software Substitute (SaaSS)"[0], but in principle it is possible for a web app to work entirely on the client side and be distributed under a Free licence (and for the browser to enforce that, if the web developer is careful).[1] > You can't trust package maintainers any more than you can trust companies. The point is, if you have the source code, you don't have to trust the package maintainers. Instead you can trust whoever you choose to audit the source code for you, which might be yourself (if you're very skilled, and very untrusting), or it could be the community. I admit that "trust the community" usually means "Assume that someone somewhere will find any critical bugs before they affect you, and assume that developers won't destroy their reputation when they know they'll eventually get caught", but we are slowly moving towards a system of community code reviews for all Free software[2]. (Obviously reproducible builds, and boostrappable builds, are necessary steps to take full advantage of this). > But wait, your entire computer is a black box with no schematics whatsoever. Rinse and repeat. Nope, that's the final step (unless you think the aliens that built this simulation put backdoors into the laws of physics). As for how we trust hardware, fortunately there are projects to make computers out of chips that can be safely reasoned about. You have to ask yourself what your threat model is. Do you think the NSA is hiding a hardware backdoor in every FPGA, which detects when someone is running a compilation process and makes sure to install a software backdoor in any compiler or kernel it detects? What if multiple people on multiple homebrew computers all carried out the same build process and hashed the results, and all the hashes agreed? What if you ran these processes in virtual machines that implement custom architectures that have never been seen before? Eventually you start to run into information-theoretic problems trying explain how such a backdoor can remain hidden and effective. [0] https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s... [1] https://www.gnu.org/software/librejs/index.html https://www.gnu.org/software/librejs/index.html [2] https://github.com/crev-dev/crev https://github.com/crev-dev/crev

MaxBarraclough 4y ago
> if you have the source code, you don't have to trust the package maintainers I wouldn't go that far. It's possible for a skilled malicious developer to conceal malicious behaviour in their code, to make it hard to detect and plausibly deniable as a bug. Speaking of which, I've never understood why SELinux is adopted so uncritically considering it was developed by the government agency behind [0]. [0] https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html https://www.schneier.com/blog/archives/2013/09/the_nsa_is_br...