Hacker News new | ask | show | jobs
by _akhe 784 days ago
> sometimes the design/software is the secret

Decreasingly the case, and we might be at the point I can say "poorly architected" if that's the case. A random 19 year old developer in the military with access to the secrets would be a big security hole too.

That's what we should be comparing with regards to open-source vs not open-source - in either case access to weaponry would of course be heavily gated.

Some of the other arguments you make here are no different than conventional arguments against open-source:

> the real code would still be private

Precisely the point, get the crowd to optimize the low-risk parts, build communities around those libraries and frameworks and recruit from it

> opponents might catch up

To remain an industry leader it's actually better to get everyone playing your game rather than trying to compete and stay ahead in a wild west scenario. You want to capture it really, so you can control it and be the leader in it. Open-source is one great way to do that (browser vendors come to mind).

1 comments

You can say "poorly architected" all you want, but it's true. Military capability is frequently determined by software-implemented behaviours, not data you can plug into a generic public framework.

>19 year old developer with access would be a big security hole

It's true, they are. That's why militaries and defence companies go to great lengths to vet their staff and why even within vetted staff, sensitive material is compartmentalised to minimise the risk from any given individual. Even despite that, military secrets are still leaked on an all too regular basis.

> That's why militaries and defence companies go to great lengths to vet their staff

What a joke, no they don't. They establish security internally by gating access, not trusting everyone because they've been "pre-vetted".

Gating access is compartmentalisation. If you're being brought onto, say, missile development, you absolutely will have to submit to both vetting (knowing who you are prior to access) and compartmentalisation (permitting access only to your relevant secrets throughout).

I'm not saying that just because you have some kind of clearance you will get access to everything, but it's part of the preconditions to your own relevant access.

Yes, those security clearances are the real gates, not anything in your JavaScript codebase, and that's the point - there's already clearance in place within the military, there should be nothing in a codebase that can bypass a security clearance requirement anyway.

A very secure codebase is designed in a way that all the sensitive parts are separated from the parts general users (and developers) have access to - it shouldn't be all imbued together such that sensitive parts about missiles are exposed to login APIs etc. as it seems like you were saying.

It may even be lower risk than not to open-source as the public is more likely to find and fix actual security quirks that a private contractor might miss (or could even be paid as a spy to purposely leave vulnerable).

There's also the community/recruitment aspect. AI/LLM companies are cleverly open-sourcing major parts of their work while keeping the only important part that makes them valuable private - it's a win:win as they keep their secrets yet provide for and stimulate a developer community.