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

321–330 of 386 posts

Re: The Insecurity Industry

#321

Post by pyuser583 »

7373737373 wrote: post #175
pyuser583 wrote: post #151

Is Python a safe language? It doesn’t seem to have the sorts of problems other languages do. Why is that?

Absolutely not, unfortunately. One of the architectural issues plaguing even comparatively memory-safe languages is the fact that there is a global scope that's accessible from anywhere. In some Python versions even numbers or truth values could be redefined. [0] This makes it impossible to sandbox functions or imported modules, because they can communicate arbitrarily. But communication/access security is not the on…

lol … this is the first time I’ve heard some one mention the E language outside the context of “inspiration for Scala.”

This is a very interesting comment, and I’m going to study it and the links you gave. Thank you!

Re: The Insecurity Industry

#322

Post by raxxorrax »

pjmlp wrote: post #246
kragen wrote: post #230

Earlier quoted context omitted.

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

That is for the law makers to decide, If someone gets run down by a bicycle that a hobby repair shop failed to fix, it doesn't matter it was done for free by a guy that learned to repair bicycles during late nights.

This is a completely unrealistic demand of software and security. I am really surprised of Snowdens arguments here.

The law makers cannot make the internet safer by one bit. Technical experts can and lawyers would dream to have leverage against them. They should be denied.

Re: The Insecurity Industry

#323

Post by danarmak »

aj3 wrote: post #304
danarmak wrote: post #284

Earlier quoted context omitted.

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

Your second link mentions sellers avoiding liability by selling product (that can be inspected in stores) "as-is". It could be argued that open source falls in the same category. You have an opportunity to inspect it before using and if you don't like it or don't feel qualified to pass judgement, no one is forcing you to use it.

The second link doesn't mention "as-is", the first one does. I'll assume that's what you meant. It says,

> Though manufacturers cannot so easily escape liability, sellers can escape liability by informing the customer before the purchase that a product must be taken "as-is,” which means how the product was found when it was purchased in-store. “As-is” works because the buyer has an opportunity to inspect the product and decide whether to buy it given its condition.

On that analogy, Github and RedHat aren't liable, but the original author of the software still is.

Re: The Insecurity Industry

#324

Post by raxxorrax »

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…

This is unnecessary regulation and not a good idea. Would that also apply to runtimes, interpreters and compilers?

Liability should be created where when you expose third party data. That would disincentivise data collection massively.

Re: The Insecurity Industry

#325

Post by staticassertion »

MichaelMoser123 wrote: post #301
staticassertion wrote: post #146

Earlier quoted context omitted.

The way this would likely end up being handled is the same as any other compliance. You define the threat model for your application and then justify why you're safe. In this case we'd be adding an explicit point to ensure that there are controls for attackers who can exploit memory safety issues. You could end up with controls like: 1. We sandbox our code, so even though it's C we feel that we're safe 2. We use a me…

would that imply that the state would have to review the design and implementation of every system under their jurisdiction? I think that would be a bit heavy for everyone involved.

This is already the case.

Re: The Insecurity Industry

#326

Post by staticassertion »

BruiseLee wrote: post #278
staticassertion wrote: post #140

Earlier quoted context omitted.

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…

And naturally the ones to decide which software is unsafe will be the lobbyists from the most powerful tech companies like Microsoft or Google.

Not really, no.

Re: The Insecurity Industry

#327

Post by staticassertion »

trasz wrote: post #257
staticassertion wrote: post #250

Earlier quoted context omitted.

You can't just adopt that hardware and get memory safety. The hardware is providing support for a capabilities model, which you then have to adopt at a software level both within your OS, compiler, and application code. This also would break C and C++ ABIs, so it's very unlikely to get adopted for a number of cases. Further, CHERI is not enough to achieve temporal memory safety, it only provides the primitive that on…

Indeed, you need the whole stack. However, the (non-temporal) memory safety alone is still quite easy to get - the compiler will take care of it, as a programmer you just need to make sure your code doesn't get in the way by eg manually stashing pointers into non-pointer types. It's been demonstrated on large, real-world code bases, such as FreeBSD and PostgreSQL. (Disclaimer: been there, done that, part of the CHERI…

Yep, much of the wins look to be a matter of just recompiling, which is great. I'm a big fan of these pointer tagging techniques in general. I just want to be clear that pointing at CHERI and going "See? We already have memory safe C and C++" is glossing over some important details.

Best of luck with the research, I'm quite bullish on the work.

Re: The Insecurity Industry

#328

Post by fouric »

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…

> We could pass a law and ban new code in unsafe languages

I can tell you exactly how this will end up: like PCI DSS.

Re: The Insecurity Industry

#329

Post by LargoLasskhyfv »

pjmlp wrote: post #196
DoingIsLearning wrote: post #158

It feels like we've gone full circle back to 1980 when the US Defense comissioned a 'safe' embedded language. Jean Ichbiah's team won this contract with the language 'Green' in 1979. They subsequently went on to further develop this and standardize it in what was then the Ada 83 language standard. The more I think about the more it feels that Ada just came about to solve the right problem but at the wrong time.

Unisys still sells Burroughs to customers that care about top level security. https://en.wikipedia.org/wiki/Burroughs_large_systems ESPOL/NEWP were the very first system programming languages to have UNSAFE code blocks, 10 years before C was even an idea. Before that there was JOVIAL as well, https://en.wikipedia.org/wiki/JOVIAL

Hasn't that morphed into some sort of emulation nowadays?

Like almost COTS(common of the shelf) Xeon, running some hypervisor and the 'legacy' within? Similar to what Symbolics did with Genera for Alpha?

edit:

[1] https://microsites.unisys.com/offerings/clearpath-forward

[2] https://docs.microsoft.com/en-us/azure/architecture/example-...

Azure?! Err...sure...

Re: The Insecurity Industry

#330

Post by dylan604 »

mikepurvis wrote: post #316
dylan604 wrote: post #315

Earlier quoted context omitted.

>"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?

Texas' ERCOT. It's a government appointed regulation body, not a branch of gov't.

Are you really doubting that this is something that "might" happen?

Edit: FAA allowing Boeing to self-certify 737MAX. FDA allowing/not allowing trials of drugs, or allowing a drug meant for one thing to be tried for something else totall untested (ex: AZT).

Post reply on HN