Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Insecurity Industry

edwardsnowden.substack.com

Post reply on HN
Print view View original

61–70 of 386 posts

Re: The Insecurity Industry

#61

Post by Nicksil »

renewiltord wrote: post #60
c-cube wrote: post #59

Earlier quoted context omitted.

Maybe it's because real engineering has higher stakes than a crud app. Condos can kill, bridges can kill, Javascript forms or video game engines generally can't. If they could we'd witness a lot more deaths, despite your confidence.

I have a personal philosophy: "if you can't do it well, don't do it at all". That's because I prize my ability at what I do. I am good at it. I am a craftsman. Not like these fly-by-night characters busy dropping concrete on people's heads. Maybe I need to teach these "real engineers" something about building things haha: "If you can't do it without killing people, don't do it". Man, that's a motto for the ages. You'…

>I have a personal philosophy: "if you can't do it well, don't do it at all". That's because I prize my ability at what I do. I am good at it. Maybe I need to teach these "real engineers" something about building things haha: "If you can't do it without killing people, don't do it". Man, that's a motto for the ages. You'd think you don't have to teach people that, but here we are.

You're trying too hard. It's embarrassing.

Re: The Insecurity Industry

#62

Post by azakai »

zozbot234 wrote: post #17
_wldu wrote: post #15

Nice to see that he linked to rust as a safe alternative to the C's (C, C++, Objective-C). There is a place for Go and Java as well above the system level. Both perform well and are safe.

Go is not safe for concurrent code, unfortunately. Specifically, it does not protect against data races on non-atomic types, which can lead to torn writes and break invariants that are required for safety.

You're right that Go has those flaws, and it would be nicer if they didn't exist. However, in practice Go is still far, far safer than C and C++. Use after free etc. are far easier to exploit than Go's races.

If you can write in 100% safe Rust, Swift, C#, Java, etc. - and not use any of the unsafe escape hatches they provide at all - that would be best. But using some small amount of unsafety in any of those languages, or using Go, would still be a huge improvement over the typical C or C++ codebase.

Re: The Insecurity Industry

#63

Post by kreelman »

nextos wrote: post #21
dmoy wrote: post #18

Earlier quoted context omitted.

Most of the people I went to Uni with ended up in fields where the companies are liable for bad stuff, to a certain degree. It does exist. However: * you get paid a lot less * the companies and industries move very slowly * you spend a lot more time writing long-form, some time just re-using existing stuff wholesale, and almost no time building actually new things I mean like Real Engineering fields. What we do in so…

I completed a MSc in Formal Methods a decade ago, and I've worked in software projects where the level of rigor was equivalent or superior to any classical engineering field. For example, railway signaling or some real time control systems. We handed in complex artifacts that have had zero defects throughout their lifetime (> 15 years). I believe lightweight formal methods are quite promising and might let software m…

Liquid Haskell looks similar to Eiffel in terms of contracts.

I imagine a whole bunch of power could be derived from this in Haskell. I don't know how heavily contracts were/are used in Eiffel (I don't think it's so popular these days).

It would be great to know if contracts had a measurably useful outcome on projects and what that measurable was (addressed a market that we otherwise wouldn't have been able to, dropped runtime errors to only system based errors, etc).

WRT your projects, I imagine it would be great to see your product out there working with a known level of uptime and quality. I could imagine it's a bit of a shift from the normal "throw it together" of ... a lot of software.

I'd be curious to know what it's like to work on day to day, year to year. I imagine lots of software will still be "throw it together" for a long time yet, but even if the subsystems are formally verified, it could have a useful impact on the software that consumes these (verified) modules.

Re: The Insecurity Industry

#64

Post by api »

o8r3oFTZPE wrote: post #11

"For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product." That sort of discussion is quickly dismissed on HN. And probably elsewhere on the web/over the internet. Instead we frequently see discussion blaming users of the software, i.e., Microsoft's customers, or even suggestions to make the customer liable, or comments from "…

Put liability on software and you will halt innovation almost completely. It won't lead to a utopia of provably safe systems and secure languages, but to a dystopia of paranoid risk-averse companies refusing to allow any form of innovation or use any code that is not already in use. Instead of clean bug-free code we'll end up with code that looks like OpenSSL, ugly as hell but relatively bug-free after decades of brute force fixing.

Re: The Insecurity Industry

#65

Post by csande17 »

zarzavat wrote: post #31
dmoy wrote: post #18

Earlier quoted context omitted.

Most of the people I went to Uni with ended up in fields where the companies are liable for bad stuff, to a certain degree. It does exist. However: * you get paid a lot less * the companies and industries move very slowly * you spend a lot more time writing long-form, some time just re-using existing stuff wholesale, and almost no time building actually new things I mean like Real Engineering fields. What we do in so…

Actually it's simpler. People and organizations would just move to a jurisdiction where such liability laws didn't exist. Apple would move. Microsoft would move. Google would move. And then the US would be forced to decide whether to accept imports of foreign devices and software (created under the no-liability framework) or to stay with homegrown technology frozen in time. The best thing you can say about this propo…

Tech companies can't even manage to leave San Francisco's outrageous cost of living and rising crime, much less the United States.

Re: The Insecurity Industry

#66

Post by staunch »

yellow_lead wrote: post #49
novok wrote: post #30

Earlier quoted context omitted.

Can you do a security exploit with a concurrency bug although in golang? You may corrupt data, but can you cause remote code execution with it?

Yes, not all RCEs are caused by memory bugs.

Can you point to some examples of RCEs caused by Go concurrency bugs?

Re: The Insecurity Industry

#67

Post by nextos »

kreelman wrote: post #63
nextos wrote: post #21

Earlier quoted context omitted.

I completed a MSc in Formal Methods a decade ago, and I've worked in software projects where the level of rigor was equivalent or superior to any classical engineering field. For example, railway signaling or some real time control systems. We handed in complex artifacts that have had zero defects throughout their lifetime (> 15 years). I believe lightweight formal methods are quite promising and might let software m…

Liquid Haskell looks similar to Eiffel in terms of contracts. I imagine a whole bunch of power could be derived from this in Haskell. I don't know how heavily contracts were/are used in Eiffel (I don't think it's so popular these days). It would be great to know if contracts had a measurably useful outcome on projects and what that measurable was (addressed a market that we otherwise wouldn't have been able to, dropp…

Liquid Haskell is a bit different from Eiffel. On Eiffel, contracts were designed to be verified at runtime. There were some efforts to verify them at compile time, like Liquid Haskell does, but that's hard unless the whole language and type system are designed for that from the ground up.

As for my day to day job, I think the real difference with common software development was that requirements were very well understood right from the beginning. This allowed us to formalize them into axioms and then derive the implementation in a stepwise fashion using some Standard ML tooling.

I've also worked on proving theorems on existing software artifacts, but that's way harder both in terms of effort and number of defects.

Re: The Insecurity Industry

#68

Post by zizee »

o8r3oFTZPE wrote: post #11

"For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product." That sort of discussion is quickly dismissed on HN. And probably elsewhere on the web/over the internet. Instead we frequently see discussion blaming users of the software, i.e., Microsoft's customers, or even suggestions to make the customer liable, or comments from "…

Microsoft and friends would love this, as it would result in such a huge barrier to entry that only those who could pay large amounts for insurance woyld be able to enter the market, with insurance built into the price of the software.

Say goodbye to open source software!

Re: The Insecurity Industry

#69

Post by zucker42 »

dmoy wrote: post #18
o8r3oFTZPE wrote: post #11

"For example, if you want to see Microsoft have a heart attack, talk about the idea of defining legal liability for bad code in a commercial product." That sort of discussion is quickly dismissed on HN. And probably elsewhere on the web/over the internet. Instead we frequently see discussion blaming users of the software, i.e., Microsoft's customers, or even suggestions to make the customer liable, or comments from "…

Most of the people I went to Uni with ended up in fields where the companies are liable for bad stuff, to a certain degree. It does exist. However: * you get paid a lot less * the companies and industries move very slowly * you spend a lot more time writing long-form, some time just re-using existing stuff wholesale, and almost no time building actually new things I mean like Real Engineering fields. What we do in so…

I don't completely disagree but

> you get paid a lot less

Isn't that the point? That is, the argument is right now the money goes to the devs, management, and stockholders, when it rightfully should go to those people damaged by the software (or toward preventing them from being damaged).

> the companies and industries move very slowly

How much of this is due to liability law and how much is due to natural aspects of the relevant technology? Liability law may be part of the reason, but software probably naturally moves faster than other engineering fields.

Re: The Insecurity Industry

#70

Post by strangeattractr »

renewiltord wrote: post #60
c-cube wrote: post #59

Earlier quoted context omitted.

Maybe it's because real engineering has higher stakes than a crud app. Condos can kill, bridges can kill, Javascript forms or video game engines generally can't. If they could we'd witness a lot more deaths, despite your confidence.

I have a personal philosophy: "if you can't do it well, don't do it at all". That's because I prize my ability at what I do. I am good at it. I am a craftsman. Not like these fly-by-night characters busy dropping concrete on people's heads. Maybe I need to teach these "real engineers" something about building things haha: "If you can't do it without killing people, don't do it". Man, that's a motto for the ages. You'…

Why bother with the software engineering, your moral sensibilities are needed everywhere. It's not every day someone emerges capable of writing a todo app in react without killing anyone
Post reply on HN