https://xkcd.com/538/

One would be that people are the weak point in your security system. If all your organizational security hinges on one guy not folding, that guy is the natural target. Whether a literal 5$ wrench is used or they bribe him makes no difference.

That means you could consider shaping your org in a way that is resistent against this by e.g. decentralizing secrets. That means instead of bringing a "5$ wrench" to one person (which may even work without raising suspicion), you now need to convince multiple people at once which is much more unlikely to work without being detected.

The only defence is to not have the secret at all.

As for secrets, you sometimes need to have them for very good reasons. If you can reach the same goals without a secret while having the same protection going without a secret is a good choice.

But let's assume if you want the cryptographic protections of confidentiality (through encryption), authenticity (through signatures) and integrity (also through signatures or hashes) chances are someone somewhere has to store a secret. If that someone isn't you it is someone else (or something else).

But if you want to protect data with encryption and you should be the only one who can decrypt it I don't really know how you would do it without any form of secret.

If they want our information, they should have to become literal tyrants, send armed men after us and violate human rights in order to get it. Not push a button on a computer to tap into their warrantless global dragnet surveilance networks and suddenly have our entire private lives revealed to them on a computer screen.

Yes, people will fold if they are kidnapped and tortured. That's not news. Forcing them to stoop to that is the entire design. Once the situation has escalated to that level, you are justified in killing them in self-defense. Torturers don't make a habit of allowing their victims to live and testify about it.

Don't make me link 1053 ;)

every comment that has little bit content of security/cryptography/secure/blockchain/CIA etc always mention this particular entry

https://en.wikipedia.org/wiki/Generic_trademark

Huh, bubble wrap, even.

Video description, from the Velcro brand YouTube channel:

Our Velcro Brand Companies legal team decided to clear a few things up about using the VELCRO® trademark correctly – because they’re lawyers and that’s what they do. When you use “velcro” as a noun or a verb (e.g., velcro shoes), you diminish the importance of our brand and our lawyers lose their insert fastening sound. So please, do not say “velcro shoes” (or “velcro wallet” or “velcro gloves”) - we repeat “velcro” is not a noun or a verb. VELCRO® is our brand. #dontsayvelcro

The end-goal is to gain complete access to the system - the outcome (data theft or ransomware) is customers choice

I've had an ROG Zeph collecting dust for a couple years now, specifically for the reasons you described, which I now have a good reason to dig out and poke around in. Got my weekend sorted :)

    I'll preface this comment with: I am a recent startup owner (so only dev, which is important) and my entire codebase has been generated via Sonnet (mostly 3.7, now using 4.0). If you actually looked at the work I'm (personally) producing, I guess I'm more of a product-owner/project-manager as I'm really just overseeing the development.

    > I have yet to see an LLM-generated app not collapse under it’s own weight after enough iterations/prompts.

    There's a few crucial steps to make an LLM-generated app maintainable (by the LLM):

    - _have a very, very strong SWE background_; ideally as a "strong" Lead Dev, _this is critical_

    - your entire workflow NEEDS to be centered around LLM-development (or even model-specific):

      - use MCPs wherever possible and make sure they're specifically configured for your project

      - don't write "human" documentation; use rule + reusable prompt files

      - you MUST do this in a *very* granular but specialized way; keep rules/prompts very small (like you would when creating tickets)

      - make sure rules are conditionally applied (using globs); do not auto include anything except your "system rules"

      - use the LLM to generate said prompts and rules; this forces consistency across prompts, very important

      - follow a typical agile workflow (creating epics, tickets, backlogs etc)

      - TESTS TESTS AND MORE TESTS; add automated tools (like linters) EVERYWHERE you can

      - keep your code VERY modular so the LLM can keep a focused context, rules should provide all key context (like the broader architecture); the goal is for your LLM to only need to read or interact with files related to the strict 'current task' scope

      - iterating on code is almost always more difficult than writing it from scratch: provided your code is well architected, no single rewrite should be larger than a regular ticket (if the ticket is too large then it needs to be split up)

    This is off the top of my head so it's pretty broad/messy but I can expand on my points.

    LLM-coding requires a complete overhaul of your workflow so it is tailored specifically to an LLM, not a human, but this is also a massive learning curve (that take's a lot of time to figure out and optimize). Would I bother doing this if I were still working on a team? Probably not, I don't think it would've saved me much time in a "regular" codebase. As a single developer at a startup? This is the only way I've been able to get "other startup-y" work done while also progressing the codebase - the value of being able to do multiple things at a time, let the LLM and intermittently review the output while you get to work on other things.

    The biggest tip I can give: LLMs struggle at "coding like a human" and are much better at "bad-practice" workflows (e.g. throwing away large parts of code in favour of a total rewrite) - let the LLM lead the development process, with the rules/prompts as guardrails, and try stay out of it's way while it works (instead of saying "hey X thing didn't work, go fix that now") - hold its hand but let it experiment before jumping in.

Right now your comment reads like something off a conspiracy forum and has nothing to back it up - which is not something that warrants discussion (on HN).

I wouldn't, in my opinion:

Capitalism incentivizes selfishness at the detriment of others that are "playing the [capitalism] game" or anti-competitive practices. It also pushes people to hoard resources - think Tragedy of the Commons or anti-competitive practices in general. The incentive is to reduce the amount of resources available to competition while increasing your holdings, allowing you to repeat the loop but with higher chances of success.

Providing something others find useful seems like a lucky side effect that often isn't even true, there's a lot of industries who have no intention of providing something useful (like stock trading, short trading especially). Most companies are trying to reduce costs as much as possible, reducing the usefulness of their product/service to the lowest point that people will still pay for.

But I agree with your other points - just because capitalism breeds selfishness it doesn't mean all parties are going to the extremes.

Capitalism prioritizes making money, not satisfying people's needs and wants.