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

181–190 of 386 posts

Re: The Insecurity Industry

#181

Post by lionkor »

FractalHQ wrote: post #148
MichaelMoser123 wrote: post #128

Earlier quoted context omitted.

Where is your legislation supposed to draw the line? In Rust you need to have occasional unsafe code - you can't even have a double linked list or bidirectional graph without unsafe code. Would you also outlaw jni calls in java?

Can’t unsafe Rust (when properly isolated) exist within a larger codebase that, as a whole, can still be considered safe?

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

Re: The Insecurity Industry

#182

Post by n0on3 »

I think we already know how to build secure tech, we just don't because of the cost, which is not 2x or 10x but way higher to the point that is deemed not worth/feasible both for private companies and governments, so it affects everyone and we are not getting out of it anytime soon (if anything sometimes we go in the opposite direction following the goal of money and calling it innovation). Heck, I think it would take a book just to even explain all the components of this argument. Go figure do something meaningful about it. Safe/unsafe languages is just one piece of this thing, and frankly a quite easy one to wrap one's head around: we already have so much stuff we use everywhere written when memory-safety was not really cared for and no-one wants to rewrite / catch up / surpass (there you go: because of the cost). So we get on with it, because meanwhile life goes on, bread needs to put on the table, people want to play with their shiny phones and whatnot, etc.

Re: The Insecurity Industry

#183

Post by rapsey »

SV_BubbleTime wrote: post #97
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…

If there is one thing politicians are surely better at it than programmers is making decisions about what programming languages should be used! /s Yes on theme, but no on ”there aught to be a law” that bans C/C++ because of an evolving goal of memory safety. When Rust++ comes out surely there will be people complaining that Rust isn’t safe, and so on. Best case is you make the consequence punishable (as was described…

> If there is one thing politicians are surely better at it than programmers is making decisions about what programming languages should be used! /s

Programmers aren't that good at it either.

Re: The Insecurity Industry

#184

Post by z77dj3kl »

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 think he's referring to the standard, non-hidden microphones.

Re: The Insecurity Industry

#185

Post by jodrellblank »

d110af5ccf wrote: post #83
jodrellblank wrote: post #78

Earlier quoted context omitted.

All the internet backbone routers, endpoint routers and switches, hardware firewalls, VPN concentrators, the SSH daemons, SSL software, RSA keyfobs and the like, the content delivery networks and DNS ecosystem, SSL public trust system, the connectivity providers from ISP networks and national and international fibre connections to cellular and wifi networks, web browsers which billions of people use to interact with…

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?

Re: The Insecurity Industry

#186

Post by GoblinSlayer »

Hermitian909 wrote: post #112
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…

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…

Even in confines of C there are coding conventions with lower bullrun compatibility and there are some projects that use them: putty and s2n use them with C, grpc library uses it with C++. Fat pointers are in talks since 80s and are cheaply implementable, meanwhile Fuchsia, an allegedly new codebase, is written in old good 70s vanilla C as if PDP-7 is still hot.

As for the article, the dream to get all UBs right without a systematic approach is idealism.

Re: The Insecurity Industry

#187

Post by GauntletWizard »

otabdeveloper4 wrote: post #166
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.

> Linux kernel rather actively embraces experimental code written in Rust False. Which broken telephone did this come from? The Linux kernel has 0% Rust code in it and has no plans to change that.

https://lore.kernel.org/lkml/20210704202756.29107-1-ojeda@ke... - A patch to include experimental rust support, with support from Linus; I believe it's in the latest mainline HEAD.

Re: The Insecurity Industry

#188

Post by pjmlp »

"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 quickly Mark Zuckerberg would start smashing the delete key.

Where there is no liability, there is no accountability... and this brings us to the State. "

Yep, this definitly needs to eventually happen.

Re: The Insecurity Industry

#189

Post by pjmlp »

Karrot_Kream wrote: post #160
nine_k wrote: post #123

Earlier quoted context omitted.

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…

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.

Re: The Insecurity Industry

#190

Post by pjmlp »

roca wrote: post #162
h_anna_h wrote: post #152

Earlier quoted context omitted.

This is false. There are multiple safe C implementations. compcert and https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html are two such.

Compcert is a verified compiler. It guarantees that the generated code does what the source code requires. It doesn't turn unsafe C programs into safe ones. "Fail-Safe C" is a research project that has been dead for ten years. Note: > Some benchmark results show that the execution time are around 3 to 5 times of the original, natively-compiled programs, in avarage That overhead is actually a lot higher than similar p…

Actually that is what Oracle did with SPARC ADI, Google/ARM are pushing for with MTE, Apple is trying to do with PAC, Microsoft with Phonon.

When everything else fails, kill the bug with hardware memory tagging spray.

Post reply on HN