Live data from Hacker News

The Insecurity Industry

edwardsnowden.substack.com

31–40 of 386 posts

Re: The Insecurity Industry

#31
post #18

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

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 proposed reform is that it would make a great plot for a sci-fi novel.

Re: The Insecurity Industry

#32

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

> Even more, how many times do we hire someone knowing they have made 500+ mistakes in prior work leading up to their application.

While i don't disagree with the point you're making entirely, I have made many mistakes in my career and i still get hired and i suspect you have too. Most people make mistakes, and still have jobs.

Realistically, people/orgs make mistakes. Requirements change. Expectations change, security practices change, etc.

Roman bridge engineers would likely struggle to build bridges at the scale and requirements they're built to in 2021 (miles long, tall, huge train weights, etc). Things change in technology jobs a LOT faster than typical NSPE engineering licensees' jobs. Its a different world. There are probably bridges under contruction today that were designed before the iphone.

Re: The Insecurity Industry

#33

Edward Snowden is a traitor or a coward. Daniel Ellsberg gave the pentagon papers to the press after trying to give them to Congress. He then fought the govt in court and won. Ellsberg is a patriot.

No he's not, he even stated, that he is fine with coming back to the US if he is guaranteed a fair trail.

https://www.washingtonpost.com/news/the-switch/wp/2015/10/06...

Re: The Insecurity Industry

#34
post #30

Earlier quoted context omitted.

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?

RCE in that process maybe not, but security exploit absolutely. Things like that are how can be the difference between admin and non admin privileges or an “authenticated/not-authenticated” scenario.

Re: The Insecurity Industry

#35
I'm not going to comment on Snowden's view of what liberal western states do when it comes to surveillance. I have my own opinion, but he's been right about stuff I'd disagreed with him in the past before so I'm gun shy about confronting his ideas again.

On the topic of unsafe language though, he's absolutely right. We don't have to put up with this. We could pass a law and ban new code in unsafe languages from national security threatening devices like phones or cyberphysical devices like self-driving cars and we would be the better for it in under a decade. We could even have taxes to give breathing room during a transitionary period to encourage it before outright banning it, but we don't. We don't because so often it is less of a hassle for the government to trust the private sector that it is to take some real position on the regulatory issues that matter. This will probably always be the case until the government is able to evaluate talent and pay salaries in accordance with that talent as the private sector is.

Re: The Insecurity Industry

#36
post #14

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

My guess is the ‘users didnt know what they were doing defense.’ Not that you can deploy software in a secure by default stance. But once somebody sets up users and a million other settings inside Active Directory, it’s pretty much bound to be insecure. And then the defense is akin to ‘you werent supposed to crash the car into the tree’.

I guess they blamed "the army that didn't know what it was doing" for using that bridge wrong too. So it's not _just_ software "engineers"...

Re: The Insecurity Industry

#37

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

We tried this with general aviation. Private plane manufacturers all went bankrupt, and now the minimum price for a new airplane is in the hundreds of thousands of dollars.

Apply strict liability to software, and you'll see the same results. Every piece of software will have to be constructed with the care of a medical device. Expect most forms of technological progress to come to a halt. Some part of the HN crowd will post "I want that" from their iphone (which wouldn't exist under such a regulatory scheme).

Re: The Insecurity Industry

#38
post #30

Earlier quoted context omitted.

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?

Corrupt data may break invariants, which widen the attack surface.

Re: The Insecurity Industry

#39
post #28

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

Does it need to be 50 million lines of code? When you design with security in mind you might have to prune old code and drop some risky optimizations, probably drop some features. Using a higher-level language might help reduce the line count as well at the cost of performance and memory consumption.

Re: The Insecurity Industry

#40
I tend to bang on about software not as engineering but as literacy. It makes some sense even here - that bad code is as common as bad law - and often for the same reasons, politics, money, and hard questions

"Engineering" is a wide subject - the big stuff is carefully built and highly regulated - bridges and buildings. But as we go down the scale we see engineering give way to the problems of politics and money - tower blocks collapse for example, and then we see human level engineering - factory tools that try to meet inflicting goals, dangerous toys and so much more.

The software world should not beat itself up for not being like all those engineers - when lives are not on the line engineers get tied up just the same as the rest. And when lives are on the line, software and hardware engineering have learnt a few things - reduce the scope to the barest possible essentials - have a lot of redundancy and stick to well known designs.

Post reply on HN