This links to some other blog post for the bulk of it's 'why', and that blog post mostly seems to be annoyed about "You cannot invalidate individual JWT tokens". Which every time I've implemented, the general guideline is to check for invalidated nonces somewhere. Which resolves that random blog posts second point too.
>The JWT specification itself is not trusted by security experts.
This feels like it needs more evidence than just one blog post. And that blog post seems to just largely blame bad implementations? Something that will plague any standard.
Overall, I don't know what I expected clicking a random gist link.
Yeah... some early implementations just allowed for any authority to be set in the header and trusted it... that's of course wrong from the start... if you only allow for trusted or "known" authorities a lot of the contextual concerns become non-concerns.
Beyond this, you can make shorter lived JWTs just fine in the browser and have the agents self-update. If you use Azure Entra or a number of other providers it works this way in practice... you keep your JWTs relatively short lived (5-15m) and can even check for jti revokation.
JWTs are incredibly useful for separating/reusing an access authority from your applications/api systems. You shift the attack surface and do it in a way that can be trusted. We use PPK for lots of things, including SSH all over the world. No, I wouldn't use shared secrets and I wouldn't use long lived tokens... but short lived, ppk signed tokens from verified/known sources are generally fine.
For that matter, it's often API keys that are really problematic. Just had to implement them... for me, the API key presents as a Bearer token as well, but there's a short "sak." prefix then an identity part (base64url uuid bytes) followed by a secret as base64url bytes... in the database is the uuid and a passphrase level salt+hash from the secret.. so the api key generated should be treated as a secret and is one-way to the database, so a db breach doesn't breach auth.
Even then, an API key leak is far mroe likely than a problem with a well implemented JWT solution.
Also many situations just don't require a "Logout" button and hence don't require a revoked list.
On a linked page, there's also this:
> Any JavaScript code on your page can access local storage: it has no data protection whatsoever. This is the big one for security reasons (as well as my number one pet peeve in recent years).
This is a weak argument. You know, just don't put "any javascript code" on your webpage? Limit it to trusted javascript code? If you allow random people putting random javascript on your webpage, you have already lost anyway!
Right, but once you're checking for invalid nonces, your token format is now stateful; it's lost the primary benefit of statelessness, which is continuing to function under network partition between the application server and the token state store.
> "You cannot invalidate individual JWT tokens". Which every time I've implemented, the general guideline is to check for invalidated nonces somewhere. Which resolves that random blog posts second point too.
100% agree. This is common sense to me and I'm always surprised to re-learn people don't do this
Even worse than both of those scenarios. If you don't check the signature anyone can simply write whatever they want in the payload string. The signature is always generated by combining the payload with a private key. Then the receiver uses the public key to verify the signature. If you don't do that the payload can be modified to be anything. Storage not required by the attacker.
It's like prompting for a password but accepting any password as valid.
Wallpaper Engine is pretty old now, and I remember using it years ago reading warning about not downloading unknown wallpapers. I believe there's even settings in the configuration not to run arbitrary code. 8 year old post about it, but honestly pretty sure it's been warned since day 1. [1]
I presume he's exhilarated that the government is taking the threat seriously and banning foreign nationals from accessing these super dangerous tools.
Someone disagreeing with you doesn't make it reddit.
Two days ago Antheopic's CEO made a lengthy post calling for most government oversight on AI. He even mentions support export controls, even though he wanted them applied only to chops [1].
Anthropic literally asked for this, though they might have hoped it wouldn't be used against themselves.
You didn't read your own link. He called for a transparent testing process prior to releasing frontier LLMs into the wild. Export controls on chips to slow down China, which makes sense if you believe that chips are the way to superintelligence and the PRC will not be the best steward of it.
Unless the courts here made the ruling incredibly narrow somehow (only referencing search engines maybe?), how does this not just ban AI in Germany overnight?
Every AI model can make something up sometimes. Over millions of daily calls, it's essentially impossible for the technology to be guaranteed correct 100% of the time.
I thought locking down H1Bs actually had bipartisan support?
How can you argue there aren't enough jobs, and support H1Bs to fill jobs?
I can see Alaska's case since encouraging people to move there very well may be a requirement, but surely there's somewhere between $0 and $100k that would convince someone to move there.
You’re putting words in people’s mouths. The fact that people oppose this solution doesn’t mean they disagree with the problem. We oppose it because it’s stupid; it’s the first solution that a dim-witted eight-year-old would’ve come up with.
The program needs to be reformed so it only applies to people with skills that genuinely cannot be found domestically.
Given the difference in expected engineering salaries for many citizens/permanent residents and foreigners/temporary residents, $100,000 is not an effective way of making that happen.
If people that think like you had actually done something about it, then we wouldn’t be to this point. But at this point the only people taking action are trumps, and if that’s the only solution being offered, it will be taken. The conversation here is mild, get the room temp on this issue outside of lib tech circles and you’ll see
So after 4 years, or whenever this con man finally has the decency to keel over, is everyone who supported these performative non-solutions simply to "be heard" (or however else they frame their emotional release) going to own up to the fact that they've burnt all the political capital on the issues they care about? Or are they going to blame their predictable failures on "libuhruls" and go right back to whinging while waiting for the next con man who might pay them lip service?
>Total repair costs, he estimates, are somewhere between $70,000 and $100,000
This is always so depressing to read, especially when you realize the thief did the damage only to gain a couple hundred dollars in copper. It's just a massive net loss for society to deal with this.
It's a similar problem places have with people destroying ac units to steal some small amount of copper.
Theft is always bad, but this blatant net negative for the world theft is the kind of thing that makes you wonder about societies long term.
>The JWT specification itself is not trusted by security experts.
This feels like it needs more evidence than just one blog post. And that blog post seems to just largely blame bad implementations? Something that will plague any standard.
Overall, I don't know what I expected clicking a random gist link.
reply