Ransomware hot takes fresh out da' oven.
The ransomware gangs attack with little care for the societal impact of their actions, or perhaps more sinisterly, precisely because of them.
We must target the delivery mechanism, not just stop the execution of the payload.
@thegibson I think it would help if:
- there was actual liability for commercial software and hardware providers; I don't fscking care why the bugs are there, it's your product, you're accountable.
- annual NSA/CIA dark cyber budget of ~50bln USD was redirected to US-CERT instead (and similar moves were made in EU/UK), which currently gets ~100mln annually.
- those agencies were otherwise required to report and help fix vulnerabilities they found, instead of hoarding them.
@thegibson "all software has bugs" is the "boys will be boys" of the tech sector.
It pretends to explain and justify the state of affairs.
IT is infrastructure. Somehow we can have bridges that don't crumble when a teenager sneezes on them funny. We should be able to have IT infrastructure just as stable. It's not rocket surgery, it's just lack of incentive.
@rysiek @thegibson there is differences between bridges and programs. the function of a bridge is well defined, and the laws of physics don’t change over time. our understanding of them may change, construction techniques may improve; but the final “test” is immutable .
but the function of a computer program is usually poorly defined vague waffling from a middle manager, if there is an equivalent “laws of computing” they’re poorly understood, and programming techniques go in fashion cycles.
@zens @thegibson seems like the problem is not defining the function well enough. If you're saying we need to fix this and make sure software functions are well-defined when used for critical infrastructure, I am there with you.
If you are using it as an "argument" to make it seem fixing IT is impossible, you're making the problem harder to fix.
@rysiek @thegibson what I am saying is, yes, we certainly can do better. but not by having faith in the religion that all problems can be well defined, without a y evidence that they actually can, and piles of evidence they can’t.
@zens @thegibson how about we actually start putting "engineering" in "software engineering"?
One wonders what would happen if some Microzon Facegoople drone was as responsible for their product not failing catastrophically as construction crews are for bridges not falling. I am talking hard jail time.
Would that incentivise them to find good ways of defining the scope of the project better?
One wonders...
@rysiek @zens @TheGibson fun fact: the National Council of Examiners for Engineering and Surveying, who administer the Professional Engineer exams for other disciplines, used to have a Software Engineer exam, which could have been the foundation of a proper licensed engineer cadre in the United States.
It was discontinued due to lack of use.
We should abandon the designation Software Engineering and stick to programming or development, until the industry writes software to meet national safety and reliability standards that are enforced by a system of inspections of plans, the process and final code.
That's why engineering is so reliable - software development hasn't advanced to the level of engineering yet.
@rochelimit Did you read about Hillel Wayne's Crossover Project? I used to hold the same opinion as you do, but after reading about the project, I'm not so confident anymore. https://functional.cafe/@minoru/105602220101068544
@minoru @rochelimit @khm @rysiek @thegibson i think the question of whether software devs are “engineers” really comes down to certifications, oaths, and agreements. I found out the other day that most doctors don’t take a hippocratic oath! but for lawyers, and doctors there’s a bar, specifically so they can be disbarred. engineers have a ring
https://en.m.wikipedia.org/wiki/Engineer%27s_Ring
software devs don’t have this, and it’s kind of urgent that we do like this to self regulate, orherwise governments will.
@minoru @rochelimit @khm @rysiek @thegibson but i will sound like a broken record again and reiterate my original point: only a tiny minority of software dev resembles engineering, e.g. control systems, network comms, kernel development. the rest is the extremely political act of turning all human life into formal logical statements, to decide things like whether someone “deserves” to get a welfare check
@zens Yeah, licensing is the most common counter-argument to claims that software engineering exists. There is a good counter-counter-argument to it in the first post of the Crossover Project. Do read about the project; it's just two posts, and they're pretty insightful.
@minoru
I read the Crossover article - thanks for the pointer.
I still don't agree with the conclusion though, since the article discusses the process similarities between 'trad' engineering and software engineering without discussing the most common definitions.
Licences don't really exist in Europe, so it not a credential thing really for me, @zens @khm @rysiek @TheGibson - 1/2
although Engineering or Physical Science degrees seem universal.
No, I see engineering as the application of physics or maths principles in the design of solutions. Software engineering sits closer to social engineering in the use of the term. (engineering with a small 'e').
@zens @khm @rysiek @TheGibson @minoru - 2/2
@rochelimit But the whole project exists precisely because there are no definition of "engineering". The first post starts off stating: just like with porn, you know engineering when you see it. Or do you have some other definitions in mind?
College/uni degrees are indeed a bit of an indicator. I never heard of anyone landing a "trad" engineering job after a three-months-long bootcamp. Never even heard about the existence of such bootcamps.
I take it you don't buy Hillel's argument regarding discrete maths? And you disagree with his parallels to electricians vs. EEs?
(I dropped the topic starter from mentions to stop spamming them — they never replied here).
@rochelimit @minoru @zens @rysiek @TheGibson
Engineers are regulated in 84% of EU countries, generally under the EUR ING accreditation process. Almost all nations have a similar degree plus minimum years of practice requirement for certification, generally coordinated by FEANI. Of course each nation has its own governing body for accreditation.
@rochelimit @minoru @zens @rysiek @TheGibson It's precisely this form of self-regulation which is conspicuously absent from software engineering, which was my original point.
@khm The Crossover Project highlighted that software as a field is much more open: devs know not just what their colleagues are doing, but also what FAANG is doing, what startups are doing, what FOSS are doing. It could be argued that this level of awareness replaces regulations somewhat. I do realize these are not completely equivalent, though.
(I dropped the topic starter because they never responded in this thread).
@minoru @rochelimit @zens @rysiek Forgive me, but I don't think the development world is as open as people believe it to be. Goals and projects might be open, but the amount of irresponsibly-bad software in the world never seems to decrease -- especially in the embedded and mobile spaces.
In the end, if a bridge collapses and kills people, there is a custodial chain of responsibility for that. Visibility can enable accountability, but not replace it.
@khm @minoru @rochelimit @rysiek
to clarify my position, I don’t *actually* believe that accreditation can magically turn software inro engineering. I maintain that software is, ar its core, *not* engineering; though certain specific cases of software, instances where the problem is well defined and the outcomes measurable, can have engineering applied. (e.g, network programming, which has an element of real physics to it)
@khm @minoru @rochelimit @rysiek
rather, “engineering” is a giant red herring here, when what we really care about is safety and security. The core belief is that if some “good” software was better defined and regulated, and “bad” software made harder to sell and/or distribute, things like ransomware can be avoided. trying to claim this “goodness” is “engineering” and then defining what engineering is, is a distraction.
@khm @minoru @rochelimit @rysiek i’ll go further and double down on this by pointing out that things like ransomware normally have a component of “social engineering” to them. a stress matrix similation isn’t goong to get you anywhere with that. you need an ethnologist
@khm @minoru @rochelimit @rysiek also, imagine how far we could get by just stopping the widespread use of C and C++.
@zens @minoru @rochelimit @rysiek
This conflates the thing itself from the use of the thing.
If I build a wooden house, and the buyer tries to land a jet on it, that's not an engineering failure, but pilot error.
If I am hired to design an aircraft carrier, and I specify it to be buit from matchsticks, I have demonstrated incompetence and should be prohibited from practice.
The epistemology of engineering is irrelevant; programmers are simply unaccountable for their work output.
@khm @zens @minoru @rochelimit @rysiek i keep saying we have no material science in programming, and i will continue to say that until we get one.
the closest thing we have is @jepsen as a way to compare databases, and decide which one suits your needs
but we have nothing like that for programming languages, libraries or API
@meena @khm @zens @minoru @rochelimit oh, I was not aware of @jepsen, thanks!
And yes, I completely agree. Things like fuzzing, ChaosMonkey, and unit tests are kinda sorta steps in the right direction, but we're way at the beginning of that road.
LANGSEC ( http://langsec.org/ ) and reproducible builds movement are another important steps in the direction of IT infrastructure reliability. We need more of these.
@meena @khm @minoru @rochelimit actually, I really like what your "no material science in programming" take is doing to my brain.
I am hereby stealing this take, for it is a good take, and illustrates an important part of the problem. 😉
Seriously though, this hits one of the nails right on the head!
(dropped a person who is not interested in this conversation)
@rysiek @khm @minoru @rochelimit we can't tell which programming language is a match stick and which one is a brick
which API is a steel beam, which one is a dry wall?
we can't tell anything, because everything is just ✨ an opinion 🎉
and to a certain extent, when it comes to the ergonomics of programming, that may be true
but the amount of security issues unergonomic APIs (👀 OpenSSL) have q caused is truly mind boggling
@meena @khm @minoru @rochelimit totally agreed!
And it gets worse: sometimes even after we kind of sort of figure out that a particular technology stack is somewhat brick-shaped rather than match-shaped, a few years later that technology stack is dismantled or deprecated for some odd reason.
Python 2.x is an example here. It's not a perfect language, but it was reasonably good at being infrastructure when used correctly, and was reasonably well understood. So a lot of stuff was built in it.
@meena @khm @minoru @rochelimit which means we also need to figure out very-long-term funding and support for infrastructure-critical projects.
Oblig. #XKCD:
https://xkcd.com/2347/
To give a painfully concrete example of the above:
https://roy.marples.name/archives/dhcpcd-discuss/0003457.html
@zens @khm @minoru @rochelimit look, you can call it "flabgraffity" if you like for all I care as long as our digital infrastructure stops constantly falling on its head.
But then:
1. it is clear we have not achieved "software flabgraffity" yet
2. we need to figure out how to achieve "software flabgraffity"
And I am pretty sure once we start sketching out what "software flabgraffity" looks like and how to achieve it, it will start looking suspiciously "engineering"-shaped.
@rysiek @khm @minoru @rochelimit i am going to say something that you might not want to hear:
perhaps it is not software, or any quality about it, flabgeaffity, engineering, or other, that is the most important factor in ransomware.
maybe people, and their incentives has a more important role.
@zens @khm @minoru @rochelimit well you are more than welcome to scroll through this thread and count how many times I used the word "incentives" in it myself. Go on, I'll wait.
In the meantime, most of what you said in this thread seems to be "it's impossible to make software safe"; perhaps that is true, but in that case, I hope you agree software should not come anywhere close infrastructure.
Would you agree with that?
@rysiek @khm @minoru @rochelimit
my position is more that, yes, software can be engineered, and can be made safe, but only a tiny miniscule subset of it. the subset that resembles a maths problem or an engineering problem. most software, to repeat myself, are codified political starements about the human world; self contradictory and brittle against the complexity of reality.
@rysiek @khm @minoru @rochelimit id i am not mistaken, from an engineering perpective, ransomware performs extremely well, is engineered well. if it were not, it eould be easy enpugh to just decrypt the ransomed data and move on. engineering on its own is amoral
@zens @khm @minoru @rochelimit well there's this pesky "engineering" word you're now using yourself. I thought you don't like that word used in the context of software?
What is "the subset of software that resembles an engineering problem"?
@rysiek @khm @minoru @rochelimit if you’re going to build strawmen I’m not interested in this conversation
@rochelimit @khm @rysiek @thegibson air traffic control, flight guidance systems, and medical equipment are supposed to meet these standards. it’s why I am so keen on sqlite; NASA requires certain qualities from it that the author is bound to.