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

221–230 of 386 posts

Re: The Insecurity Industry

#221

Post by throwaway210222 »

pjmlp wrote: post #189
Karrot_Kream wrote: post #160

Earlier quoted context omitted.

Then punish defects. Give programmers the freedom to define their semantic space, but make sure to punish profit-seeking entities for insecure behavior. It's not that simple of course (it's easier for FB to pay a fine than a startup, for example), but we need to enforce the cost of defects at the organization level. I mean, there's also a world where FB apologizes about how they "forgot" to remove `unsafe` from a par…

Definitly, liability needs to happen, sledgle with lawsuits hammer any company that doesn't take security seriously.

Sledge with lawsuits and company that knowingly buys uncertified software.

Like the FAA does.

Never, ever going to happen in enterprise and consumer software.

Re: The Insecurity Industry

#222

Post by kragen »

grncdr wrote: post #203
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.

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 illegal pornography site? Why didn't your legal office respond within 8 hours when you were notified of a privacy invasion on your blog last Saturday?

Re: The Insecurity Industry

#223

Post by wydfre »

3pt14159 wrote: post #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 natio…

What he is referencing is what I call “artificial complexity”, a way for making solving problems ludicrously wasteful in man-hours. This is primarily accomplished via limiting remixes of known technology - think for example of how easy it is to add types to Lisp and yet it took decades to be attempted publicly.

It is the job of human intelligence to cause ‘discontention’ - discontent and contention. I like to think of how it as how you can make powerful gears almost seize if you understand their weaknesses properly.

Re: The Insecurity Industry

#224

Post by ozim »

grncdr wrote: post #203
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.

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

Personal website - what if someone takes over your server and does malicious stuff?

Are you going to put up with accountability that you might have misconfigured something and it allowed attackers to scam people or serve porn?

You are perfectly sure that you are going to keep your small site updated all the time and you won't forget about it?

Because that is where it is going - it is not just code that can be vulnerable - but also combination of different software, combination of configurations. If you install 2 applications they might interact in a way that makes your system vulnerable.

Software is infinitely complex we can cut down complexity but then anything that is useful and complex will cost a lot more.

Re: The Insecurity Industry

#225

Post by lionkor »

pjmlp wrote: post #191
lionkor wrote: post #181

Earlier quoted context omitted.

The same way you can write safe modern C++ and only use unsafe features of the language when its necessary and isolated, but thats also considered unsafe, so Rust should be, too

My experience with trying that in Visual C++, alongside the C++ Core Guidelines and "borrow checker" static analysers, is that there is what we wish to happen, and how the code actually looks like in reality.

I find that, if you enable all warnings, most as errors, and use clang-tidy and cppcheck, you end up with an incredibly powerful safe language. Now, combine that with some good patterns and avoidance of NIH syndrome, and you can get very far while keeping the huge amount of control and libraries that C++ gives.

Edit: And, of course, a lot of forced static typing and avoiding global scoped stuff. So, for example, you'd make a

    struct Meter {
        float value { 0.0f };
    };
    Meter wall_length;
instead of `float wall_length; // meters`.

Re: The Insecurity Industry

#226

Post by neolog »

kragen wrote: post #199
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…

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.

This makes no sense. Open source doesn't collect my personal information. (Except when it does, which is bad behavior.) Anyway, the law is capable of making reasonable distinctions where necessary.

Re: The Insecurity Industry

#227

Post by d110af5ccf »

jodrellblank wrote: post #185
d110af5ccf wrote: post #83

Earlier quoted context omitted.

The point is that if legislation were introduced that resulted in liability it would likely completely decapitate the FOSS ecosystem (among other things).

Why would it? If faced with the choice of taking liability for using Linux or rebuilding Amazon shop + AWS + Kindle + Echo on Windows I'd guess Amazon would do the former, wouldn't you?

In the short term? Perhaps. They might just develop their own proprietary OS - they already design custom CPUs!

I imagine it would depend heavily on how large the liability was. I expect individual components would begin being replaced with "certified" commercial alternatives. If not existing ones, definitely new ones. Remember that they make money by selling to customers who would also be subject to the same rules. Look at healthcare, aviation, and finance for concrete examples of the effects (both negative and positive) that red tape has on software and IT policies.

There's an entire FOSS ecosystem and the vast majority of it is composed of small-ish slow moving projects. The tech industry is also an entire ecosystem full of small and medium sized players. Even if behemoths such as mainline Linux and AWS somehow survived unchanged I would expect a much greater chilling effect on smaller players that couldn't afford to take on such risks. New companies and software projects would become very difficult to get off the ground (healthcare is a good example here). With few to no new entrants forward progress would slow to an absolute crawl.

All of this has downstream effects. Fewer consumer devices running Linux would mean even less hardware support. Security related liabilities would almost certainly mean more vendor locked hardware. Would companies like Purism remain viable (or even legal)? The steady stream of new FOSS users and contributors would almost certainly dwindle.

Depending on how such regulation was written, could open source contributors themselves become liable for a freely provided product?

Re: The Insecurity Industry

#228

Post by neolog »

roca wrote: post #124
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…

That paper has many problems. For example: > There is no particular need to rewrite existing C code, provided the same benefit can be obtained more cheaply by alternative implementations of C To be clear, those "alternative implementations" do not exist , and no-one actually working on C compilers or tools to make C code safer has been able to produce one, or even come up with a credible plan for producing one.

The author of that paper has written a safe C implementation.

https://github.com/stephenrkell/libcrunch

Re: The Insecurity Industry

#229

Post by lionkor »

michaelt wrote: post #201
lionkor wrote: post #178

Earlier quoted context omitted.

An statistical approach like that has the flaw any the most used language would always appear to be at the top of the "most unsafe". Instead, people should be schooled to write better code. Thats it. Don't let some random new employee with no certifications write safety-critical code. Don't hire people who are under qualified. Its really that easy. I have no idea, honestly, how you would introduce a use-after-free bu…

> Don't hire people who are under qualified. Its really that easy. I understand what you're saying, but I'm not sure I agree. For example, look at Google Chrome. They've got mountains of cash. They've got loads of people working for them, and loads of job applicants if they want more. They've got a strong business case to work on security. They've got in-house pen testers, and a bug bounty program. They've got code r…

You make a good point. There is a lot of evidence that it's not as easy as I make it seem.

I might be wrong about this, too, but I think a lot of smaller companies have the really bad practices. Google shines as one of the major "suppliers" of C++ tooling, and their code quality is undeniably very high (considering the complexity of some of their codebases), but a lot of popular libraries are written by small teams, often not even under contract, and you end up with a lot of PR'ed stuff, which is great, but it needs to be thoroughly reviewed.

A good example of "unqualified" PR's was that recent one with the malicious PR into the linux kernel by some university. It was caught, but it does make you wonder how many vulnerabilities make it through because of simply trusting "random unqualified people" too much.

Re: The Insecurity Industry

#230

Post by kragen »

pjmlp wrote: post #208
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.

Nope, they only need to uphold to the same standards. The guy selling food on the street has the same liability as a restaurant.

The guy selling food on the street has liability in proportion to his profits; fifteen customers, fifteen potential food-poisoning cases. He can set his prices accordingly. Simon Tatham doesn't have any profits, but his PuTTY is installed on every developer's Windows machine. OpenSSL is installed on even more machines. How long do you think it would take your proposed regulatory regime to find that Kurt Roeckx owed several million dollars to every company that generated private keys with Debian's copy of OpenSSL? He did, after all, introduce the subtle security hole that left them wide open for years.

Maybe you could make the case that he was following best industry practices in doing so; after all, using Valgrind is a best practice, right? But you could also pretty plausibly convince a jury that he was negligent. Especially if you're IBM's senior counsel. Or, say, RSA's.

Now, is Kurt Roeckx or RSA going to be advising the US legislators who draft this candidate legislation, establishing the standards that they both must uphold?

Post reply on HN