Hacker Timesnew | past | comments | ask | show | jobs | submit | FrankWilhoit's commentslogin

In the typical medium-to-large company that has legacy implementations of a few decades' worth of processes, RBAC is absolutely infeasible. The legacy systems evolved to accommodate specific individuals who wore multiple hats, and now that those persons are gone, the processes that they left behind can only be worked on a cargo-cult basis.

At some of the larger orgs that I've worked at each individual system had some level of RBAC. Often they would try to centralize around an Okta-style system, but the roles in there infrequently matched what was needed. In the places you are describing what have they done around security? Even without AI it sounds like they didn't have a feasible solution?

We can have technology, but we have to live up to it. Each new discovery means we have to think more deeply, more quickly, more clearly. If we do not rise to that obligation (which we never have), the technology does us no good; it is only a burden and a misery.

"Deciding to accrue technical debt means there's such a large opportunity in front of you that it's worth sacrificing the short-term quality of the codebase..."

It was courteous of the author to signal, with his very first word, that he is addressing a vanishing splinter of all technical debt. Of course in most cases there is no decision, or even awareness.


This way, every decision is deniable.

This is all about preventing the assignment of blame when something goes wrong. That is why "AI" is worth spending all the money there is, and why it is not going away.

Openness (or fillintheblank) brings more good to a society that believes in openness (or fillintheblank), not to one that doesn't. Start by changing what people believe in. If you say that that is not possible, you are quite right: but then, neither is anything else.

It turns out to be quite unreasonably difficult to put something aside for a time -- from milliseconds to decades -- and then go back and find it again. The difficulty is all in the "find", because things that anyone might care about finding have various different aspects that different people may care about. There is no middle ground between the electronic equivalent of a pile of papers on one's desk and the full capabilities of the relational model. Filesystems are somewhere in between; but there is no useful place in between.

Just one pinprick: "discovering capabilities at runtime" is a security antipattern. There can never be wildcard roles. Every interaction must specify one (possibly composed) role.

I think two different meanings of "capabilities" are getting conflated here. In the HATEOAS sense, capabilities are the state transitions a server advertises via hypermedia links – an API discovery mechanism, not an authorization model. Roles and permissions are orthogonal to that and of course still enforced server-side on every request. A server that takes hypermedia seriously only advertises links the current user is actually allowed to follow, which is arguably a security plus.

Also worth noting: that sentence was just a historical aside about Fielding's original definition. The actual argument of the piece is that what most people call REST is really CRUD over HTTP, and that commands and queries are a better fit.


Third Law of Modern Politics: Nothing is top-down. Everything is bottom-up. "Leaders" follow. The people are the problem.

If he understood this, he would not have had to write at such enormous length. The word count is the tell that the argument is based upon false premises. He has mistaken the jockey for the tiger.


Stop wanting anything to make sense. That was then, this is now.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: