8 ms·

> Anything related to privacy or security should be fully tested. How often do you write code that's not related to privacy or security? As soon as you connect

by hannob 10y ago

> Anything related to privacy or security should be fully tested. How often do you write code that's not related to privacy or security? As soon as you connect something to the Internet it's related to privacy and security. The only situation where privacy and security don't matter a whole lot is if your code runs on airgapped devices with very limited tasks.

EpicEng 10y ago
I rarely write code that connects to anything, so almost never? There's a lot of code that's not written by web devs.
- hannob 10y ago
  > I rarely write code that connects to anything, so almost never? Sounds hard to believe. What kind of code would that be? > There's a lot of code that's not written by web devs. There's also a lot more than the web that has some form of connectivity with the Internet (even if it's not directly connected it may still parse data that comes from untrusted sources). There is a widespread belief among many that "security is important, but doesn't matter for me". The most extreme example is obviously IoT ("Who would want to hack my coffeemaker?"), but there's a lot more. The unfortunate truth is: There is hardly any code these days that is not security relevant.
  - nickpsecurity 10y ago
    "Sounds hard to believe. What kind of code would that be?" You do realize there's a bajillion non-networked apps in existence? Word processors, excel, editors/IDE's, system tools (esp monitoring/backup), media players that don't download stuff, compression libraries, MATLAB-style tools for numeric analysis, and so on.
    - hannob 10y ago
      > You do realize there's a bajillion non-networked apps in existence? Word processors, excel, editors/IDE's, system tools (esp monitoring/backup), media players that don't download stuff, compression libraries, MATLAB-style tools for numeric analysis, and so on. All of them parse potentially untrusted inputs. They don't have to be directly network connected to be a security risk. Just pick the first example: A word processor. It is not a security risk only if you can guarantee that you'll only ever open documents that you created yourself. If you ever use it to open documents you got from someone else it needs to take security into consideration.
    - mwexler 10y ago
      Sadly, almost everything you mention involve opening files, and files are often on networks. Standard modal file|open on windows allows http:// http:// access to files on hosted servers, for example. Suddenly, all of these are potentially networked in the hands of users using the code for unintended purposes or in unexpected ways.
      - Jtsummers 10y ago
        But you don't write those dialogs yourself. You write code that calls the system file open dialog. Then, presumably, you do some check on the file for sanity checking (is it the right type? does it parse correctly? does the internal size # equal the value the OS is claiming?). If those checks fail, you report an error. Otherwise, you process it. The source doesn't matter at that point. And if there's a glitch in the dialog for handling HTTP or similar sources, then that's on the system developers to correct, and on you to report if you discover it.
        nickpsecurity 10y ago
        Exactly. All the concerns of networking, the Internet, and the Web go away. It becomes an input validation problem. From there, one can do a format suitable for correct-by-construction auto-generation of the parser. Or can take the common route building a Turing machine into it to fight with over time. ;) Still not writing or patching a networked app.
        Jtsummers 10y ago
        OT: Have you ever read Engineering a Safer World [0] by Nancy Leveson [1]? Seems like something that'd be of interest to you. Started on it this week, my sister is in her class this semester at MIT. I'll be tackling it over the next few weeks, and then her previous text (Safeware) after the new year. [0] https://mitpress.mit.edu/books/engineering-safer-world https://mitpress.mit.edu/books/engineering-safer-world [1] http://sunnyday.mit.edu/ http://sunnyday.mit.edu/
        10y ago
  - ryandrake 10y ago
    > > I rarely write code that connects to anything, so almost never? > Sounds hard to believe. What kind of code would that be? Device drivers, compilers, and some embedded systems come to mind immediately, there are plenty of others out there. I've worked on a lots of software where the only inputs were physical and sensor based, and the only outputs were to the screen. Device didn't even physically have network equipment.
    - hannob 10y ago
      Device drivers are a bad example, they can be extremely security sensitive (particularly so because they usually have kernel privileges). There are few things where security doesn't matter. But they are extremely rare. The situations where programmers think their code isn't security sensitive are probably vastly more common.
      - ryandrake 10y ago
        Good point, but I was addressing the perceived lack of "code that connects to anything". I agree with you that security is a valid concern for most if not all code written.
    - RandomOpinion 10y ago
      >...device drivers... I hope you're joking but I suspect you're not. Device drivers have the highest level of privileged access in many operating systems and code quality for drivers is so uniformly lousy (certain large vendors whose names begin with "N", "A", and particularly "Q", I'm looking at you) that attempting to break the drivers would be among the first things I'd consider if I were trying to root a device.
      - ryandrake 10y ago
        Please see my other reply. I was addressing "unconnected software" not "software without attack surfaces". I agree that security is a concern with all software.
  - EpicEng 10y ago
    I write code that interfaces with hardware (health care imaging systems), processes images, and a little computer vision here and there. Very few service calls in that stack. I jump up 1000 levels of abstraction from time to time, and when I do, I agree that security is extremely important (FDA class III device and HIPAA compliance is mandatory.) I'm also a lead, so I have to know enough to call BS when I hear it from a team member.
tlrobinson 10y ago
Most client-side web app code doesn't have much bearing on privacy/security, aside from avoiding XSS and a few other pitfalls.
Alex3917 10y ago
Right, I meant that in the context of things that tests are designed to catch. E.g. almost no one writes tests to look for unsafe eval or whatever. A good example is that I care a lot about making sure our search endpoint doesn't return private user data. But beyond that, I'd rather just know that the endpoint returns a 200 and let someone tell us if it's broken rather than have an extra three hundred lines of code to see if it's returning the correct results. If we get a ton of users then that will probably change, but for now the cost of writing and maintaining those extra tests wouldn't be worth the benefit.
mannykannot 10y ago
> The only situation where privacy and security don't matter a whole lot is if your code runs on airgapped devices with very limited tasks. That used to be true for the software in cars, but it no longer is. The problems that result are not the fault of the original authors; that belongs to the people who decided to bridge the airgap without thinking through the consequences.

by hannob 10y ago

EpicEng 10y ago

I rarely write code that connects to anything, so almost never? There's a lot of code that's not written by web devs.

hannob 10y ago
> I rarely write code that connects to anything, so almost never? Sounds hard to believe. What kind of code would that be? > There's a lot of code that's not written by web devs. There's also a lot more than the web that has some form of connectivity with the Internet (even if it's not directly connected it may still parse data that comes from untrusted sources). There is a widespread belief among many that "security is important, but doesn't matter for me". The most extreme example is obviously IoT ("Who would want to hack my coffeemaker?"), but there's a lot more. The unfortunate truth is: There is hardly any code these days that is not security relevant.
- nickpsecurity 10y ago
  "Sounds hard to believe. What kind of code would that be?" You do realize there's a bajillion non-networked apps in existence? Word processors, excel, editors/IDE's, system tools (esp monitoring/backup), media players that don't download stuff, compression libraries, MATLAB-style tools for numeric analysis, and so on.
  - hannob 10y ago
    > You do realize there's a bajillion non-networked apps in existence? Word processors, excel, editors/IDE's, system tools (esp monitoring/backup), media players that don't download stuff, compression libraries, MATLAB-style tools for numeric analysis, and so on. All of them parse potentially untrusted inputs. They don't have to be directly network connected to be a security risk. Just pick the first example: A word processor. It is not a security risk only if you can guarantee that you'll only ever open documents that you created yourself. If you ever use it to open documents you got from someone else it needs to take security into consideration.
  - mwexler 10y ago
    Sadly, almost everything you mention involve opening files, and files are often on networks. Standard modal file|open on windows allows http:// http:// access to files on hosted servers, for example. Suddenly, all of these are potentially networked in the hands of users using the code for unintended purposes or in unexpected ways.
    - Jtsummers 10y ago
      But you don't write those dialogs yourself. You write code that calls the system file open dialog. Then, presumably, you do some check on the file for sanity checking (is it the right type? does it parse correctly? does the internal size # equal the value the OS is claiming?). If those checks fail, you report an error. Otherwise, you process it. The source doesn't matter at that point. And if there's a glitch in the dialog for handling HTTP or similar sources, then that's on the system developers to correct, and on you to report if you discover it.
      - nickpsecurity 10y ago
        Exactly. All the concerns of networking, the Internet, and the Web go away. It becomes an input validation problem. From there, one can do a format suitable for correct-by-construction auto-generation of the parser. Or can take the common route building a Turing machine into it to fight with over time. ;) Still not writing or patching a networked app.
        Jtsummers 10y ago
        OT: Have you ever read Engineering a Safer World [0] by Nancy Leveson [1]? Seems like something that'd be of interest to you. Started on it this week, my sister is in her class this semester at MIT. I'll be tackling it over the next few weeks, and then her previous text (Safeware) after the new year. [0] https://mitpress.mit.edu/books/engineering-safer-world https://mitpress.mit.edu/books/engineering-safer-world [1] http://sunnyday.mit.edu/ http://sunnyday.mit.edu/
        10y ago
- ryandrake 10y ago
  > > I rarely write code that connects to anything, so almost never? > Sounds hard to believe. What kind of code would that be? Device drivers, compilers, and some embedded systems come to mind immediately, there are plenty of others out there. I've worked on a lots of software where the only inputs were physical and sensor based, and the only outputs were to the screen. Device didn't even physically have network equipment.
  - hannob 10y ago
    Device drivers are a bad example, they can be extremely security sensitive (particularly so because they usually have kernel privileges). There are few things where security doesn't matter. But they are extremely rare. The situations where programmers think their code isn't security sensitive are probably vastly more common.
    - ryandrake 10y ago
      Good point, but I was addressing the perceived lack of "code that connects to anything". I agree with you that security is a valid concern for most if not all code written.
  - RandomOpinion 10y ago
    >...device drivers... I hope you're joking but I suspect you're not. Device drivers have the highest level of privileged access in many operating systems and code quality for drivers is so uniformly lousy (certain large vendors whose names begin with "N", "A", and particularly "Q", I'm looking at you) that attempting to break the drivers would be among the first things I'd consider if I were trying to root a device.
    - ryandrake 10y ago
      Please see my other reply. I was addressing "unconnected software" not "software without attack surfaces". I agree that security is a concern with all software.
- EpicEng 10y ago
  I write code that interfaces with hardware (health care imaging systems), processes images, and a little computer vision here and there. Very few service calls in that stack. I jump up 1000 levels of abstraction from time to time, and when I do, I agree that security is extremely important (FDA class III device and HIPAA compliance is mandatory.) I'm also a lead, so I have to know enough to call BS when I hear it from a team member.

tlrobinson 10y ago

Most client-side web app code doesn't have much bearing on privacy/security, aside from avoiding XSS and a few other pitfalls.

Alex3917 10y ago

Right, I meant that in the context of things that tests are designed to catch. E.g. almost no one writes tests to look for unsafe eval or whatever. A good example is that I care a lot about making sure our search endpoint doesn't return private user data. But beyond that, I'd rather just know that the endpoint returns a 200 and let someone tell us if it's broken rather than have an extra three hundred lines of code to see if it's returning the correct results. If we get a ton of users then that will probably change, but for now the cost of writing and maintaining those extra tests wouldn't be worth the benefit.

mannykannot 10y ago

> The only situation where privacy and security don't matter a whole lot is if your code runs on airgapped devices with very limited tasks. That used to be true for the software in cars, but it no longer is. The problems that result are not the fault of the original authors; that belongs to the people who decided to bridge the airgap without thinking through the consequences.