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

21–30 of 386 posts

Re: The Insecurity Industry

#21

Post by nextos »

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 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 move relatively quickly and economically while retaining some rigor. Look into Liquid Haskell for some ideas that might become mainstream.

Re: The Insecurity Industry

#22

Post by tootie »

o8r3oFTZPE wrote: post #7

[accidental dupe. see above comment]

Who dismisses it? I think it's a pretty good idea. I think an enforceable law would have be more thoughtful than just paying for every breach. We need a reasonable standard for responsible security and how to assign blame.

Re: The Insecurity Industry

#23

Post by beezle »

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

Masterlock is still in business, right?

Re: The Insecurity Industry

#24

Post by imglorp »

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…

> fields where the companies are liable for bad stuff...

> * the companies and industries move very slowly

The reason the rest of us move so fast is we skip safety, security, quality, and maintainability to get to market. Those things are usually perceived "not bringing immediate customer value".

Re: The Insecurity Industry

#25

Post by user3939382 »

iamstupidsimple wrote: post #19
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…

> What we do in software is not real engineering, not even close. The only reason our processes and practices aren't much heavier is because the stakes are lower. People do not die if a Tweet doesn't make it through, but they do if a bridge collapses through. The threat model is also significantly different. If we go back to the bridge analogy, a company like Microsoft has to deal with tens of thousands of people try…

> People do not die if a Tweet doesn't make it through

True, and what you're saying is generally true. But what were the total consequences of the Equifax breach? We can't even quantify it. Snowden himself in the article mentions activists and journalists being killed because of these vulnerabilities. There are definitely counterexamples.

Re: The Insecurity Industry

#26

Post by tomc1985 »

bambax wrote: post #5

> it is still hard for many people to accept that something that feels good may not in fact be good This strikes me as surprising. I have always been taught the opposite: if it feels good, it's probably bad for you, or illegal, or immoral, or all three.

Protestant Western propaganda at its finest

Re: The Insecurity Industry

#27

Post by spoonjim »

I thought this was going to be about Instagram making money by making people, especially women, feel worse about themselves. Turns out there are multiple insecurity industries operating today...

Re: The Insecurity Industry

#28

Post by chevill »

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

>How many mistakes does someone have to make before we start to suspect there might be problems with relying on that person's work.

There's a lot of legitimate criticisms about modern OS security, whether we're talking about Linux/Android, MacOS/IOS, or Windows. However, we can't ignore the scope of these programs. Supposedly Windows 10 is approximately 50 million lines of code and due to its overwhelming popularity it has almost certainly been targeted more often than all of the other OS's listed combined. I am pretty sure all of these operating systems are > 10 million lines of code.

Whose work are you going to rely on instead? The level of security in these OS's isn't equal across the board, but I assure you zero days exist for all of them and barring some kind of miraculous technological breakthrough, they'll continue to pop-up from time to time as long as they exist.

Suppose someone pulled off a miracle by making a security-focused OS that's easy for non-technical people to install and use and actually gains enough traction to establish a market share. If such a thing existed it would likely get lots of things right where others have failed, but they would also likely get lots of things wrong. It doesn't mean we shouldn't try and it doesn't mean we shouldn't encourage both old and new companies to try and improve the situation, it just means that its an incredibly difficult and likely never-ending task. Security is a process, not an achievement.

Re: The Insecurity Industry

#29

Post by lu4p »

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.

True, but still memory safe, also Go has a race detector included which is really easy to use https://blog.golang.org/race-detector

Re: The Insecurity Industry

#30

Post by novok »

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.

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?
Post reply on HN