hirsin

Less technical here doesn't neccesarily mean "worse engineers". It can also mean lawyers, marketing, sales, product, and leadership.

Someone is trying to learn something from you and you give them an answer so full of holes and caveats that it looks like fishnet stockings, you haven't imparted any confidence to them in your answer.

HUD and FEMA alone are 2.5x larger than USAID's budget, so while I can't argue with the unsourced bit that it would be shocking, it's clear there is and was even more money being spent on Americans too.

Maybe we've worked with different FF systems, but anything that involves a call more expensive than an RPC would be lethal to request latency. Calling out to a CDN forty five times per inbound request would be... Infeasible

You'll still be building management UI over their system (it doesn't understand or validate actor types, tenants, etc, so you have to do that.).

But at high throughput, you might want something with dedicated professional love. Ten thousand feature flags, being checked at around 2 (or 200) million RPS from multiple deployments... I don't want to be the team with that as their side project. And once you're talking a team of three to six engineers to build all this out, maybe it makes sense to just buy something for half a million a year. Assuming it can actually fit your model.

Except that she was not rejected - she rejected them. She simply couldn't get a match with a job that worked for her.

They're not just the insurance company - they are also the pharmacy manager who sells the drugs to the patient. So there wasn't really anyone to negotiate with - they pick the price they want to sell the drug for and then how much of it they'll cover.

Pick the right number is not secure (enough), unfortunately - MFA exhaustion leads to users hitting one of three at random in an attempt to "make the notifications stop" (that are, naturally, being spammed by the attacker with a password but no mfa).

The attacker just has to spam them a few dozen times to get the victim to pick the right one at random and let the attacker in.

This is why it's switched on good platforms to "type in the number you see", which mitigated this.

Keys are _not_ just long passwords. They're asymmetric. Feel free to steal any and all of my webauthn public keys.

Heck, here's one: "kty": "EC", "alg": "ECDSA_w_SHA256", "crv": "P-256", "x": "xYkEVgMClD28hXHn5JQjrgjRX3crmr0OhGiWKsLvxUY=", "y": "5lZZGFF6VrVubIHfRhGbvQBGpw6LcbP3/ZBVk7PqH0Y="

It's what you'd get if you somehow got into the db and decrypted it.

Now, do feel free to give me your nice symmetric secret password, since it's the same, yeah?

Pointing out that they maybe have experience with this (however you want to phrase it) does sort of lend the guidance some credence no?

I was curious - land use stats in the US show agricultural use has dropped from 49% to 45% in the last 60 years, with the majority of the loss in the 90s and early 60s. Basically zero change in the last 20 years. https://data.worldbank.org/indicator/AG.LND.AGRI.ZS?location...

It looks like there's about 20x more ag land, by sq km, than urban land in the US (4M to about 200k). So even if urban areas doubled in size, purely at the expense of ag (and not forests), it would be about 5% loss overall.

I have a feeling these numbers don't account for suburban land use, and that's actually an issue... Not urban use.

Oauth usually implies some variability of access - ie selective permissions. Is this more a pure authn layer as opposed to authz?

You have a repo on GitHub... Have you looked at using account public keys for anything? Ie https://github.com/hpsin.keys I hear a lot about how those keys should get used to bootstrap pki systems but I've not seen it happen yet.

Convenience. If it works like Google pay (fair bet?), it hands over your payment, billing, and shipping details in one go. It's wildly effective.

What? That's token to self, you don't even really need an access token there. What's the actual use case for an access token where the client and the resource are the same app? (I'm aware of some, but we didn't expect most folks would follow that flow)

Do you want select account, implying the site supports multiple accounts at a time, or just prompt=login?

We're still shaking out bugs and bad behaviors after adding multi account on GitHub, I get why folks might not want to implement it.

Cosign. AAD ID tokens had the same issue, and we'd see tokens with 1500+ guids shoved in there for the group ids. We had (and have) a nasty "too many, go call this API you need a new permission for" outcome there.

Right next to those customers were the ones demanding our tokens always be an exact number of bytes (yeah. Really).

Is that just because they're old trees, which are stronger than the fast farmed ones we get today?

Should I read this as a reversible hash? I can't imagine it works this way, have you got any pointers to learn more about early sabre ?

It's rare in my experience. We don't support OIDC, so technically it's standalone oauth. In reality there's of course a user identity in the mix used to authorize the resulting access tokens.

Even server to server calls, ie daemons, service principals, what have you, still rely on a client identity.

I think the closest to true agentless access I've seen widely used are SAS for Azure Storage and of course deploy keys in GitHub, which we're building off ramps for. Agentless authz just is not a good idea

I was a bit disappointed that the kwak glass didn't make an appearance here. Although I suppose the treatment of the thick bottom as being better insulating wins out over volume efficiency.

It's not my first time seeing this, but I'm struck by some disappointment in the legacy of OSS here. The author clearly understood what was happening enough to post this to the unix SO - but not enough to find the `man` code and grep for the string that had to be present? I'll admit I don't immediately know where to go to look for the source code, but I can't imagine it's some tightly held secret address to a file share somewhere.

Alternatively - maybe it wasn't the difficulty of finding it but the (perceived?) difficulty in requesting that it be changed?

E - maybe the likely alternative is the "the customer has nukes so please fix it" entitlement? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644#c4

Ooh that's excellent news, thank you! When I'd last checked it was not an option and our account rep had no predictions to offer.

Okta barely supports OIDC I'm afraid. We have to use SAML with them because they don't support a reusable app model for OIDC (a "marketplace app" that multiple customers can use).

I'd love to add FastFed support for OIDC and be done with it but SAML still rules the world.

Cheese is a processed food, class 3. "Cheese products" like Kraft and Velveeta are class four ultra processed given the additives and way it's broken down and reformed.

This is malpractice, so if you have evidence of this you should consider reporting them. Certainly I've never had this issue with my opticians, but have certainly had plenty of bad Zenni glasses.

What recent experience? Do you mean keeping them home from school for covid? I don't think the knock on effects from that are remotely traceable to their immune systems.

I was ready to go along with that but uh, it converts down to urethane. Let's maybe let people take the hit on their bread not being so fluffy (and probably more profitable) to avoid extra urethane in our food.

Similarly with a sibling comment about how we use condom lubricant in cooking oils, maybe we just shouldn't?

I could believe that being in 2.1 as a BCP,but if it's not it's a good idea to add it.

/s? The violations in question almost all happened during ZIRP. Capitalism is the culprit here, zero interest loans just meant they had more juice to squeeze from their workers.

In the sense of "I refuse to support browsers that only support tls 1.0", definitely. "Just let the user turn off TLS, why do you hate choice" isn't the instant win you might hope it is.

I feel like we'll get a (less physically _real_, but much more impactful) run of this "make it to the next day unscathed" adventure in 2038. Only 14 short years...