"a filter" is an even better analogy because it is also technically correct

thats not a analogy, its just a description

Fair point, and thanks. Certainly true that Starlink satellites are already successfully dealing with the problem and use a lot of energy.

I think the trouble with my thinking was that I was locked into the Shuttle/STS numbers of waste heat transfer.

Mandatory mention: https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...

But yeah, pretty cool DNS resolving features in HAProxy, that's nifty

I‘ve built this anti-k8s stance pre-LLMs, and just realized that, actually, agents should be pretty helpful in dealing with it? Is avoiding kubernetes still advisable for projects that will likely never use its full complexity, given how easy it is to maintain now?

Kube and helm are ideal for LLM usage, they make what is a fragile kind of thing into declarative, same as terraform for infra at the slightly lower level.

That doesn't solve anything, you can just create event-specific accounts as a scalper (which you can reset after the event has happened).

Non-transferable tickets are bound to a specific name iiuc.

How would 2FA help here, you'd still create the compromised OAuth credential with 2FA?

You should use the subject identifiers, not the usernames. You store a mapping of provider & subject to internal users yourself.

But this has been a problem in the past where people would hijack the email and create a new Google account to sign in with Google with.

Similarly, when someone deletes their account with a provider, someone else can re-register it and your hash will end up the same. The subject identifiers should be unique according to the spec.

Ah yeah but I wanted my platform to provide universal OAuth with any platform (that my app developer user trusts) as OAuth provider. If you rely entirely on subject identifiers; in theory, it gives one platform (OAuth provider) the ability to hijack any account belonging to users authenticating via a different platform; e.g. one platform could fake the subject identifiers of their own platform/provider to intentionally make them match that of target accounts from a different platform/provider.

Now, I realize that this would require a large-scale conspiracy by the company/platform to execute but I don't want to trust one platform with access to accounts coming from a different platform. I don't want any possible edge cases. I wanted to fully isolate them. If one platform was compromised; that would be bad news for a subset of users, but not all users.

If the maker of an application wants to trust some obscure platform as their OAuth provider; they're welcome to. In fact, I allow people running their own KeyCloak instances as provider to do their own OAuth so it's actually a realistic scenario.

This is why I used the hash approach; I have full control over the username on my platform.

[EDIT] I forgot to mention I incorporate the issuer's sub in addition to their username to produce a username with a hash which I use as my username. The key point I wanted to get across here is don't trust one provider with accounts created via a different provider.

Proprietary techniques like this are usually a good indication you’re missing something. In this case it sounds like you are missing appropriate validation of the issuer and/or token itself.

I want to support OAuth2, not OpenID so I don't rely on a JWT; I call the issuer's endpoint directly from my backend using their official domain name over HTTPS. I use the sub field to avoid re-allocation of usernames/emails but my point is that I don't trust it on its own; I couple it with the provider ID.

To make it universal, I had to keep complexity minimal and focus on the most supported protocol which is plain OAuth2.

How does that work, when you add an OAuth app, the resulting tokens are specific to that app having a certain set of permissions?

It's not a new attack vector as in giving too many scopes (beyond the usual "get personal details").

I am curious how this external OAuth app managed to move through the systems laterally.

See the commit message: https://github.com/torvalds/linux/commit/78d979db6cef557c171...

RAM producers aren't adding more capacity on the non-HBM side of things, so we shouldn't see a dramatic drop in pricing if AI HBM memory demand drops.

If we end up with metric tons of unused HBM memory lying around, I'm sure that someone will design a general purpose computer using them, or design a HBM-to-DDR interface.

Probably AI in the sense of what Google DeepMind has been up to with the protein folding and other biological simulations, instead of the LLM variant of AI.