6 ms·

I'm baffled by that opinion. The fact that memory-unsafe software keeps on being produced in C/C++ is a good thing? The capabilities of criminals to run local (

by DCKing 12y ago

I'm baffled by that opinion. The fact that memory-unsafe software keeps on being produced in C/C++ is a good thing? The capabilities of criminals to run local (or remote!) root exploits on many devices is offset by the fact that some hackers can tinker with them? Freedom should be achieved in different ways. Please don't make freedom and security contradictions.

userbinator 12y ago
Yes, it's definitely controversial but I think a little bit of insecurity is a good thing but not too much -- the question is how much. Consider that had the NSA been far more secure in their processes, the whole Snowden thing may have never happened... which is somewhat ironic. > Freedom should be achieved in different ways. Please don't make freedom and security contradictions. In an ideal world, they wouldn't be. Unfortunately that's not how it is in reality.
- DCKing 12y ago
  So what do you think about the NSA's capabilities to easily rootkit your "free" exploitable device? I don't think this is a consistent worldview.
  - coldtea 12y ago
    Freedom is not about consistency in everything.
    - DCKing 12y ago
      I've never said that freedom is about consistency. Opinions should be consistent if they are to be taken seriously. This guy wants to intentionally leave software exploitable, ready to be unknowingly hacked by criminals or governments, and call it freedom. And he gets upvoted for it!
      - userbinator 12y ago
        What's not consistent? Also, it seems that "criminals" are the new "terrorists".
  - 9mit3t2m9h9a 12y ago
    To play a devil's advocate, I want to answer this directly as answered. Available information indicates that NSA used various coercion tactics to ensure cooperation from various companies and that it has the methods to ensure hardware modifications in its own interests. So the damage to NSA from improving security too much is less than damage to my ability to use the computing device I have paid for as an actual computing device. Of course we should also consider smaller threats. But the better the platform is locked down, the less limitations there ae for advertiser-friendly platform design, which makes people expect a lot of permissions requested by applications, so phishing and trojans become easier. The problem here is about the effects of scale: it is hard to produce just a few thousands phones with good specs.
  - userbinator 12y ago
    That freedom also means I have the freedom to modify my device after exploiting it in order to remove those exploits. On the other hand, a device that is completely unexploitable due to being written in a strongly safe language, would mean I no longer have that freedom - and while it may be unexploitable to everyone else, I'm pretty sure the NSA has its ways to get in anyway; if it does, then there's no escape.
    - bronson 12y ago
      So, you like languages that are prone to obscure bugs because they allow you to remain competitive with the NSA?
weland 12y ago
Practical experience shows that once you run into even routine systems programming elements, like writing device drivers and whatnot, you eventually have to concede some safety, or end up with an unprogrammable behemoth of such baroque complexity that you likely have more security holes, just of some other kind. There has been a lot of research into this back in the 1990s; most of the useable results produced security by architecture rather than tools.
- pohl 12y ago
  It's almost as if what one would want is a language where you could shrink unsafe operations to as small a footprint as possible by confining them within a block with a special keyword, like this: unsafe { … } Someone should invent such a thing. Edit: …yeah, I was being tongue-in-cheek. This is exactly what Rust provides. http://doc.rust-lang.org/rust.html#unsafety http://doc.rust-lang.org/rust.html#unsafety "...When a programmer has sufficient conviction that a sequence of potentially unsafe operations is actually safe, they can encapsulate that sequence (taken as a whole) within an unsafe block. The compiler will consider uses of such code safe, in the surrounding context…"
  - ygra 12y ago
    - http://msdn.microsoft.com/library/chfa2zb8.aspx http://msdn.microsoft.com/library/chfa2zb8.aspx - http://doc.rust-lang.org/rust.html#unsafe-blocks http://doc.rust-lang.org/rust.html#unsafe-blocks
  - Touche 12y ago
    If I call a function that is running unsafe { } inside of it, do I know? Because I really want to know. And I want my function to be marked as unsafe as well (because it is) as well as any function calling my function, etc.
    - steveklabnik 12y ago
      You don't know, but you can use a compiler flag that will tell you if you are. > I want my function to be marked as unsafe as well (because it is) This misunderstands the nature of `unsafe`. `unsafe` means "I promise that this is actually safe, even thought it can't be inferred." Take, for example, a type which has mutable, shared state, but enforces all access through a mutex[1]. This type presents a safe interface, but the compiler can't know that it's safe, so you have to use `unsafe` internally. 1: http://static.rust-lang.org/doc/master/std/cell/struct.RefCell.html http://static.rust-lang.org/doc/master/std/cell/struct.RefCe...
taeric 12y ago
I think a lot of us are somewhat happy with freedom being maintained by the laws of the land. Granted, those do seem under attack, as well. Oddly, by a similar mantra as what leads type safety. Consider, in a "type safe" law system, intent doesn't matter. Only what you did. Now, look at the laws that run on that principle. Now, I personally think this is probably orthogonal to type safe programs. But I'm not completely convinced, yet. Type safe programming seems hamstrung by the fact that a type system only really protects that which is specified in the type system. Which seems to mean you can't easily have a variety of ways to do things, as ultimately the type system has to grow to encompass all of the system. Now, I grant I'm probably just soured by some bad systems in the past where a change to one part required a rework of the entire system.
- Jtsummers 12y ago
  Most type safe systems have escape hatches that allow for conversion between types. Also, IME, type safe languages don't hobble me as a programmer. However, the systems and things I work on (and am trying to get work on) have generally well considered specs associated with them. Be it radio protocols, file formats, or whatever. A type safe language (haskell, sml, ocaml, ada, rust (it seems, not explored it much yet), etc.) can really help with these projects. Instead of needing a dictionary translating what magic # 134 means if it's used in this context (god, these old fortran programs break me), we can actually specify things in code in sane, clear ways that map from spec/design to code cleanly. OO, in theory, can help us with this, but it also adds a lot of overhead to create a ton of classes when really we want integers that the compiler knows some are meant to be temperature and some are meant to be pressure. If you start adding temperature and pressure, it flags it. If there's some formula where that actually makes sense, you deliberately, intentionally, explicitly handle the conversion. This is a good thing. Slightly more verbose code, but such a boon for mainenance and v&v work.
  - taeric 12y ago
    Doesn't shock me too much. The experience I have had is when folks basically try to do their programming in the type system. This can work for some cases, maybe all if you "do it right." I've not been lucky enough to see that. Instead, I like it when the types are basically there to help, not force, you.

by DCKing 12y ago

userbinator 12y ago

Yes, it's definitely controversial but I think a little bit of insecurity is a good thing but not too much -- the question is how much. Consider that had the NSA been far more secure in their processes, the whole Snowden thing may have never happened... which is somewhat ironic. > Freedom should be achieved in different ways. Please don't make freedom and security contradictions. In an ideal world, they wouldn't be. Unfortunately that's not how it is in reality.

DCKing 12y ago
So what do you think about the NSA's capabilities to easily rootkit your "free" exploitable device? I don't think this is a consistent worldview.
- coldtea 12y ago
  Freedom is not about consistency in everything.
  - DCKing 12y ago
    I've never said that freedom is about consistency. Opinions should be consistent if they are to be taken seriously. This guy wants to intentionally leave software exploitable, ready to be unknowingly hacked by criminals or governments, and call it freedom. And he gets upvoted for it!
    - userbinator 12y ago
      What's not consistent? Also, it seems that "criminals" are the new "terrorists".
- 9mit3t2m9h9a 12y ago
  To play a devil's advocate, I want to answer this directly as answered. Available information indicates that NSA used various coercion tactics to ensure cooperation from various companies and that it has the methods to ensure hardware modifications in its own interests. So the damage to NSA from improving security too much is less than damage to my ability to use the computing device I have paid for as an actual computing device. Of course we should also consider smaller threats. But the better the platform is locked down, the less limitations there ae for advertiser-friendly platform design, which makes people expect a lot of permissions requested by applications, so phishing and trojans become easier. The problem here is about the effects of scale: it is hard to produce just a few thousands phones with good specs.
- userbinator 12y ago
  That freedom also means I have the freedom to modify my device after exploiting it in order to remove those exploits. On the other hand, a device that is completely unexploitable due to being written in a strongly safe language, would mean I no longer have that freedom - and while it may be unexploitable to everyone else, I'm pretty sure the NSA has its ways to get in anyway; if it does, then there's no escape.
  - bronson 12y ago
    So, you like languages that are prone to obscure bugs because they allow you to remain competitive with the NSA?

weland 12y ago

Practical experience shows that once you run into even routine systems programming elements, like writing device drivers and whatnot, you eventually have to concede some safety, or end up with an unprogrammable behemoth of such baroque complexity that you likely have more security holes, just of some other kind. There has been a lot of research into this back in the 1990s; most of the useable results produced security by architecture rather than tools.

pohl 12y ago
It's almost as if what one would want is a language where you could shrink unsafe operations to as small a footprint as possible by confining them within a block with a special keyword, like this: unsafe { … } Someone should invent such a thing. Edit: …yeah, I was being tongue-in-cheek. This is exactly what Rust provides. http://doc.rust-lang.org/rust.html#unsafety http://doc.rust-lang.org/rust.html#unsafety "...When a programmer has sufficient conviction that a sequence of potentially unsafe operations is actually safe, they can encapsulate that sequence (taken as a whole) within an unsafe block. The compiler will consider uses of such code safe, in the surrounding context…"
- ygra 12y ago
  - http://msdn.microsoft.com/library/chfa2zb8.aspx http://msdn.microsoft.com/library/chfa2zb8.aspx - http://doc.rust-lang.org/rust.html#unsafe-blocks http://doc.rust-lang.org/rust.html#unsafe-blocks
- Touche 12y ago
  If I call a function that is running unsafe { } inside of it, do I know? Because I really want to know. And I want my function to be marked as unsafe as well (because it is) as well as any function calling my function, etc.
  - steveklabnik 12y ago
    You don't know, but you can use a compiler flag that will tell you if you are. > I want my function to be marked as unsafe as well (because it is) This misunderstands the nature of `unsafe`. `unsafe` means "I promise that this is actually safe, even thought it can't be inferred." Take, for example, a type which has mutable, shared state, but enforces all access through a mutex[1]. This type presents a safe interface, but the compiler can't know that it's safe, so you have to use `unsafe` internally. 1: http://static.rust-lang.org/doc/master/std/cell/struct.RefCell.html http://static.rust-lang.org/doc/master/std/cell/struct.RefCe...

taeric 12y ago

I think a lot of us are somewhat happy with freedom being maintained by the laws of the land. Granted, those do seem under attack, as well. Oddly, by a similar mantra as what leads type safety. Consider, in a "type safe" law system, intent doesn't matter. Only what you did. Now, look at the laws that run on that principle. Now, I personally think this is probably orthogonal to type safe programs. But I'm not completely convinced, yet. Type safe programming seems hamstrung by the fact that a type system only really protects that which is specified in the type system. Which seems to mean you can't easily have a variety of ways to do things, as ultimately the type system has to grow to encompass all of the system. Now, I grant I'm probably just soured by some bad systems in the past where a change to one part required a rework of the entire system.

Jtsummers 12y ago
Most type safe systems have escape hatches that allow for conversion between types. Also, IME, type safe languages don't hobble me as a programmer. However, the systems and things I work on (and am trying to get work on) have generally well considered specs associated with them. Be it radio protocols, file formats, or whatever. A type safe language (haskell, sml, ocaml, ada, rust (it seems, not explored it much yet), etc.) can really help with these projects. Instead of needing a dictionary translating what magic # 134 means if it's used in this context (god, these old fortran programs break me), we can actually specify things in code in sane, clear ways that map from spec/design to code cleanly. OO, in theory, can help us with this, but it also adds a lot of overhead to create a ton of classes when really we want integers that the compiler knows some are meant to be temperature and some are meant to be pressure. If you start adding temperature and pressure, it flags it. If there's some formula where that actually makes sense, you deliberately, intentionally, explicitly handle the conversion. This is a good thing. Slightly more verbose code, but such a boon for mainenance and v&v work.
- taeric 12y ago
  Doesn't shock me too much. The experience I have had is when folks basically try to do their programming in the type system. This can work for some cases, maybe all if you "do it right." I've not been lucky enough to see that. Instead, I like it when the types are basically there to help, not force, you.