or even "My code is correct, so I don't need to test."
or even "My code is correct, so I don't need to test."
35 years in industry, most of that in "millitary/aerospace" where the consequences are large and often fatal.
Perhaps more importantly, my father, a Structural Engineer with a PE license, and I discussed professional liability many times. He was involved in some court cases as an expert witness when a building fell down. (He said there was blame to go around. Bad design by the architect, incorrect/incomplete specification of materials by the architect and engineer, and the materials that were used failed to meet their own documented capabilities.)
So yes, I think this is not just doable, but also needs to be mandatory, in commercial environments, particularly where the costs of failure are significant (financial and/or human/property damage.) The disclaimer of any warranty, including that the software does what you pay for it, should be made totally illegal.
The core question for the engineering community is whether they get in front of this problem, or they wait for enough catastrophes that the lawyers, courts and particularly the legislatures decide to solve it for us.
Well first, the techniques for high confidence software (such as safety-critical) show that -substantial- improvements in software reliability are possible. For commercial avionics, the verification costs are much more (maybe even an order of magnitude) than the development costs. The ROI for verification (such as MCDC) has been questioned (whether the additional surety gained is worth the cost to get it.)
What's most important is the culture of assurance, i.e. 'think before you write', at least anecdotally doing code annotations without associated verification/proof gets you most of the benefits for relatively low costs. (The one thing I liked about Extreme Programming was its emphasis on pair coding and reviews.)
With respect to AI, I think what would work is an axiomatic approach that specifies Must Do/Must Not Do, and verification against those axioms. That's not the same level of verification as line-by-line/instruction-by-instruction avionics code, but it's a heluva lot more than we get now.
Structural engineers (my father was one) don't have a union and they don't get their degrees from trade schools.
The do have a professional society that is fully engaged in licensing, educational standards for engineering curriculum, and a career path that leads to the necessary experience to qualify for a license, along with testing. They also collaborate with the state Engineering licensing agencies.
On the other hand in computing, at least some of the professional societies have actively argued against licensing. I remember one debate that went something like, "Beauticians are required to have licenses. Should we be like beauticians?" To which the response was, "Doctors have licenses. Should we be like doctors?"
Actually, I have developed software applying DO-178B (although not to Level B/A) for air traffic control, and to Mil-Std 882D for a project that included networked fires and autonomous potentially armed vehicles. On the latter project, I was the lead software safety person for a while.
And to the follow-on comment: Yeah, there's a lot of work to get the hazards and the requirements down to the level that verification against those has real impact. That's part of the job.
and I've been calling for professional licensing and liability for software engineers for at least 30 years. That should follow the approach for other Professional Engineers, including the use of 'engineering practices' as a defense.
The software community has done an appallingly shitty job with software reliability. (Exhibit 1: CERT database of software vulnerabilities.) It's way past time they get held accountable. And yeah, this will slow things down and require people do things right the first time, and it will put a serious dent in the management approach to "throw the cheapest bodies at the software problem, and damn the bugs!" Product liability needs to include both corporate and individual liability.
Email outsourcing companies don't seem to place much value on following rules like SPF and DMARC. A lot of the false positives we get in quarantine are from senders using email outsourcing or "relationship management" companies. After all, the company gets paid by their customer for sending the mail, and has no real accountability whether the customer's email is properly formatted and delivered.
And with large institutions (particularly universities) moving to outsource email and other IT services, this problem will get worse.
(By the way, the same concept applies to phone spam: reliable/unforgeable Caller ID would probably shut most of that down. Of course, that would require the Telephone Companies to make changes. Caller ID should either be 'guaranteed' or the incoming call marked as "no Caller ID" when the caller's phone number can't be verified.)
Well, some research shows you have to download some code, install it on your machine as an RPC server, and then use the command line to get to "LBRY://"
Does this strike anyone else as fraught with IA concerns?
I'm all in favor for open repositories for Creative Commons and Public Domain content, but not if I have to breach my own machine to get to it!
Huh? Not recognized by my browser.
That's not my experience, over the last 15 years where I was required to exchange PKI encrypted emails with both DoD users and other contractors (Fortune 50 company through 1 person security consulting shop). I've had problems setting up/loading certificates, particularly handling root and intermediate certificates (from DoD PKI). When a certificate expires, Mail has real problems with the email. And recently I was sent a short encrypted message where it took order a couple of minutes to decrypt and display.
Those problems, I believe are a combination of flaws in Mail.app, in the underlying Mac OS X PKI support, and with PKI in general. I had similar problems with Thunderbird, which depended on little or no Mac PKI infrastructure.
Hence my posting elsewhere in this thread that it's the underlying PKI infrastructure at the OS level that is at least partly at fault, and I think the complexity of the PKI design explains much of the reason why PKI infrastructure is so messy. What looked good on paper didn't scale and had real usability problems even for relatively sophisticated users. It's certainly not ready for the casual user!
Finding, installing, handling revocations/expiration. Loading parent/certificate chains, -particularly when the certificate chains themselves (root and intermediate) change-. In a perfect world, this would all be handled automagically. But when something goes wrong, figuring out what happened, and then trying to fix it, has been At Least One Bridge Too Far.
I've had to mess with PKI encrypted email (as a job requirement) many times over the last 15 years. In my experience, the problem is the underlying PKI support. It's really hard to load & manage certificates, deal with revoked certificates (including preserving emails when a certificate expires), etc. Some of that is, I believe, due to the complexity of PKI itself, and some of it is due to poor (at least from a user experience perspective) support by the OS vendors. Much of my experience is with DoD PKI, including their huge chains of PKI certificate/trust.
If the PKI infrastructure worked well, encrypting/decrypting email should be easy. But if the PKI infrastructure makes it really hard to manage certificates, there's nt a lot the mail user agent can do about that!
Agree! And in particular, do the test cases cover both all expected functionality and error situations, particularly bad (user) input?
(someone please mod parent up).
I didn't assert 'No one develops websites on the Mac', all the websites hosted on my servers are developed on the Mac.
But the number of people who do this is Much Less Than the total Mac user population.
Furthermore, few people who develop websites on any platform get their tech advice from Consumer Reports.
But then, when you can't produce a useful thought, insults work just fine.
How many Mac users develop web sites?
If you can't get your work done in the first 24 hours, work nights.