Why it's hard to trust software, but you mostly have to anyway
educatedguesswork.org
educatedguesswork.org
I love those classic tools from the likes of Sysinternals or Nirsoft. I didn't hesitate to give them full access to my machine, because I was confident they'd (mostly) work as expected. Although I couldn't inspect their source, I could reason about how they should behave, and the prevailing culture of the time was one where I knew the developers and myself shared a common set of expectations.
Their creators didn't tend to pull stunts like quietly vacuuming all your data up to themselves. When they did want feedback, they asked you for it first.
There wasn't such a potent "extract value" anti-culture, and successful companies recognized enduring value came from working in the user's best interest (eg. early Google resisted cluttering their search results).
Although silos existed (like proprietary data formats), there was at least an implicit acknowledgement and expectation you retained ownership and control over the data itself.
Distribution wasn't locked behind appstores. Heck, license enforcement in early Office and Windows was based on the honour system - talk about an ecosystem of trust.
One way to work toward a healthier zeitgeist is to advocate tirelessly for the user at every opportunity you get, and stand by your gut feeling of what is right - even when faced with opposing headwinds.
I’m actually looking back at the past, and realizing why app stores took over.
For the developers, it was indeed an ecosystem of trust.
For regular users, it was hell. The app stores, on a basic level, were absolutely in their best interest.
Why does the phone, even now, have more apps than desktop? I answer that it was because users could try software for the first time, and could afford to take risks, knowing with certainty it wouldn’t steal their bank account. Users were implicitly trained on the “free” platforms to trust no one, take no risks, that .exe (or .deb) could ruin your life.
For the average user, there has never been such an ecosystem of trust as there is now. That’s a sobering indictment about how a “free” or “open” platform can simultaneously be, for most people, user-hostile.
Or another example: We like owning our data, knowing that Docx is ours, as you also complain above.
But if you talk to many families; so many families have horror stories of digital losses. Lost photos, lost tax documents, lost memories. Apple charges $2.99/mo. and they’ll never lose it (or at least, the odds are lower than a self-inflicted disaster)? For them, the cloud has never felt so freeing.
If anyhing, *huge part* of that software cannot be replicated on your phone because the golden cage owner decided that you're not allowed to have it until they monetize it on you.
> If anyhing, huge part of that software cannot be replicated on your phone because the golden cage owner decided that you're not allowed to have it until they monetize it on you.
Objectively, most people have no desire for old software. Nobody wants a 10 year old video editor. Even retro video games, the most heavy market for retro software, is a drop in the bucket.
Terrible example. Many professionals, hobbyists and casuals do, actually. The only reason I still have a Mac is running ancient versions of CS and Premiere..
The only things Im really missing are codecs and, well, running it on a modern OS. Still prefer it over the cloud crap. I guess you think Im a “nobody“.
I'm not talking about old software (yet another weasel thing you dragged into the conversation). I'm talking about software that you're not allowed to have at all - software that automates your phone, software that processes your data, modifies how your phone looks or works, software that modifies other software on your phone (e.g. Outlook itself had a massive ecosystem of productivity plugins just byitself to serve the user).
The fact that those whole businesses existed and still exist for decades directly contracticts your "users don't want it" bull coming directly from corporate whiteknighting.
Actually now I wonder how many text editors have been made for PC, must be in the thousands.
Hello Mr. Jobs, back from the dead ? /s
"If everyone just" stood in front of the storm, they'd all get blown over, and the storm would go on.
No one wants to hear that individual heroics aren't the answer, but they aren't. Our moral intuition fails on problems bigger than it's meant for.
One person, out of hundreds, working in a factory that makes a slightly cheaper widget, that changes a BOM, that drives a different industry to swap one process for another, that forces other factories to move, that changes water use and heat flow in a region, that nudges weather systems out of a regime that favors storms, is doing more to stop the storm than any hundred people standing in the wind.
The person washing windows at a lab that figures out how any of those steps might be connected doesn't get to be a hero, and doesn't feel righteous for fighting, but they're fighting, while the people who choose feeling righteous aren't.
In the case of user-hostile software, what is an example of an action that would lead to a change in overall climate
Show a programmer a system that requires constant on-call burning out the team—they'll tell you (if they've been around) heroics are a sign it's broken, not to find more heroes. Definitely not to pull the person working on systemic issues off that nonsense and get them a shift.
Show them an equivalently structured broken system in a different field and they'll demand heroics.
I can't give you an example of an action, because I don't know, and I'm not talking about actions. I'm saying the approach itself is wrong and any action it suggests won't be effective.
Moralizing has a brutal, self-perpetuating metaproblem that makes people more and more convinced it works the more it doesn't. Actions based on moralizing will be chosen if suggested and they will not work, so any moralizing framing needs to be rejected right away, even if you can't suggest a better action.
I think such "immune response" of human society will be more realistic modeling of the storm blowing. The Leviathan won't listen to few of scales screaming data abuse is technically legal or whatever, if it deem that unreasonable.
"Developers" are themselves "users" and they, too, must trust other "developers".
I compile kernel and userland myself, sort of like "Linux from Scratch" but more personalised. I am not a "developer". I read through source code, I make decisions based on personal tastes, e.g., size, speed, language, static compilation, etc. Regardless, I still have to "trust". To be truthful, I read, write, edit and compile software not for "trust" reasons but for control reasons, as well as for educational purposes. I am not a fan of "binary packages" except as a bootstrap.
It seems that most self-proclaimed "developers" prefer binary packages. In many cases it appears the only software they compile is software they write themselves. These "developers" often muse about "trust", as in this submission, but at the same time they use other peoples' software as pre-compiled binaries. They trust someone else to read source code and alert them of problems.
Hell no. I don't think that "Developers" who made the new Windows (10, 11) GUI use it in any way. If they do, they must be very masochistic.
It is quite common for self-proclaimed "developers" to write software for other "developers". In other words, developers who are "users". We see this on HN everyday.
The stakes are now higher with data being so important and the advent of algorithms that affect people directly. From health insurance claims, to automated trading, social media drugs and ai companions, bad code today can and does ruin lives.
Software engineers, like every other engineer have to be held accountable for code they sign off and ship. Their livelihoods should be on the line.
No.
What you’re suggesting is about as plausible as the Aesop fable about mice saying they should put a bell on the cat. Sounds great, completely impossible.
So what about only new code then? In that case, does old code get grandfathered in? If so, Google gets to take tens of billions of lines with them for free, while startups face the audit burden which would be insurmountable to reach a similar scale. Heck, Google does not have enough skilled labor themselves to audit it all.
Also completely unfeasible.
And even if, even if, some country decided to audit all the code, and even if there was enough talent and labor in this world to get it done by the next decade, what does that mean?
It means all research, development, and investment just moves to China and other countries that don’t require it.
Also completely unfeasible.
> “Their livelihoods should be on the line.”
This fundamentally relies on the subject being so demonstrably knowable and predictable, that only someone guilty of negligence or malice could possibly make a mistake.
This absolutely does not apply to software development, and for the reasons above, probably never will. The moment such a requirement comes into existence, any software developer who isn’t suicidal abandons the field.
In computer code, every last line is possibly structural. It also only takes a single missing = in the 1.2 million line codebase to kill.
Comparing it to school engineering is an oversimplification. You should be comparing it to verifying the structural integrity of every skyscraper ever built; for each project.
Leaded paint, Aresenic, flammability, weight (steel walls vs sheet rock).
The complexity is still less than software though, and there are much better established standards of things that work together.
Even if a screw is slightly wrong, it can still work.
In software it's more like, every screw must have monocrystalline design, any grain boundary must be properly accounted for, and if not, that screw can take out an entire section of the building, possibly the whole thing, possibly the entire city.
When something like that does happen, it is very hard to know the measure of responsibility every entity holds. This will most certainly be decided in court.
There is a lot of literature on civil engineering failures. In fact, my civil engineering education was largely structured as a study of engineering failures. One of the most striking things about forensic analysis of civil engineering failures, a lesson the professors hammered on incessantly, is that they are almost always the result of really basic design flaws that every first-year civil engineering student can immediately recognize. There isn't some elaborate engineering discipline preventing failures in civil engineering. Exotic failures are exceedingly rare.
Never forget as well that it only takes a single cosmic ray to flip a bit. Even if you code perfectly, it can still fail, whether in this way or countless other black swans.
2.8 trillion lines of code aren’t going to rewrite themselves overnight. And as any software developer can tell you, a rewrite would almost certainly just make things worse.
Plus, the bulding codes are safety-focused and often don't cover things that most people would consider defects: for example a huge hole in the interior wall is OK (unless it breaks fire or energy efficiency codes)
Outside of those rare cases, everyone is demonstrably unwilling to pay the unavoidable costs of providing these guarantees. The idea that software can be built to a high-assurance standard by regulatory fiat and everyone just gets to freeload on this investment is delusional but that is what is often suggested. Also, open source software could not meet that standard in most cases.
Furthermore, those guarantees can only exist for the narrow set of hardware targets and environments that can actually be validated and verified. No mixing and matching random hardware, firmware, and OS versions. You'll essentially end up with the Apple ecosystem, but for everything.
The vast majority of people who insist they want highly robust software neither write software to these standards nor are willing to pay for software written to these standards. It is a combination of revealed preferences and hypocrisy.
In software, when people think it counts, they do too. The problem is not all people agree on “when it counts”
I don't suppose most doctors or civil engineers want to take liability either.
That's the problem, isn't it ? Nobody wants to assume liability. They all want just the profits.
Think about, if your car will come with a disclaimer like Microsoft's EULA.
In software, a single bit-flip or typo can lead to catastrophic failure, it is sensitive to defects in a way physical systems are not. The behavior of software is dependent on the behavior of the hardware it runs on; unlike physical engineering, the hardware for software is not engineered to the specifications of the design, it has to run on unknown hardware with unknown constraints and work correctly the first time.
Physical systems are inherently resilient in the presence of many small defects, a property that physical engineering relies on greatly. Software is much less tolerant of defects, and there is a limited ability to "over-engineer" software to add safety margin, which is done all the time in physical engineering but is qualitatively more expensive in software engineering. Being broken is often a binary state in software.
I've written software for high-assurance environments. Every detail of the implementation must be perfect to a degree that would make engineers with even the most perfectionist tendencies blush. Physical engineering requires nothing like this degree of perfectionism. In my experience, the vast majority of engineers are not cognitively equipped to engineer to that standard, and in physical engineering they don't have to.
Totally agree with what you wrote but in any well run engineering organization one has to consider the cost/benefit of extra testing and engineering.
If you're making a USB powered LED desk lamp, you get into diminishing returns fairly quickly. If you're making basically anything on JWST, less so.
In software systems, correctness is binary, so they actually have to be defect-free. Defects don't manifest gradually and gracefully like they often do in physical systems.
Every detail of the implementation must be perfect to a degree that would make engineers with even the most perfectionist tendencies blush
the amount of software that fits this description is likely comparable to amount of physical engineering that requires the same perfectionism…
AWS is using a lot of Formal Verification and Automated theorem proving on their core systems like S3 and TLS to increase reliability.
That can happen in physical engineering too, if it's not done right. Likewise, if a single bit flip can lead to catastrophic failure, that's an indication that the system was poorly engineered.
The problem with software is not so much that it is fundamentally different in terms of its failure response (though there certainly are differences -- the laws of physics provide important constraints on hardware that are absent in software) but rather that it is so easy to copy, which tends to entrench early design decisions and make them difficult to go back and change because the cost is too high (e.g. syntactically-significant tabs in 'make'). But even that can and does happen in physical design as well. The Millennium Tower in San Francisco is the best example I can think of. The World Trade Center is another example of a design that failed because the failure mode that destroyed it was not part of the original design requirements. When the WTC was designed, no one imagined that someone would fly a jet into them some day. Today's adversarial environment was similarly hard to imagine before the Internet.
It absolutely is possible to engineer software for robustness, reliability, and trustworthiness. The limiting factor is economics, not engineering.
That's why you have tests for this.
The main problem that i see with software, is that the testing and bug finding part are left to the user.
And, when testing is done, it is done as easy as possible. For example a function must return 5 when it has 8 as an input. They only test for 5 as an input value and 2 or -1 are left to the user to test them.
Not all software is equivalent and there is plenty of code that gets treated with the precision you're asking for.
But the ability to ship out code to billions in the blink of an eye is both the strength and the weakness of modern software.
It allows few engineers to tackle very complex problems without the huge investment in man hours that more rigor would require.
This keeps costs down enabling many projects that wouldn't see the light of day if the NRE was equivalent to HW.
On the other hand, you get a lot of "preliminary" code in the world, for lack of a better word.
At the end of the day all engineering is about balancing trade-offs and there are no right answers, only wrong ones. :)
Like Crowdstrike ? Or Microsoft ?
> The stakes are now higher with data being so important and the advent of algorithms that affect people directly. From health insurance claims, to automated trading, social media drugs and ai companions, bad code today can and does ruin lives.
See above and the UK Post scandal. Nobody gives a shit. There is no acountability for bad software. Software is not a product from a liability point of view.
> Software engineers, like every other engineer have to be held accountable for code they sign off and ship.
They managers more than them. Software engineers are not responsible for the software lifecycle. Somebody must test the code. Somebody must review the code.
Because, instead of "trusting" the update (or rather codebase) of a messenger, we now have to trust the complete browser bundle.
You may additionally ask why Electron, but that's a different question after all.
And all of that is completely out of your control and competence budget, unless you’re fine with shipping your first 50kb updates ten (metaphorical) years later.
Signal desktop doesn't use incremental updates. Each "update" is just reinstalling the whole package. That's what those 100 MB are.
It's possible to make incremental updates with binary patches, but it's more difficult. I guess Signal have other priorities.
The fastest way to money is to not dig too deep
Generally speaking, I agree, the npm-ecosystem still has this pervasive problem that pulling one package can result in many transitive dependencies, but a growing amount of well-known packages try to keep it as limited as possible. Looking at the transitive dependency graph is definitely good (necessary) hygiene when picking dependencies, and when done rigorously enough, there shouldn't be too many bad surprises, at least in my personal experience.
Or Tesla.
What really grinds my gears is updates that intentionally break things. Sometimes on purpose, sometimes out of incompetence, but most often out of not giving a single fuck about backwards compatibility or the surrounding ecosystem.
Every few years I lull myself into the false sense of security over running apt upgrade, until it finally destroys one of my installs yet again. Naturally only one previous package is ever stored, so a revert is impossible if you ever spent more than two releases not doing an upgrade. Asshole-ass design. Don't get me started on Windows updates (actual malware) or new python versions...
If you're going to be militant and absolutist about things, that seems like the best place to start
And then probably updating your software incredibly slowly at a rate that can actually be reviewed
Software churn is so incredibly high that my impression is that only some core encryption algo really get scrutinized
Bunnie's work is inspiring, but he is not alone.
As far as verifiable hardware goes, I would argue that Tillitis TKey is more open source than the Precursor. However, they are very different products, and Precursor is a lot more complex and capable. The only reason TKey is more open than Precursor is because TKey is able to use a completely open source FPGA flow, whereas Precursor cannot.
Of course, warranty still has the counter-party risk that they go out of business (probably because of all the lawsuits about a bad software ...).
IMO, Software, and what we expect it to do is too complex to offer something like warranty.
IBM offers literal written warranties on plenty of their software products. It’s just usually bundled with expensive hardware or consulting products too.
The corporate buyer paying millions didn't "fail to get a warranty". What happened is that the market equilibrium price for that transaction for that seller-and-buyer is one that does not come with a warranty. In other words, if the software seller doesn't provide a warranty AND still able to find willing buyers, then the market price becomes "software sold without a warranty".
Likewise, SpaceX sells rocket launches for companies that need to get their payloads up into orbit. SpaceX does not reimburse or provide insurance for the monetary value of the payload (satellite, etc) if it blows up.
Why would companies pay millions for launches if SpaceX won't cover damages to the payload (akin to FedEX/UPS insuring monetary value of packages) ?!? Because the competitors don't cover payload reimbursements either. If you really really want to get your satellite up into orbit, you have to eat the cost if the launch destroys your satellite. The market clearing price for launching satellites is a shared risk model between buyer and seller. Someday in the future when space missions become 99.99% reliable and routine, an aerospace company may be the first to offer payload insurance as a differentiating feature to attract customers. Until then, buyers get 3rd-party coverage or self-insure.
>If you're going to be forking over millions of dollars like get a real warranty that it's going to work or spend that millions doing it yourself
x = price of 3rd-party software without a warranty
y = price of developing in-house software (which your employee programmers also code without warranties)
if (x < y) : purchase(x)https://www.insurancebusinessmag.com/us/guides/satellite-ins...
Software is much more complicated, "brittle" to calculate risk associated with it. I may be biased but I think the real progress in the future of programming is not AI but formal methods. That's were long-term value is, and the even worse "brittleness" of AI will drive even more the point home in many domains (even if it is used to check and validate AI outputs).
A big problem is user hostile software (and products in general). I'm not able to walk into a Walmart and buy a TV or walk into a dealership and buy a new car, because there are no options that aren't user hostile.
Options exist, but I have to go out of my way to buy them.
* https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
But aside from that, yes, we still need to trust our software to a large degree especially on desktop operating systems. I would like to see more object capability systems start to show up so we can more effectively isolate software that we don't fully trust. (WebAssembly and WASI feel like they might be particularly interesting in that regard.)
An installed binary is much more verifiable and secure and trustworthy.
The real problem is the fact that software that can be used locally needs to connect the vendor's server in the first place. The other real problem is that by and large desktop software is not sufficiently sandboxed and does not have effective security policy (like SELinux) to restrict their permission.
mount -o remount,rw /usr
/usr (and root access in general) is such a distraction from the real issue though, which is that all the stuff I care about is accessible under my account. My browser data, photos, etc etc… if a malicious app isn’t sandboxed and is running as me, it’s game over. Stopping it from writing to /usr (or other places outside my homedir) is basically meaningless.
Today's most advanced projects are able to compile pretty much arbitrary rust code into provable RISC-V programs (using SNARKs).
Imo that solves a good chunk of the problem of proving to software users that what they get is what they asked for.
> … zero-knowledge succinct non-interactive argument of knowledge (zkSNARK), which is a type of zero-knowledge proof system with short proofs and fast verification times. [1]
[1] Microsoft Spartan: High-speed zkSNARKs without trusted setup https://github.com/microsoft/Spartan
Provable does not imply secure.
People figured this out 50 years ago but the rest of the world prefers to suffer I guess https://github.com/void4/notes/issues/41 https://en.wikipedia.org/wiki/E_(programming_language)
Imagine if we ran the electrical grid this way... with inspections, certifications, and all manner of paperwork. That world would be hell.
Instead we carefully capabilities at the source, with circuit breakers, fuses, and engineering of same so that the biggest circuit breakers trip last.
Capabilities based operating systems limit capabilities at the source, and never trust the application. CapROS, KeyKOS, and EROS have lead the way. I'm hopeful Hurd or Genode can be our daily driver in the future. Wouldn't it be awesome to be able to just use software without trusting it?
"image by chatgpt"
I'm just gonna assume the rest of this post is also AI-generated waffle. closes tab