Live data from Hacker News

The Insecurity Industry

edwardsnowden.substack.com

131–140 of 386 posts

Re: The Insecurity Industry

#131

I doubt "real" engineering is better. It's just that attacking its artifacts doesn't scale, so it looks more secure. In fact, the average bridge or skyscraper is probably absolutely riddled with serious design and manufacturing flaws

The design process is pretty rigorous. Anything to back up your idea?

Re: The Insecurity Industry

#132
post #130

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

C and C++ are really versatile, why are there no safe libraries for them (or are there?). If you want to make buffer overflows impossible then add a library that does so and use it. If you want safer memory handling use a library. Or extend C and C++ with standard libraries that are safer to use. Java is implemented in C so anything Java can do, C can do. Many languages are actually implemented in C. What is this fas…

Because safety requires that the language prevent you from doing things and libraries don't have much ability to do that.

Example: C++ shared_ptr gives you reference counting which helps prevent use-after-free errors. However, shared_ptr can't stop you getting a raw pointer or reference to the underlying object, which can then be used to trigger a use-after-free bug.

Re: The Insecurity Industry

#133
post #130

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

C and C++ are really versatile, why are there no safe libraries for them (or are there?). If you want to make buffer overflows impossible then add a library that does so and use it. If you want safer memory handling use a library. Or extend C and C++ with standard libraries that are safer to use. Java is implemented in C so anything Java can do, C can do. Many languages are actually implemented in C. What is this fas…

Saying that Java is safe therefor you can write safe C is not actually sensible. The JVM is a virtual machine that runs user's programs, and those programs are in a memory safe language. That doesn't mean the JVM is memory safe... at all.

It's like saying "llvm is in C++, and llvm is used to compile Rust, therefor C++ is as safe as Rust". It's just not a tractable argument.

As for the rest of your post, sure, you can create a new revision of C/C++ that's memory safe - feel free to do so. It'll basically be a new language, but that's fine and has nothing to do with the parent's point, which is that we should incentivize memory safety - they didn't say it had to be a new language.

As for why people don't take that approach, it's because: it'll be a massive breaking change, so it's really no different from a completely new language. If you're going to create a completely new language you may as well take the time to fix a bunch of other issues while you're there.

edit: The above applies to libraries too. There are libraries that enforce stronger security in C++ (I want to say... IronC++? Something like that), and it basically ends up being, give or take, the cognitive overhead of a new language, but with the added bonus of no one actually using it.

> From a security perspective creating a new language reduces security because it will never have been as thoroughly vetted as the old languages.

This is unsubstantiated, and I highly doubt it is the case.

Re: The Insecurity Industry

#134
post #126
post #122

Earlier quoted context omitted.

Would you refuse to use Postgres, the Linux kernel or SQLite because they’re all written in C? Certainly C and C++ have more footguns than many other languages, but highly insecure as well as highly secure software gets written in all languages. I think coming up with better/easier avenues for digital-security-breach related lawsuits and fines is a better idea than banning specific languages.

Funny that you ask: Linux kernel rather actively embraces experimental code written in Rust. And yes, for a really critical system I might consider taking something much simpler and potentially slower but formally proven correct, like seL4. Google is working on Fuchsia as a new phone / chromebook OS, and it's very much focused on bulletproof security.

While Fuschsia's microkernel architecture has a lot of security benefits, the microkernel (Zircon) is still written in C++

Re: The Insecurity Industry

#137

Earlier quoted context omitted.

Other industries handle this kind of thing with a layer of indirection: instead of laws from the state, the state imbues a professional body with certification power, and the body sets standards by consensus or whatever other process among their members. So if you're an architect, or lawyer, or tradesperson, or whatever, you have to do things in the manner prescribed or you lose your license. I know this kind of thin…

Anytime gov't gets involved though, you have to consider how the lobbiest will get involved. So a proponent with deep pockets that is thouroghly entreched with a language about to be "banned" decides to hire a lobbiest to convince these "well educated in all things" gov't reps. Yet proponents of "safe" languages have no cash to spend. Which language is going to get banned then?

Yep, and what happens when the committee (perhaps correctly) chooses a proprietary language as the safest language? Anyone making essential software would end up writing code like this: https://i.imgur.com/8S6JbDS.png (labview; Haven't used it in 10 years, but I'm pretty sure it is 100% memory safe)

Don't worry, the pricing will be FRAND (fair, reasonable, and non-discriminatory). You just won't be able to see the compiler and runtime sources or follow stack traces into stdlib code. For security reasons. Defense in depth, y'all.

Re: The Insecurity Industry

#138

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

As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes. Yes C/C++ have more footguns than Java but there's no "hard line" in the safety differences and there are real and important things that need doing that it's not always clear can be reasonably done in another language. If you haven't, I'd encou…

> As a professional software engineer I'm not sure the idea of "safe" or "unsafe" programming languages is a coherent idea, or if it is then all languages are unsafe in my eyes.

I agree, though that's not intractable. There's security compliance like ISO27001, which can't say "you're secure", but can say "you've got a threat model and you take measures to address it". It's then something you document and provide evidence for as part of your compliance obligations.

If we applied the same thing to a programming language I think it could be very clear to see the differences between languages.

That's not at all to say that I think ISO27001 is a good model for security, just that we already have systems that handle very nuanced ideas, so a formal definition, or proof, etc, is not really as necessary as it may seem.

Re: The Insecurity Industry

#139
post #108

I was all ready to post a reply... when I was hit by the darkest pattern of all... you must pay to do so, with no hint prior to that moment.

Substack replies are paid? Hmm. Thinking about this right now: annoying sure but why do you consider this pattern dark? I bet it reduces spam and trolling by orders of magnitude unlike say confusing cookie dialogs designed to make you surrender all your private info.

The dark pattern is that you don’t know it beforehand, not the paywall itself.

Re: The Insecurity Industry

#140

I don't think you'd have to ban unsafe languages but you could pass a law that slowly decreased the amount of money the government could spend on 'unsafe' software (either through direct licensing or renting through clouds). The government is such a huge client to these companies that it'd immediately create a large financial incentive to migrate.

I think this is probably one of the better, more practical ideas that I've seen. If the government has to consider whether the underlying technology has adequately addressed memory safety issues (doesn't have to be at a language level, but that's obviously the easiest way), that puts pressure on them to fund projects that use memory safe approaches.

That's billions of dollars that will get slowly steered in the right direction.

Post reply on HN