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

261–270 of 386 posts

Re: The Insecurity Industry

#261

Post by michaelnik »

mehlmao wrote: post #90
stickfigure wrote: post #37

Earlier quoted context omitted.

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

Private plane manufacturers went bankrupt, but more importantly, plane crashes have become incredibly rare.

I don't know about "rare", since 1999 the broadest "accident" statistic fluctuates around 6 per 100,000h

Notice that "accident" definition conveniently excludes tons of partial failures! (see the legalese of 49 CFR § 830.2 - Definitions.)

To make parallel with broader discussion, the security failing of software could be considered "partial failures"...

Re: The Insecurity Industry

#263

Post by david_draco »

pjmlp wrote: post #188

"If you want to see change, you need to incentivize change. 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. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. Imagine how quick…

> talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected

https://www.gdpreu.org/compliance/fines-and-penalties/

Re: The Insecurity Industry

#264

Post by arkh »

pjmlp wrote: post #188

"If you want to see change, you need to incentivize change. 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. If you want to give Facebook nightmares, talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected. Imagine how quick…

> talk about the idea of making it legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected

That's kinda sorta one of the goals of the GDPR. And they go farther as they're liable for any leak of personal data, not just the unnecessary personal data.

Re: The Insecurity Industry

#265

Post by eru »

kragen wrote: post #237
eru wrote: post #236

Earlier quoted context omitted.

I am sympathetic to your argument, but be careful to avoid 'Post hoc ergo propter hoc'.

I think there's a clear line of causality here, though.

Hmm, I think so, too.

But it weakens your argument a bit. Basically, it would only convince people who are already convinced.

Re: The Insecurity Industry

#266

Post by nine_k »

Ieghaehia9 wrote: post #194
nine_k wrote: post #126

Earlier quoted context omitted.

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.

> And yes, for a really critical system I might consider taking something much simpler and potentially slower but formally proven correct, like seL4. One of seL4's points is that security can still be fast, no? From https://docs.sel4.systems/projects/sel4/frequently-asked-que... >To the best of our knowledge, seL4 is the world’s fastest microkernel on the supported processors, in terms of the usual ping-pong metric:…

Yes.

But within the Linux kernel, you might not need that cross-process IPC at all, so if you're into squeezing every last microsecond of latency, you likely want your entire app running as a monolith in kernel mode.

But if you want security more than top speed, seL4 + a few daemons you write for other OS needs must be fine.

Re: The Insecurity Industry

#267

Post by eru »

Ma8ee wrote: post #240
eru wrote: post #235

Earlier quoted context omitted.

Eh, contract law gives you all the tools you need to create liability. If you want software where the vendors are liable, you can get that today.

Oh yea, I’ll definitely win if I sue Microsoft, and being in the right will absolutely make a difference.

Well, then don't do business with Microsoft?

Only contract with companies that either have a reputation for upholding their end of the bargain without a court threatening them (ie most good companies), or only contract with companies where you have a reasonable expectation of being able to win a fair court case.

As an example of a more generalised version of the former: Amazon is pretty generous in their customer service, and you don't typically have to sue them to get them to eg give you a refund.

Reputation is a powerful asset, and companies often want to protect theirs.

(Not always, though. Amazon is less nice to sellers or employees, I think, for example.)

Re: The Insecurity Industry

#268

Post by aaronmdjones »

imdoor wrote: post #173

> Fixing the hardware, which is to say surgically removing the two or three tiny microphones hidden inside, is only the first step of an arduous process, and yet even after days of these DIY security improvements, my smartphone will remain the most dangerous item I possess. What's the purpose of these microphones? Do they pose more threat than the standard non-hidden microphone?

I believe he's referring to the various MEMS sensors (accelerometer, gyroscope, etc) which can be repurposed into microphones (much like harddrives).

Re: The Insecurity Industry

#269

Post by nine_k »

pjmlp wrote: post #193
conradev wrote: post #134

Earlier quoted context omitted.

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

For the time being yes. They are now starting to rewrite OS components in Rust, and I wouldn't be surprised if that happens to Zircon as well, it stared as a C anyway, and thus already suffered one rewrite.

s/suffered/enjoyed/

A rewrite usually improves a lot of small things that were found in the previous version. It's like a new major version, even if it does not add new major features.

It's an expensive undertaking, though.

Re: The Insecurity Industry

#270

Post by Kalium »

nine_k wrote: post #123
Hermitian909 wrote: post #112

Earlier quoted context omitted.

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…

Certainly there's no boundary that clearly delineates "safe" and "unsafe" languages. But certain languages (like C and C++, for instance) have built-in footguns. They were built in for various important reasons, but right now many of these reasons are not as pressing anymore. We can take something like Ada, Rust, OCaml instead, or at least use the extensive tooling that allows to statically check programs written in…

At the risk of being confrontational, show me a language without built-in footguns and we can talk. I've seen people fail to check their inputs in every language I've ever touched. I've seen people cobble together their own horrifically insecure SQL query builders. And so on.

Meanwhile, I have to argue with developers on a regular basis to convince them that they actually need to patch the libraries in their systems. Yes, even if they don't see an obvious exploit path. Yes, even if it's more work than drop-in-and-ship.

Getting them to use static analysis is a nightmare. Entirely too many developers view each finding as an attack on their style they can negotiate away.

As you so wisely and correctly say, we're at a point in time where we mostly have the tools to employ safer software development lifecycle methodologies. It is telling, then, how often we don't.

Post reply on HN