Related:

The Six Dumbest Ideas in Computer Security (2005) - https://news.ycombinator.com/item?id=28068725 - Aug 2021 (21 comments)

The Six Dumbest Ideas in Computer Security (2005) - https://news.ycombinator.com/item?id=14369342 - May 2017 (6 comments)

The Six Dumbest Ideas in Computer Security - https://news.ycombinator.com/item?id=12483067 - Sept 2016 (11 comments)

The Six Dumbest Ideas in Computer Security - https://news.ycombinator.com/item?id=522900 - March 2009 (20 comments)

The Six Dumbest Ideas in Computer Security - https://news.ycombinator.com/item?id=167850 - April 2008 (1 comment)

The Six Dumbest Ideas in Computer Security (2005) - https://news.ycombinator.com/item?id=35811 - July 2007 (2 comments)

Yep, it’s worth repeating.

Although I’d spin the issue about host vs network security differently. I’ve found that engineering teams prioritize security a lot more if they don’t feel like they’re safe in a cocoon of local network bliss behind network firewalls. I love “beyond corp” or “zero trust” precisely because you’re making it explicit that they’re on the internet and they’re a target.

> Yep, it’s worth repeating.

I don't know; I haven't really seen most of these things in the wild for a long time.

For "#4) Hacking is Cool" the zeitgeist has moved in the exact opposite direction with "white hat", bug bounties, etc. I think that section in particular is a pretty outdated view of things.

"#6) Action is Better Than Inaction" is probably the only one that still broadly applies today, and is actually a special case of "X exists, therefore, therefore we must use it ASAP, and any possible negativities are not our problem and inevitable anyway" attitude that seems the be prevalent among a certain types of people.

Honestly #4 applies as much as ever. - At least in most regards.

The thing is: The 'security researchers' which I've had contact with focus mostly on hacking and memory corruption attacks.

The thing is: This is a solved problem by now!

And yet, instead of teaching students to avoid the horrible tools, which cause those problems, they keep on teaching how to penetrate and fix.

It's maddening.

Please tell me you have already thrown Firefox, Chrome, old Microsoft Edge and whatever browser out of window and are posting to HN with you rewritten-in-Rust lynx.

Not being able to rewrite the world or convincing people to stop using memory unsafe languages is entirely unrelated to what security researchers do.

I'd love to stop having to build complicated lifetime model in my mind to figure out whether there are hidden code paths for a UAF, but at the same time this is the best thing I can do to secure what we have today, now it's on you to rewrite the world.

No.

We need to stop compromising.

Yes, there is a lot of old code.

No, I can't do it all on my own.

But we can do it as a profession. Refuse to take jobs, nag managers, refuse to by hardware that only supports C, etc.

If construction was as ridiculous our fiels, we'd still use asbestos.

> Refuse to take jobs

Well, I'm unfortunately not in a place where doing so makes sense. Unless you mean only auditing Rust code.

> nag managers

I already do so. This doesn't change much. There are still too many must-be-evolved C++ projects (no easy incremental rewrite path forward), it is impractical to have engs put significant effort into rewriting in Rust. It's really difficult to convince someone to fix something ain't broken.

People coding in C++ are just as desperate as you, that's why someone bring up Carbon [1], a half-baked experimental project to the world last year, instead of just using Rust. Sure, they would like to use a memory safe language as possible. No, they still have to get their job done.

> refuse to by hardware that only supports C

If it supports C, we can make it support Rust, it's a very fun weekend project to bring-up some nostd Rust code on it.

[1] https://github.com/carbon-language/carbon-lang