6 ms·
Regulation comes up later in the film. Ross Anderson, professor at Cambridge University recently wrote, https://m.cacm.acm.org/magazines/2018/3/225467-making-se
by transpute 9y ago
Regulation comes up later in the film. Ross Anderson, professor at Cambridge University recently wrote, https://m.cacm.acm.org/magazines/2018/3/225467-making-security-sustainable/fulltext https://m.cacm.acm.org/magazines/2018/3/225467-making-securi...
"Once software becomes pervasive in devices that surround us, that are online, and that can kill us, the software industry will have to come of age. As security becomes ever more about safety rather than just privacy, we will have sharper policy debates about surveillance, competition, and consumer protection. The notion that software engineers are not responsible for things that go wrong will be put to rest for good, and we will have to work out how to develop and maintain code that will go on working dependably for decades in environments that change and evolve."
- terminado 9y agoThe Ivory Tower has a way of phrasing concepts such that they are framed by finality and totality. The mentalility comes with having made it through the admissions process, and passing your final exams with a good grade point average, conferring some lofty degree of distinguishment into one's possession. So, to look at the words: The notion that software engineers are not responsible for things that go wrong will be put to rest for good. I'd have to say that this sort of high-minded platonic concept needs some revision. The notion that *some* software engineers *cannot* be found as responsible (in part or in whole) for *some* things that go wrong will be put to rest in *some* situations. There needs to be a degree of responsibility ascribed to some classes of systems development. Meanwhile, there is very obviously a line to be drawn between the programmer that programs their VCR clock to time a recording, the programmer that programmed the VCR as a consumer-grade product intended for purchase by unlicensed individuals, the TV network that broadcast the television show at the time the individual programmed their VCR to record 60 minutes of broadcast on a given channel, and the programmer who locked me out of the firmware on my smart phone.
- goalieca 9y ago> software engineers I've had the idea for a while that most of us practice software development rather than software engineering. I have a degree in computer engineering but i consider myself software developer now rather than a software engineer. The reason, I don't practice engineering in the legal and professional sense. In engineering school we learn about engineering as a formal process and professional responsibility. Both of these things are largely absent in most shops now. I get that not all projects need to be professionally engineered with all the costs and timelines associated with it. I think this is why agile came along. Sometimes it's just good enough to hack something together and demo it until a manager says it's time to release. But there are many other projects which are extremely important to society and should follow more traditional engineering practices. There shall be external and internal engineers who must formally approve any product before release. There shall be specific and testable formal requirements. There shall be a formal design and documentation for engineers to review and people to develop from. etc. etc.
- deleted 9y ago[deleted]
- terminado 9y agoThere's no legal framework, to distinguish devices that matter from devices that don't. There's no clear demarcation between devising a convenient contraption, versus implementing an inadvisable hack that leads to a hazardous outcome, especially within the scope of web based systems, since no portion of the internet is to be regarded as reliable life-saving infrastructure. I think the mistake is to trust packet-switched networks and peer-oriented protocols as reliable systems at all. If you cannot control the whole system, end-to-end, and any unwitting peer can over-consume bandwidth (jamming traffic and communication with interference), effectively cutting you off from a necessity, why would you bet your life on the availability of that system?
- transpute 9y agoWork is underway to support Time-Sensitive Networking in modern operating systems: https://schd.ws/hosted_files/elciotna18/b6/ELC-2018-USA-TSNonLinux.pdf https://schd.ws/hosted_files/elciotna18/b6/ELC-2018-USA-TSNo...
- transpute 9y agoAn effort was started by Mudge to use static analysis and fuzzing to assess a range of software, https://34c3.cyber-itl.org https://34c3.cyber-itl.org & https://theintercept.com/2016/07/29/a-famed-hacker-is-grading-thousands-of-programs-and-may-revolutionize-software-in-the-process/ https://theintercept.com/2016/07/29/a-famed-hacker-is-gradin... "... first-of-its-kind method for testing and scoring the security of software — a method inspired partly by Underwriters Laboratories, that century-old entity responsible for the familiar circled UL seal that tells you your toaster and hair dryer have been tested for safety and won’t burst into flames. Called the Cyber Independent Testing Lab, the Zatkos’ operation won’t tell you if your software is literally incendiary, but it will give you a way to comparison-shop browsers, applications, and antivirus products according to how hardened they are against attack. It may also push software makers to improve their code to avoid a low score and remain competitive."
- downer68 9y agoThis is a flawed concept from the outset. You either have appliances, or computational platforms. Turing-complete systems are arbitrarily flexible as a matter of principle. If the firmware can be altered; if any addressable memory can be changed, and a system relies on an internet connection for maintenance and support, it is an unreliable system.
- transpute 9y agoTheir site mentions relative assessments of different products, not absolute claims: "These sorts of questions can’t be answered in an automated fashion, due to theoretical obstructions ("undecidability") first identified by Alan Turing. Thus, to measure security in a practical fashion, we employ heuristics. We don’t need to find any specific vulnerabilities in order to assess how secure software is. Instead, we can observe the software’s safety features, build quality, complexity, and other heuristics. Some heuristics directly impact software security, while others might just be properties of software that are generally only found in cases where development teams know what they’re doing. As long as they correlate, it doesn’t matter."
- 9y ago
- Latteland 9y agoThat comment about admission to and completion of college leads to simplistic conclusions comes across as unfair. Pretty much every educated person went through such a sequence to get through college (others are educated without college, but they are tiny minority...). And plenty of us are able to understand the world has nuance. ON your latter point, I agree that there needs to be a degree of responsibility to some software dev, but it's a complex area and I can't really organize 'blame'. What's the blame I should get for writing a better webserver that some dicator uses to serve up his orders and have people killed? Compare that to the firmware of a phone programmer, and the person who teaches a robot how to determine if someone is killed by a weapon. It's too easy to look to that last person and say without thinking that they are the bad one.
- jancsika 9y ago> "The notion that software engineers are not responsible for things that go wrong will be put to rest for good, and we will have to work out how to develop and maintain code that will go on working dependably for decades in environments that change and evolve." That sounds like a really hard problem to solve. Not only would you need to have an audit trail for the history of changes to the code, you'd also have to figure out a way for third parties to audit the code and make sure they're looking at the same data that is being released by the project. Additionally, reacting to arbitrary changes in the environment probably requires more resources than even a multinational corporation can provide. So you'd need a way for third parties to be able to make their own changes to the software, somehow add them to the codebase without creating too much administrative overhead for the core team, and audit those changes in an automated fashion so that they don't create thousands of new exploits. And how would you even manage the sum total of all these Frankenstein versions of the original software with the changed versions? How would all these geographically disparate groups of programmers even communicate? We obviously need funding for a lot more CS professors to come up with solutions to these issues.
- ben_w 9y ago> That sounds like a really hard problem to solve. Yes, but we still have to solve it… or, at the very least, make a good effort to improve the situation. Biology and chemistry already have systems around them to help limit any damage from, for example, smallpox research or mishandling chlorine triflouride, and they manage this without needing everyone to wear safety goggles when mixing yeast and water.
- transpute 9y agoThe Anderson article mentions research into extended maintenance practices: "As we build more complex artifacts, which last longer and are more safety critical, the long-term maintenance cost may become the limiting factor. Two things follow. First, software sustainability will be a big research challenge for computer scientists. Second, it will also be a major business opportunity for firms who can cut the cost. On the technical side, at present it is hard to patch even five-year-old software. The toolchain usually will not compile on a modern platform, leaving options such as keeping the original development environment of computers and test rigs, but not connecting it to the Internet. Could we develop on virtual platforms that would support multiple versions?" ELC 2016: Approaches to Ultra-Long Software Maintenance: https://elinux.org/images/f/fb/Approaches_to_Ultra-Long_Software_Maintenance.pdf https://elinux.org/images/f/fb/Approaches_to_Ultra-Long_Soft... ELC 2017: Long-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years: https://www.linux.com/news/event/ELCE/2017/long-term-embedded-linux-maintenance-made-easier https://www.linux.com/news/event/ELCE/2017/long-term-embedde...
- spectrum1234 9y agoSure blame software engineers. I just do what my boss tells me to do. My boss is not a software engineer.
- deleted 9y ago[deleted]
- naner 9y agoWhy would it be the engineers and not business leadership? If BP has an oil spill do we blame their engineers?