Where possible I prefer to implement signed policy objects. Then I can constrain access based on source IP and other request parameters. You can also easily implement an expiration date if you feel any particular application requires it, but some simple constraints may be useful enough that you might skip this in the majority of server to server applications.

This not only provides security but provides some resistance to bugs in your code which either call services incorrectly or call the incorrect methods of a service. I've avoided accidental data deletions and other painful events because my policy document did not allow this action. It turns these bugs into failures at the security perimeter.

I've used this concept in a few user applications as well. Typically those documents will always have expiration dates and I'll provide a "license" API which allows a single authenticated client request to retrieve an appropriate policy document. This is particularly nice when you want to implement a service across different providers or want to avoid downstream authentication overhead.

Of course, for reliability, you could even bake multiple paths into the envelope address.

Anyone remember the incredible disrepute of the phone company in the 80s?

We just wanted our own stuff. We did not want to coordinate with a proprietary vendor to network or be charged by the byte to do so.

Troops are not homogeneous.

Some of them are into it.

Unless someone knows the bets are placed by an insider how does this create any sort of risk?

I mean just the fact that bets are being placed could have tipped off the target and made them prepared.

Incentivizes him to take on more risk to ensure mission success.

When someone bets 32k that a political opponent of the US is going to be kidnapped I think its fair to say some will assume it was placed by an insider.

What exactly would that look like from the position of an individual low rank unit? What would $32k of risk look like on a foreign battle field? I'm struggling to understand this prerogative.

What would be far larger source of risk is if they bet _against_ the operation and then personally sabotaged it. That's far more understandable but it's not what happened here.

It apparently and sadly needs to be said on Hacker News, I'm not defending him, and he should be punished, but I genuinely can't apprehend the risk assessment logic here.

He's a master sergeant, once of the highest enlisted ranks, involved in planning the mission. Not low rank at all.

A lot of people were involved with the mission that were not themselves directly endangered but could still stand to profit.

Easy to think of a scenario where he should stand down but instead continues with the mission, risking the lives of his team mates, or maybe civilians.

He was incentivized to win the bet. The military does not want people to have outside loyalties because that creates problems any time they’re not perfectly aligned – for example, if they had orders to minimize team or civilian casualties you don’t want this guy starting a messy firefight because he’s thinking the target is getting away and willing to risk someone else’s lives for half a million dollars.

You also have to think about leaning information: if people do this, bodyguards around the world are going to monitor betting markets looking for unexplained changes. The military doesn’t like anything which can leak timing information since that increases the risk of a mission failing.

They are synonyms as that includes "nearly the same."

The only difference I can detect is that "class" allows members to move between groups and "castes" do not; however, all the outcomes are identical. So they are absolutely synonymous in most peoples eyes.

Hegseth represents existing military priorities. The original comment presents the issue as if it's isolated to a single administrator.

It wouldn't call it TDS but it does project a severe political blind spot.

Then use AI to make a dishwasher. Why aim for accounting first?

It's easy to get users. Speaking of accounting we should probably just measure profits.

Because robotics is really hard. Several companies are trying to make kitchen robots, but none of them are close to a viable product at the moment.

It's amazing to me that people believe a company is easier to run than a robot. Several people try to start business every year, most of them fail. The lesson is right there.

We have dishwashers.

We also have accountants. They're not even hard to come by.

Wealth inequality.