Unauthorized removal of bitcoin from a wallet, depositing into another?

Doesn't even have to be Bitcoin. Could be an ordinary set of bank accounts.

Yep. Lots of money-ish examples.

I think these four people want to be in a smaller organization. It's more fun.

Good, realistic take. There's a lot of context that can be drawn on to make better decisions and look for weird.

And then agents come along and some people want their agent to be able to do anything they can do with zero friction. That usually lasts until the first time something goes wrong ;)

Actually zero trust can be seen as an optimization problem, you almost certainly want to globally deny every single request, even for authenticated users under all circumstances to all resources, unless when "necessary", "necessary" here is the key because it needs to be as dynamic and as fine-grained as possible, context-based and scalable. For small businesses, RBAC and ACL rules can be fine, but for enterprises with thousands or tens of thousands of employees, contractors and now AI agents which need varying permissions to different resources at different times, you would have to define thousands or tens of thousands of rules that might conflict with one another and are hard to maintain. ABAC and policy-as-code can mitigate to a certain extent providing dynamic context-based fine-grained access control. But if you could gather as much information as possible about every user and every session, combine it with some boundary permissions and static rules, and feed it periodically to some reasoning engine that is tasked with dynamically increasing/decreasing permissions for each session based on all such info, you can keep your manual/static access control policies to a minimum and maybe even eliminate JIT in some cases. The real question is whether modern LLMs and transformers are the correct and optimal architecture for this problem in the first place.

Agreed; I don't think we want security controls to devolve into an argument between LLMs. Attacking and defending LLMs operate in an ecosystem, and are (hopefully) limited by constraints. Defending LLMs will be able to rely on and evolve those constraints. Attacking LLMs want to find a way around them.

+1000, and the role of non-deterministic security is to compose deterministic security primitives.

Deterministic executes fast and you know what it will do. You want to evolve your ground truth, not hope for the best.

That said, there is a role for probabilistic elements in the security model...as bait and signal.

I don't think the point here is to fully replace deterministic with non-deterministic-based access control. The point is to combine the traditional manual/coarse-grained deterministic access control with an additional layer of dynamic, fine-grained non-deterministic access control.

- Liability - What can you really fit in HW4? - No right answers in many situations. - But mostly liability. It's pretty good.

You're highly critical. What would you be doing differently? So far Tridge has elected to:

- generally decide to fix security issues over preserving compatibility - rewritten an aging test suite in what appears to be a highly responsible way - brought on additional qualified developers to help with the workload

Not bad for a guy who's retired.

You care enough to complain on HN. You could be a part of the solution.

What were you going to do differently, specifically?

Yeah, we definitely need to make sure that we take the considerations of the mob into account.

The person owning the project is using the master branch in the way he sees fit.

Incidentally, there is no amount of communicating "correctly" that quells a mob. There's a Venn diagram of concerns, and those with concerns not being met will generate (now infinite) outrage.

I recommend "How to measure anything in cybersecurity risk". Really interesting read about putting actual value on security.

I'm truly hopeful that AI will open a new of prototyping. Back in the day, prototyping was how you figured out what to build, you'd very deliberately toss the entire first (or second!) version, and you'd plan to do that.

High quality ensued. Usually ;)

Most places I've worked, devs were basically afraid to prototype

Either you would get chastised for wasting time with prototypes, or worse, your prototype would end up in production

I think the software industry really needs a cultural reset to embrace slower and deliberate development to build quality, but unfortunately AI has us racing recklessly in the wrong direction

I am so tired of it. Are there any companies out there that actually give devs time to build quality software anymore? I'm so burned out of the "move fast and break everything" grind

I understand both sides.

Quality must come from engineering. If you’re depending on a product manager to ask you that you can improve the quality of the code, you already lost.

So it requires soft skills, proper framing and ability to iterate quickly on quality-related tasks without leaving junk and multiple-versions behind.

But I completely understand push back for “doing improvements developers want to do”: A lot of developers confuse quality with familiarity or even complexity/verbosity. So business people have a reason to be reluctant.

And as an engineering manager I also had to push back several times. The thing that makes money is not the place to learn new skills, for example.

I think there's an argument that it could be cheaper and better for morale to let employees upskill while working on the thing that makes money.

It really depends on how mature the developer is.

If they have the soft-skills to do it, then by all means.

If not, they need to upskill their soft skills before tackling anything big.

Ask on sprint planning if time can be set aside to spike out a proof of concept, and then you go do that prototyping in the sprint.

Has this (for me, normal) process really been that arduous in your past jobs? It's a slam dunk to leadership, as we do this to corral time wasted.

All these companies want devs with top-engineering talent and coding skill, but then fire them because they aren't using LLMs enough.

Might be the opposite in some orgs. Higher ups in working with get visibly annoyed when you start talking about prototypes or trying something out in isolation, they don’t see why you wouldn’t just work with the real codebase and end the project with a PR.

Also seeing a lot of managerial class bypassing the PR system entirely and just committing to main “because it’s faster”.

Now it's possible to toss many more. :)

I think this is nonsense.

Prototyping already existed - how do you think the iPhone came into existence?