3 ms·

> I totally agree with that and have been a long time proponent of liability for damage caused by software bugs. But that would have to be all bugs, not just so

> I totally agree with that and have been a long time proponent of liability for damage caused by software bugs. But that would have to be all bugs, not just some classes of bugs. Why? That goes against everything we've done to categorize bugs - we do not treat all bugs the same, and we would not consider all bugs to be due to negligence. > D. Only with a garbage collector or a 'safe' annotation. Rust has the opposite - a safe language by default. > And by the way, rust is only 'memory safe' as long as you don't disable the safety mechanisms, so I think 'memory safe by default' would be a better way to describe it. That's fine, memory safe by default is an acceptable way to refer to it. It's worth noting that I have written thousands of lines of rust code and never published code with a single line of unsafe. None of my projects have required it. So 'by default' is pretty powerful, since I've never ever needed to opt out.

jacquesm 10y ago
> Why? That goes against everything we've done to categorize bugs - we do not treat all bugs the same, and we would not consider all bugs to be due to negligence. That would be something you could only know by evaluating this on a bug-by-bug basis, the important thing to realize is that to an end user it simply does not matter what class of bug caused their data-loss, loss of privacy or loss of assets.
- staticassertion 10y ago
  My point is that not all bugs lead to data loss or loss of privacy. But yes, I agree. That said, I feel that we're now talking about memory safety vs semantic safety. We can certainly prove a program is entirely memory safe. Rust's type system is prove, so the work is then to prove the unsafe code safe (actively being researched). There is no way to prove all semantics of a program (Rice's theorem). Therefor I would argue that a bug is due to a semantic issue is not necessarily negligent, whereas we could easily see memory safety issues from using C as a case of negligence. But in terms of liability they would likely both fall into the same bucket.
  - jacquesm 10y ago
    Negligence in the legal sense of the word revolves around care. If someone is maintaining some codebase and causes a memory safety related bug you would have to look at that bug in isolation and what the person did to avoid it. Saying 'you should have rewritten this in rust in order to avoid liability' is not a standard of care that anybody will ever be held to. So the ideal as you perceive it is so far from realistic that I do not believe pursuing that road is fruitful. What we can do is class bugs (or actually, the results of bugs, the symptoms that cause quantifiable losses) in general as a source of (limited) liability. This will put those parties out of business that are unable to get their house in order without mandating one technology over another (which would definitely be seen as giving certain parties a competitive edge, something I don't think will be ever done). So that's why I believe that solution is the better one. But in a perfect world your solution would - obviously - be the better one, unfortunately we live in this one.
    - staticassertion 10y ago
      > Saying 'you should have rewritten this in rust in order to avoid liability' is not a standard of care that anybody will ever be held to. Why is 'you should not have exposed C code to the internet' an unreasonable basis for care? I'm not saying your approach is wrong, I think they're not mutually exclusive - your solution would provide incentive to not use C in a technology agnostic way. But at some point isn't it just irresponsible to write critical infrastructure, or code that exposes user information, in a language that has historically been a disaster for security?
      - jacquesm 10y ago
        > Why is 'you should not have exposed C code to the internet' an unreasonable basis for care? Because it does not mesh with reality. There are 100's of millions of lines of C code exposed to the internet in all layers of the stack. So if you start off with a hardcore position like that you virtually ensure that your plan will not be adopted. It's the legacy that is the problem, not the future.

jacquesm 10y ago

> Why? That goes against everything we've done to categorize bugs - we do not treat all bugs the same, and we would not consider all bugs to be due to negligence. That would be something you could only know by evaluating this on a bug-by-bug basis, the important thing to realize is that to an end user it simply does not matter what class of bug caused their data-loss, loss of privacy or loss of assets.

staticassertion 10y ago
My point is that not all bugs lead to data loss or loss of privacy. But yes, I agree. That said, I feel that we're now talking about memory safety vs semantic safety. We can certainly prove a program is entirely memory safe. Rust's type system is prove, so the work is then to prove the unsafe code safe (actively being researched). There is no way to prove all semantics of a program (Rice's theorem). Therefor I would argue that a bug is due to a semantic issue is not necessarily negligent, whereas we could easily see memory safety issues from using C as a case of negligence. But in terms of liability they would likely both fall into the same bucket.
- jacquesm 10y ago
  Negligence in the legal sense of the word revolves around care. If someone is maintaining some codebase and causes a memory safety related bug you would have to look at that bug in isolation and what the person did to avoid it. Saying 'you should have rewritten this in rust in order to avoid liability' is not a standard of care that anybody will ever be held to. So the ideal as you perceive it is so far from realistic that I do not believe pursuing that road is fruitful. What we can do is class bugs (or actually, the results of bugs, the symptoms that cause quantifiable losses) in general as a source of (limited) liability. This will put those parties out of business that are unable to get their house in order without mandating one technology over another (which would definitely be seen as giving certain parties a competitive edge, something I don't think will be ever done). So that's why I believe that solution is the better one. But in a perfect world your solution would - obviously - be the better one, unfortunately we live in this one.
  - staticassertion 10y ago
    > Saying 'you should have rewritten this in rust in order to avoid liability' is not a standard of care that anybody will ever be held to. Why is 'you should not have exposed C code to the internet' an unreasonable basis for care? I'm not saying your approach is wrong, I think they're not mutually exclusive - your solution would provide incentive to not use C in a technology agnostic way. But at some point isn't it just irresponsible to write critical infrastructure, or code that exposes user information, in a language that has historically been a disaster for security?
    - jacquesm 10y ago
      > Why is 'you should not have exposed C code to the internet' an unreasonable basis for care? Because it does not mesh with reality. There are 100's of millions of lines of C code exposed to the internet in all layers of the stack. So if you start off with a hardcore position like that you virtually ensure that your plan will not be adopted. It's the legacy that is the problem, not the future.