3 ms·

What about software for F18s or missile defense systems?

Jtsummers 5y ago
My view: They should (and when written by government employees are) be public domain. But they ought to be classified to an appropriate level if they contain information that warrants classification. Where possible, the programs should be written in a more data-driven manner, where the actual classified portions are contained in data files that are separated from the program source code. This permits you to release the source code without issue (it tells you very little about the actual systems), and then you only have to keep classified the data used by the program and assembled (data + executable) system. If the program cannot be properly separated from something warranting classification, modular programming is the solution. Divide the program into an unclassified and classified portion. Keeping the former in the public domain and visible (at least with no more than a FOIA request, ideally with less effort) and the latter properly secured.
- beerandt 5y ago
  This doesn't work, because the complexity and reach of the systems are themselves sensitive information about capabilities. Even the un-classified stuff is mind-blowing, including thinking about how to even begin running/building a system like that. Software code would reveal way too much of that, even after being sterilized.
  - Jtsummers 5y ago
    It does work. It's called software engineering, you separate concerns between subsystems so you can assemble them separately and with alternative implementations of the other subsystems. Like if you have a classified (for whatever reason) subsystem you can provide an alternative implementation that at least lets you build the system, possibly doing what amounts to a no-op or some bare-minimum version (perhaps slower and stupider using public algorithms if the classified algorithms are classified for some key mathematical or physical insight). Regarding running/building, sure, it's harder. But mostly because of expense, the specific examples were military and US DOD and its contractors buy compilers. So buy a license for Green Hills or similar and you can build it. Buy an ARM development board and you can run it. "ARM?!?!?" Yes, ARM. Embedded systems in the modern era (that is to say, after 2000 but starting sometime in the 1980s) use off-the-shelf chips, perhaps hardened versions for things like satellites. "Hardened" doesn't necessarily change the architecture, mostly just ties them to an old version of it. If the software is from pre-1990 there's a good chance it is running on a bespoke architecture, but after that point, and certainly after 2000, it became rarer. Now, whether they will release the code is another matter. Doing this determination requires good upfront engineering or a lot of analysis before releasing it. But good engineering has been known to happen from time to time, even by the government. More practically, though, the software will mostly be developed by contractors who will retain the copyright and so it won't be public domain.
    - beerandt 5y ago
      If software is released for a sub-system that enemies don't know exists, or for a senior system that makes calls to that sub-system, damaging information is being revealed right there. Even just exposing data structures will reveal capabilities by virtue of the data created by them. If an fighter pilot's battlefield/ situational awareness software makes calls to 4 known methods of battlefield communication, and also to an additional unknown one, then that reveals info, even without knowing anything else about it. Maybe you're intending that all of these types of inquiries, or data sharing capabilities be redacted or sanitized somehow, but that seems like a huge undertaking in itself, especially if you expect a working product. And then what would that resulting skeleton product's remaining value be, for the extra effort put into releasing it? Besides potentially helping other countries close the capability gap.
fsflover 5y ago
1. If revealing their source code breaks security, then it's security by obscurity, which does not work. 2. Every similar law has exceptions concerning classified information.
- Nevermark 5y ago
  Security by obscurity works fantastically when used intelligently. S-by-O got a bad reputation due to people imagining it was the last word in security, when it really is just the beginning. Passwords are literally purified security-by-obscurity. I can't think of any security technology or method that doesn't have a security by obscurity component. Or that isn't enhanced with an additional layer of it.
  - fsflover 5y ago
    Passwords are not security by obscurity: https://security.stackexchange.com/questions/147378/passwords-and-security-by-obscurity https://security.stackexchange.com/questions/147378/password....
    - Nevermark 5y ago
      The page you linked to doesn't contradict what I wrote. It does suggest that a common usage of the term "security by obscurity" can mean security ONLY by obscurity. Which I made clear was not my usage. The other mis-use of the term is the opposite overreaction is to forget that obscurity does remain an indispensable component of practical security. Its most common form being as a password (or biometric) used to unlock an otherwise impenetrable (for practical purposes) system. Without an obscured backdoor (password, biometric, ...) the an otherwise completely secure system would not even be accessible to its owner.
josephcsible 5y ago
Free software doesn't require you to give a copy to anyone who asks. It just means that if you do give someone a copy, it needs to include the source code and certain legal rights. Presumably, the US isn't going to give copies of software for F18s or missile defense systems away like candy, so I don't see why this requirement would be a problem for those things.

My view: They should (and when written by government employees are) be public domain. But they ought to be classified to an appropriate level if they contain information that warrants classification. Where possible, the programs should be written in a more data-driven manner, where the actual classified portions are contained in data files that are separated from the program source code. This permits you to release the source code without issue (it tells you very little about the actual systems), and then you only have to keep classified the data used by the program and assembled (data + executable) system. If the program cannot be properly separated from something warranting classification, modular programming is the solution. Divide the program into an unclassified and classified portion. Keeping the former in the public domain and visible (at least with no more than a FOIA request, ideally with less effort) and the latter properly secured.

beerandt 5y ago
This doesn't work, because the complexity and reach of the systems are themselves sensitive information about capabilities. Even the un-classified stuff is mind-blowing, including thinking about how to even begin running/building a system like that. Software code would reveal way too much of that, even after being sterilized.
- Jtsummers 5y ago
  It does work. It's called software engineering, you separate concerns between subsystems so you can assemble them separately and with alternative implementations of the other subsystems. Like if you have a classified (for whatever reason) subsystem you can provide an alternative implementation that at least lets you build the system, possibly doing what amounts to a no-op or some bare-minimum version (perhaps slower and stupider using public algorithms if the classified algorithms are classified for some key mathematical or physical insight). Regarding running/building, sure, it's harder. But mostly because of expense, the specific examples were military and US DOD and its contractors buy compilers. So buy a license for Green Hills or similar and you can build it. Buy an ARM development board and you can run it. "ARM?!?!?" Yes, ARM. Embedded systems in the modern era (that is to say, after 2000 but starting sometime in the 1980s) use off-the-shelf chips, perhaps hardened versions for things like satellites. "Hardened" doesn't necessarily change the architecture, mostly just ties them to an old version of it. If the software is from pre-1990 there's a good chance it is running on a bespoke architecture, but after that point, and certainly after 2000, it became rarer. Now, whether they will release the code is another matter. Doing this determination requires good upfront engineering or a lot of analysis before releasing it. But good engineering has been known to happen from time to time, even by the government. More practically, though, the software will mostly be developed by contractors who will retain the copyright and so it won't be public domain.
  - beerandt 5y ago
    If software is released for a sub-system that enemies don't know exists, or for a senior system that makes calls to that sub-system, damaging information is being revealed right there. Even just exposing data structures will reveal capabilities by virtue of the data created by them. If an fighter pilot's battlefield/ situational awareness software makes calls to 4 known methods of battlefield communication, and also to an additional unknown one, then that reveals info, even without knowing anything else about it. Maybe you're intending that all of these types of inquiries, or data sharing capabilities be redacted or sanitized somehow, but that seems like a huge undertaking in itself, especially if you expect a working product. And then what would that resulting skeleton product's remaining value be, for the extra effort put into releasing it? Besides potentially helping other countries close the capability gap.

fsflover 5y ago

1. If revealing their source code breaks security, then it's security by obscurity, which does not work. 2. Every similar law has exceptions concerning classified information.

Nevermark 5y ago
Security by obscurity works fantastically when used intelligently. S-by-O got a bad reputation due to people imagining it was the last word in security, when it really is just the beginning. Passwords are literally purified security-by-obscurity. I can't think of any security technology or method that doesn't have a security by obscurity component. Or that isn't enhanced with an additional layer of it.
- fsflover 5y ago
  Passwords are not security by obscurity: https://security.stackexchange.com/questions/147378/passwords-and-security-by-obscurity https://security.stackexchange.com/questions/147378/password....
  - Nevermark 5y ago
    The page you linked to doesn't contradict what I wrote. It does suggest that a common usage of the term "security by obscurity" can mean security ONLY by obscurity. Which I made clear was not my usage. The other mis-use of the term is the opposite overreaction is to forget that obscurity does remain an indispensable component of practical security. Its most common form being as a password (or biometric) used to unlock an otherwise impenetrable (for practical purposes) system. Without an obscured backdoor (password, biometric, ...) the an otherwise completely secure system would not even be accessible to its owner.

josephcsible 5y ago

Free software doesn't require you to give a copy to anyone who asks. It just means that if you do give someone a copy, it needs to include the source code and certain legal rights. Presumably, the US isn't going to give copies of software for F18s or missile defense systems away like candy, so I don't see why this requirement would be a problem for those things.