[transpute]

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-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]

The 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]

> 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.

[terminado]

There'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]

Work is underway to support Time-Sensitive Networking in modern operating systems: https://schd.ws/hosted_files/elciotna18/b6/ELC-2018-USA-TSNo...

[transpute]

An effort was started by Mudge to use static analysis and fuzzing to assess a range of software, https://34c3.cyber-itl.org & 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]

This 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]

Their 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."

[downer68]

Sounds like stop-and-frisk TSA pat-down security theater. This is not the kind of concept that I'd ever expect to withstand a determined adversary.

Especially for machine learning scenarios, don't expect a show of force to prove as an adequate deterent. Posture and presumptive correctness aren't enough to protect you from entities ignorant of fear and indifferent to wastefulness.

[transpute]

Thanks for the astute observation.

It's not clear that their goal is deterrence. If they are transparent with heuristics for ranking vendors, it could provide fabled market-based incentives for a vendor race to the top, narrowing the security gap between "best" and "worst" vendors. If highly rated vendors advertise their achievement, buyers could factor the rating into purchase decisions. The heuristics would need to evolve as the floor of vendors' security practices is raised.

The bigger problem is what happens if the market-based approach fails? Will regulators step in for certain classes of software? Regulators are less likely to understand Turing-completeness.

[Latteland]

That 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]

> "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.

[transpute]

The 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_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-embedde...

[titzer]

Thanks for those links. Even with those recommendations, I think we honestly have no idea how to maintain software systems for 20+ years. Shame, because almost every other kind of industrial system we produced up until about 30 years ago _did_ in fact have the ability to be maintained for decades. Look at the B52 (https://en.wikipedia.org/wiki/Boeing_B-52_Stratofortress). Still going strong 60+ years after its first flight. Designed to last. Individual ones were built to last. Sure, it's seen upgrades over the years, but the core was just so well thought out and so _simple_.

We might never be able to build systems like that again. Simple is key, and we just can't help ourselves.

[detaro]

What mainframe systems do sounds pretty close the quote. They can still run decades-old software, even if the hardware platform underneath now looks completely different, since they can emulate everything from the old system, or have newer interpreters for the same old languages.

[ben_w]

> 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.

[naner]

Why would it be the engineers and not business leadership? If BP has an oil spill do we blame their engineers?

[spectrum1234]

Sure blame software engineers. I just do what my boss tells me to do. My boss is not a software engineer.