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

281–290 of 386 posts

Re: The Insecurity Industry

#281

Post by [deleted] »

Synaesthesia wrote: post #252
minusSeven wrote: post #245

Do people really think any of this is ever going to change? Governments don't give a shit, they time and again say they won't do something only to later do it in secret. We should at this point accept that this isn't going to change and move ahead with the belief that your data is already hacked and is not private anymore. We should discuss more on the exact consequences of this and take actions accordingly.

So not point in ever doing anything? Just give up. A mass movement of people can force a government to change.

[deleted]

Re: The Insecurity Industry

#282

Post by MichaelZuo »

ajb wrote: post #168
wly_cdgr wrote: post #102

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

If your building or structure is a public hazard, under existing legislation the government (at least in the UK) has the right to remove the hazard, up to and including demolishing your building , if you don't make it safe sufficiently fast. I'm not a lawyer, but I don't see any language in the law that would exclude unsafe automated systems which are part of a building or structure.

This is a key point. There’s no equivalent enforcement mechanism when it comes to software. It would be a very different world if one of thousands of local jurisdictions could at least theoretically issue a binding demolition order, within their boundaries of course.

Re: The Insecurity Industry

#283

Post by kragen »

justincormack wrote: post #276
kragen wrote: post #275

Earlier quoted context omitted.

> Whether the makers of my software are responsible is a contractual matter - and nearly all open source licenses include a disclaimer of warranty and a limitation of liability, including the GPLv3 (see sections 15–17). That was true in the US until MacPherson v. Buick in 01916 and in the UK until Donoghue v. Stevenson in 01932. Nearly all proprietary software licenses include the same disclaimer, but they are on sli…

Surely though without a contract there is no liability? IANAL but imposing liability on gifts seems difficult.

Without a contract there was no liability in the US until MacPherson v. Buick in 01916 and in the UK until Donoghue v. Stevenson in 01932, as I just explained in the comment you are replying to.

Re: The Insecurity Industry

#284

Post by danarmak »

justincormack wrote: post #276
kragen wrote: post #275

Earlier quoted context omitted.

> Whether the makers of my software are responsible is a contractual matter - and nearly all open source licenses include a disclaimer of warranty and a limitation of liability, including the GPLv3 (see sections 15–17). That was true in the US until MacPherson v. Buick in 01916 and in the UK until Donoghue v. Stevenson in 01932. Nearly all proprietary software licenses include the same disclaimer, but they are on sli…

Surely though without a contract there is no liability? IANAL but imposing liability on gifts seems difficult.

If I build an unsafe boiler, and gift it to you, and then it explodes and kills you - am I not liable because it was a gift and not a sale? Can I disclaim away any liability and "fitness for purpose" when I gift you the boiler?

ETA: the first couple of Google results say that no, product liability can't be disclaimed away - particularly when there is no contract or opportunity for bargaining. I am very much not a lawyer but this sounds correct to me (i.e. this is what the law is).

https://www.findlaw.com/injury/product-liability/are-product...

https://www.eltonlaw.com/does-a-disclaimer-mean-you-cannot-f...

Re: The Insecurity Industry

#285

Post by pluc »

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…

We've been incentivizing people to properly write "definitely" for decades and look where it's got us.

d-e-f-i-n-i-t-e-l-y.com

Re: The Insecurity Industry

#286

Post by matheusmoreira »

slickrick216 wrote: post #204
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…

Yeah imagine if we make pharmaceutical manufacturers accept liability for vaccine side effects. It’s the same argument right.

Side effects are expected. Vaccines provide enormous benefit but are not without risk. Patients must receive information about risks and choose whether to accept or reject treatments.

This is not at all comparable to corporations slurping up all data they can get their hands on for marketing purposes. Modern medicine provides enormous benefit for society. Surveillance capitalism... doesn't. Certainly not enough to justify the massive abuses being perpetrated.

Re: The Insecurity Industry

#287

Post by matsemann »

eru wrote: post #235
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…

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.

Ahh, yes, the free market. The bastion of privacy.

What about those not even doing business with Equifax and getting their info stolen?

Re: The Insecurity Industry

#288

Post by kragen »

eru wrote: post #265
kragen wrote: post #237

Earlier quoted context omitted.

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.

How would you make the argument?

Re: The Insecurity Industry

#289

Post by grncdr »

kragen wrote: post #222
grncdr wrote: post #203

Earlier quoted context omitted.

How would this make running a personal website risky from a legal liability perspective?

Are your HTTPD logs adequately secured? Are their security measures audited monthly, in keeping with established industry best practices? Do you have comments enabled on your blog? What's your policy for expunging blog posts about people exercising their right to erasure? How did this defamatory comment spam get past your comment filter? Did you know your open-source image thumbnailing software is being used on an il…

What a load of FUD. Personal websites don't need anything more complicated than an out-of-the-box config for apache or nginx to serve static files out of webroot. When's the last time that kind of setup was exploited?

Sure if you add more complexity, you add more attack vectors, but there's an easy way to reduce your legal culpability there: just don't collect any PII. Even in the scenario you propose where anonymous HTTPD logs are a liability (which... yeah, is not going to happen any time soon) the solution is simple: turn off logging. If the legal precedent is established, the defaults of our software will change to match.

Re: The Insecurity Industry

#290

Post by roca »

pjmlp wrote: post #200
roca wrote: post #125

Earlier quoted context omitted.

No, Go is not memory safe for concurrent code. Race detection is good but can't eliminate races altogether.

Same applies to Rust as well actually. Its type system only prevents data races for in-memory data structures, on the same OS process. There are plenty of other concurrency races.

It's true that there are "higher level" races that Rust can't prevent. But in-memory races are particularly important to prevent, because a) they're a common and very nasty kind of bug and b) it means unlike Go, Rust (the safe subset) is memory safe (and in general, free of undefined behaviour) for concurrent code.
Post reply on HN