Hacker News Reader

Comment by doytch | Hacker News Reader

I get the mentality but it feels very much like security through obscurity. When did we decide that that was the correct model?

View on HN

Security through obscurity is only problematic if that is the only, or a primary, layer of defense. As an incremental layer of deterrence or delay, it is an absolutely valid tactic. (Note, not commenting on whether that is the rationale here.)

That, and plenty of closed-source software at least has a decent security track record by now. I haven't seen an obvious cause-and-effect of open-source making something more secure. Only the other direction, where insecure closed-source software is kept closed because they know it's Swiss cheese.

They probably lack a sufficient density of people who remember why "security through obscurity" become an infamous concept. It belongs to that family of bad ideas that's superficially appealing, especially if you're still at that stage of your career at which you think past generations were full of idiots and you, alone, have discovered how to do real software development.

This is not security via obscurity; it is reducing your attack surface as much as possible.

Reducing your attack surface as much as possible via obscurity.

Going closed source is making the branch secret/private, not making it obscure. Obscurity would be zipping up the open source code (without a password) and leaving it online. Obscurity is just called taking additional steps to recover the information. Your passwords are not obscure strings of characters, they are secrets.

If there is a self-hosted version at all, then the compiled form is out there to be analysed. While compilation and other forms of code transformation that may occur are not 1->1, trivially reversed, operations, they are much closer to bad password security (symmetric encryption or worse) then good (proper hashing with salting/peppering/etc). Heck, depending on the languages/frameworks/other used the code may be hardly compiled or otherwise transformed at all in its distributed form. Tools to aid decompiling and such have existed for practically as long as their forward processes have, so I would say this is still obscurity rather than any higher form of protection.

Even if the back-end is never fully distributed any front-end code obviously has to be, and even if that contains minimal logic, perhaps little more than navigation & validation to avoid excess UA/server round-trip latency, the inputs & outputs are still easily open to investigation (by humans, humans with tools, or more fully automated methods) so by closing source you've only protected yourself from a small subset of vulnerability discovering techniques.

This is all especially true if your system was recently more completely open, unless a complete clean-room rewrite is happening in conjunction with this change.

Fully agree. But cal.com is SaaS-only, after they move to closed-source, there will be nothing to download.

I think cal.com is assuming LLMs are only good at hacking with the source code of the target, whether that's true I don't know

right, they're just securing their application by making the bugs obscure. It's totally different.

Security through obscurity is still better than no obscurity...

hey cofounder here. since it takes my 16 year old neighbors son 15 mins and $100 claude code credits to hack your open source project

Right, but those capabilities are available to you as well. Granted the remediation effort will take longer but...you're going to do that for any existing issues _anyway_ right?

I understand why this is a tempting thing to do in a "STOP THE PRESSES" manner where you take a breather and fix any existing issues that snuck through. I don't yet understand why when you reach steady-state, you wouldn't rely on the same tooling in a proactive manner to prevent issues from being shipped.

And if you say "yeah, that's obv the plan," well then I don't understand what going closed-source _now_ actually accomplishes with the horses already out of the barn.

> those capabilities are available to you as well

Give him $100 to obtain that capability.

Give each open source project maintainer $100.

Or internalize the cost if they all decide the hassle of maintaining an open source project is not worth it any more.

I'm not aiming this reply at you specific, but it's the general dynamic of this crisis. The real answer is for the foundational model providers to give this money. But instead, at least one seems to care more about acquiring critical open source companies.

We should openly talk about this - the existing open source model is being killed by LLMs, and there is no clear replacement.

Are you at all worried that the message you are spreading here is "We are no longer confident in our own ability to secure your data?"

That's exactly the message I got from the video

That's literally the message

Couldn't you just spend those $100 on claude code credits yourself and make sure you're not shipping insecure software? Security by obscurity is not the correct model (IMO)

Please, go ahead!

It only takes 20 minutes and $200 to hack a closed source one too though. LLMs are ludicrously good at using reverse engineering tools and having source available to inspect just makes it slightly more convenient.

Very true, but that is still a meaningfully higher cost at scale. If, as people are postulating post-Mythos, security comes down to which side spends more tokens, it is a valid strategy to impose asymmetric costs on the attacker.

A little harder when you don’t have the source or the binaries.

> neighbors son 15 mins and $100 claude code credits

Is that true? Didn't the Mythos release say they spent $20k? I'm also skeptical of Anthropic here doing essentially what amounts to "vague posting" in an attempt scare everyone and drive up their value before IPO.

whooptie fuggin doo, then spend $200 on finding and fixing the issues before you push your commits to the cloud

*This comment sponsored by Anthropic

I don't think this really helps that much. Your neighbor could ask an LLM to decompile your binaries, and then run security analysis on the results.

If the tool correctly says you've got security issues, trying to hide them won't work. You still have the security issues and someone is going to find them.

If I understand correctly, their primary product is SaaS, and their non-DIY self-host edition is an enterprise product. So your neighbor wouldn't have access to the binaries to begin with.

Why not can’t you (as in Cal.com) spend that amount of money and find vulnerabilities yourself?

You can keep the untested branch closed if you want to go with “cathedral” model, even.

What makes you think it'll take him more than 16 mins and $110 claude code credits to hack your closed source project?

SaaS makes that harder.

> since it takes my 16 year old neighbors son 15 mins and $100 claude code credits to hack your open source project

To what end? You can just look at the code. It's right there. You don't need to "hack" anything.

If you want to "hack on it", you're welcome to do so.

Would you like to take a look at some of my open-source projects your neighbour's kid might like to hack on?

No it doesn't. Have you been actually "hacked"?

Was open source any more secure before LLMs became so cheap? For those same 100$ you could have a North Korean hacking your code for a whole month.

Reply on news.ycombinator.com