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

311–320 of 386 posts

Re: The Insecurity Industry

#311

Post by slickrick216 »

matheusmoreira wrote: post #286
slickrick216 wrote: post #204

Earlier quoted context omitted.

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

I agree however allowing any company regardless of its business the opportunity to escape liability of consequences is dangerous. Pharma companies have in the past and will continue to have their scandals same as any other industry. There shouldn’t be exceptions. Who gets to define what industry is important or not and therefore avoids regulation is dangerous as it’s only as reliable as the “who’s” in control.

Re: The Insecurity Industry

#312

Post by ncmncm »

bob1029 wrote: post #306

> The greatest danger to national security has become the companies that claim to protect it No. The greatest danger is lack of software supply chain management followed by near-universal disrespect for formal complexity management methods. The only way I have found to win at this "are we actually secure" game is to minimize the number of parties you have to trust. The smaller you get this figure, the easier it becom…

There is no supply-chain accountability without liability.

When adding a dependency, knowing it exposes you to prosecution if it becomes a vector for security violation would give pause. A premium on attested-secure components might develop. If Facebook depended on Zst being secure to be able to stay in business, we might be more inclined to use Zst than e.g. unmaintained Zlib.

Re: The Insecurity Industry

#313

Post by minusSeven »

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.

Do people stop doing crimes because laws have made it illegal. I am saying there is no point trying to stop what is inevitable instead our energies are better spent trying to understand how best to navigate an online world without any privacy.

Right now many western nations are involved in Pegasuses, what happens when China gets involved. We will have absolutely no control over what China does, especially when no country will publicly acknowledge that we are spying on people.

Re: The Insecurity Industry

#314

Post by mikepurvis »

dylan604 wrote: post #117
mikepurvis wrote: post #110

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?

But the point of this is that it isn't the "government involved." As with other professional pursuits, the government says "we don't have the desire, expertise, or agility needed to make these decisions in-house, so we designate this organization to be our regulator of it."

For example, here's the Professional Engineers Act in Ontario: https://www.ontario.ca/laws/regulation/900941

None of it has anything to do with which tools or methods are used for the practice of engineering— it's all defining jurisdiction and constitutional meta-details about how the leadership is to be selected, term lengths, etc.

So no one can achieve regulatory capture about what kind of concrete is to be used in bridges in Ontario by lobbying the Ontario government; you'd have to lobby the PEO. Maybe your argument is that they're effectively equivalent, but they're really not— the PEO is a pretty different kind of organization from just another government office.

Re: The Insecurity Industry

#315

Post by dylan604 »

mikepurvis wrote: post #314
dylan604 wrote: post #117

Earlier quoted context omitted.

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?

But the point of this is that it isn't the "government involved." As with other professional pursuits, the government says "we don't have the desire, expertise, or agility needed to make these decisions in-house, so we designate this organization to be our regulator of it." For example, here's the Professional Engineers Act in Ontario: https://www.ontario.ca/laws/regulation/900941 None of it has anything to do with w…

>"we don't have the desire, expertise, or agility needed to make these decisions in-house, so we designate this organization to be our regulator of it."

Yes, because this has stopped them doing dumb things before. The gov't will still be in charge of selecting the people in the regulator. The lobbiest will still have influence. There's just no way around it.

Re: The Insecurity Industry

#316

Post by mikepurvis »

dylan604 wrote: post #315
mikepurvis wrote: post #314

Earlier quoted context omitted.

But the point of this is that it isn't the "government involved." As with other professional pursuits, the government says "we don't have the desire, expertise, or agility needed to make these decisions in-house, so we designate this organization to be our regulator of it." For example, here's the Professional Engineers Act in Ontario: https://www.ontario.ca/laws/regulation/900941 None of it has anything to do with w…

>"we don't have the desire, expertise, or agility needed to make these decisions in-house, so we designate this organization to be our regulator of it." Yes, because this has stopped them doing dumb things before. The gov't will still be in charge of selecting the people in the regulator. The lobbiest will still have influence. There's just no way around it.

Can you please supply examples from law, medicine, trades, engineering, etc where you feel that lobbying of the government has led to the kind of outcomes you're envisioning?

Re: The Insecurity Industry

#317

Post by yashap »

nine_k wrote: post #126
yashap wrote: 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.

As another commenter noted, there’s no Rust code currently in the Linux kernel. There may be some soon, but not much - it’ll be a dominantly C codebase for a very, very long time, maybe forever.

As for seL4, doesn’t that just support my point that highly secure software can be written in any language, even C? seL4 is primarily implemented in C. There “executable spec” is written in Haskell, but the actual kernel that people use is written primarily in C and a little Assembly.

Re: The Insecurity Industry

#318

Post by raxxorrax »

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…

I disagree with Snowden here. Liability is an extremely bad approach and would not solve the problem at all. It would also fortify companies that can pay for guarantees nobody could ever give.

That we have security flaws is always inevitable. Better languages might help but are no panacea.

I agree with Snowden on a lot, but this doesn't solve anything.

The result would be software certificates. By whom? Take a guess.

Nobody can guarantee absolute safety. This is a trap you don't want to fall into.

It would end open source and any independent development. Quite surprisingly short sighted by Snowden.

The problem with iMessage wouldn't be solved by liability. It is a security flaw that cannot be removed by law.

edit: To clarify: I agree with him in the Facebook example. They collected the data for their business and should be liable. "Bad" or "insecure" code is a different matter however.

Re: The Insecurity Industry

#319

Post by grncdr »

kragen wrote: post #294
grncdr wrote: post #289

Earlier quoted context omitted.

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…

Clearly you've never had to be responsible for PCI compliance. PCI auditors have no patience for arguments like "When's the last time that kind of setup was exploited? If you add more complexity, you add more attack vectors!" and just want you to install the damned antivirus software like their guidelines say. Yes, even though you're running Linux. No, they don't care that there's a CVE in ClamAV every two months. Th…

You're assuming quite a lot about me and not actually responding very directy to what I'm saying. However, reading this and some of your other responses makes it a bit more clear what the concern you're raising is.

> Listen, you know and I know that you can serve a personal website perfectly well with /var/www and a stock Apache config. But the proposal we're discussing here is precisely to take that judgment call away from people like you and me and give it to people like Donald Trump.

Let's revisit that proposal:

> 1. defining legal liability for bad code in a commercial product

> 2. making [website operators] legally liable for any and all leaks of our personal records that a jury can be persuaded were unnecessarily collected

I believe we both agree that neither of these technically apply to the personal website scenario (static hosting not collecting any PII).

So your argument as I understand it is: in order to make the above liabilities legally enforcable for scenarios where they do make sense, we will end up with regulations similar to those for handling "sensitive" data (such as financial/medical information) being imposed on _all_ software / online services (such as basic static websites). This will happen because laws will be written in an environment of near-total regulatory capture.

This argument is plausible, but it relies on a bit of a non-sequitur: expanding the scope of data collection/handling regulations will inevitably extend to regulating the publishing of software.

It might be in the interest of the current software behemoths to push for such a system, but I don't really see it. They derive too much economic value from the current "free as in lunch" open-source to shoot themselves in the feet like that. It seems more likely they would:

1. try and narrow the scope of their own liability (by heavily constraining which categories of software carry that burden) 2. try to minimize the costs to themselves (by demanding compensation from governments for the work required to meet those regulations) 3. try to offload liability to vendors (who can then demand compensation for taking on that liability).

Points 2 and 3 could be a large cash cow for free and open source software, though I doubt many will be able to successfully capitalize on it.

Re: The Insecurity Industry

#320

Post by raxxorrax »

parksy wrote: post #209
kragen wrote: post #199

Earlier quoted context omitted.

If this happens, it will be the end of open source and the indie web. Only large companies with large legal departments and serious liability insurance, and anonymous underground hackers, will be able to afford to make software public for commercial use or run a website.

That's one extreme extrapolation. How about, if this happens, it will be the end of commercial IP and the closed-web. Only open source with its inherent transparency and broad, distributed contributors (who would you sue? everybody at once?) and constant, real-time updates and improvements without lock-in or planned obsolescence would thrive when improved regulation gives avenues for redress and improves consumer awa…

That is an unrealistic scenario and it also not desirable to get rid of commercial software. It would give large enterprises a software monopoly.
Post reply on HN