unscaled

8 ms·

31.
by unscaled 4mo ago
The main reason I don't like the id token is that I've seen way too many instances of the ID token being used as a trusted identity assertion sent across multiple services or to third parties. This is very dangerous, since ID toke
32.
by unscaled 4mo ago
The OP was talking about sessions (which include session cookies and API tokens). I'd argue these use cases are far more common for the average programmer than tokens and signatures that are used for federation, but I'll bite the
33.
by unscaled 4mo ago
PASETO and TLS 1.3 were also written by humans. TLS libraries (which are several orders of magnitude more complicated than JWT libraries) are also written by humans. If you passionately care about security and misuse-resistance you CAN writ
34.
by unscaled 4mo ago
If memory serves me right, cookies were designed by Netscape in 1994 before JavaScript was even a thing. They were released in an early beta of Netscape (0.9 something), while Javascript was only added in Netscape 2.0. SSL 2.0 was only adde
35.
by unscaled 4mo ago
Wow, Fortune 500 companies are using an insecure technology, get hacked and exploited by cryptominers and PII burglars and then just patch their vulnerabilities and call it a day? This never happened before! /sarcasm Just because a cer
36.
by unscaled 4mo ago
A non-exhuastive list of CVEs from this year alone: CVE-2026-28802, CVE-2026-29000, CVE-2026-1529, CVE-2026-22817/8, CVE-2026-34950, CVE-2026-23993, CVE-2026-32597. Most of them are the same classic alg=none, signature verification byp
37.
by unscaled 4mo ago
JWT libraries had poor defaults because the spec was poorly designed. Of course JWT can be implemented securely. Even XMLDSig can be implemented securely. But if the spec is not designed with security and misuse-resistance as a tier 1 prior
38.
by unscaled 4mo ago
I think both you and GP are somewhat misrepresenting the OP is saying. OP's argument is three-fold: 1. JWTs are not a good fit for a session token (although there are several RFCs that are trying to shoe-horn JWTs into this use). >
39.
by unscaled 4mo ago
Ok, I think I misunderstood you. Lightweight policing, not policy. I guess this happens in the US, but in most countries cops wouldn't stop you for a traffic violation with a gun in their hand. In some countries (e.g. the UK) the polic
40.
by unscaled 4mo ago
That's interesting. I didn't know any other country in East Asia that showed this level of restrictive policy that sets up a cascade of problematic tooling and technologies. Japanese Internet was pretty bad in the 2010s, but this
41.
by unscaled 4mo ago
I don't think it's a dystopia. Hanlon's razor still applies. But I beg to differ on your classification of North Korean policies as "lightweight". Korean internet policies usually mandate a very specific technology
42.
by unscaled 4mo ago
This sounds to me like a repeat of what happened with SEED[1]. The recipe is the same: a real problem followed by a hasty (and probably inferior) NIH solution, a single implementation forced down everybody's throats followed by years o
43.
by unscaled 5mo ago
> It's not "JWT is broken". The cryptography is fine. The tymondesigns/jwt-auth package is fine. The concept of using JWT as your app's session is what's broken. If only that was true. JWT came with a lot of
44.
by unscaled 5mo ago
OP mentions backward compatibility and popular YAML libraries as the reason why the "Norway problem" is still an issue, but I'm a little bit doubtful about this explanation. It's been 10 years, if not more, since I'
45.
by unscaled 6mo ago
LDAP might have won over DAP, but it's still heavily based on the X.500-family of standards. Unlike SMTP (which is a completely different standard), LDAP is strongly based on DAP and other X.500 family standards. Besides LDAP and X.509
46.
by unscaled 6mo ago
Unlike many other developed countries, foreign employees working in cleaning and maintenance are still a minority. This is gradually changing, but I believe the main issue is that young people are completely uninterested in this kind of wor
47.
by unscaled 6mo ago
And this makes the entire application server and Servlet model the wrong abstraction. Microprofile simplifies things, but in the end I feel Java EE is just pushing the wrong abstractions here. Cloud native microservices are meant to be smal
48.
by unscaled 6mo ago
I remember all the excitement about Spring Cloud... But that was back in 2017. I never thought of Spring (or Spring Boot) as good technology, but even for the right audience Spring boot is as exciting as React is exciting for frontend devel
49.
by unscaled 8mo ago
You probably had a CoE (Certificate of Eligibility to Reside in Japan, 在留資格認定証明書). This piece of paper needs to be taken to your local embassy or consulate and be converted to a visa there, which then gets stamped on your passport. But Japa
50.
by unscaled 9mo ago
Oh, Yes. Windows 10 had big issues on arrival. But this is also selective Amnesia. The Windows 8 UI was nearly unusable on release. Windows Vista was so legendarily broken on release, that even after it became stable, the majority of techni
51.
by unscaled 9mo ago
SGML was designed for documents, and it can be written by hand (or by a machine). HTML (another descendant of SGML) is in fact written by hand regularly. When you're using SGML descendants for what they were meant for (documents) they&
52.
by unscaled 9mo ago
> JSON has no such mechanism built into the format. Yes, JSON Schema exists, but it is an afterthought, a third-party addition that never achieved universal adoption. This really seems like it's written by someone who _did not_ use
53.
by unscaled 9mo ago
You must have been very lucky. Every SOAP service I had the (dis)pleasure to integrate with was a wholly different nightmare-ish can of worms. Even when we get to the very binding of WSDL, there are way too many variations on SOAP: RPC-Enco
54.
by unscaled 10mo ago
It was a cleartext signature, not a detached signature. Edit: even better. It was both. There is a signature type confusion attack going on here. I still didn't watch the entire thing, but it seems that unlike gpg, they do have to spec
55.
by unscaled 10mo ago
I don't think it's stupid and this is one of the reason I prefer ULIDs or something like it. These IDs are very important for diagnostics, and making them easily selectable is a good goal in my book.
56.
by unscaled 10mo ago
The monotonic behavior is not the default, but I would also be happier if it was removed from the spec or at least marked with all the appropriate warning signs on all the libraries implementing it. But I don't think UUIDv7 solves the
57.
by unscaled 10mo ago
Let's revisit the original article[1]. It was not about arguments, but about the pain of writing callbacks and even async/await compared to writing the same code in Go. It had 5 well-defined claims about languages with colored fun
58.
by unscaled 11mo ago
Rust has concurrency issues for sure. Deadlocks are still a problem, as is lock poisoning, and sometimes dealing with the borrow checker in async/await contexts is very troublesome. Rust is great at many things, but safe Rust only elim
59.
by unscaled 11mo ago
Runtime borrow checking panics if you use the non-try version, and if you're careful enough to use try_borrow() you don't even have to panic. Unlike Go, this can never result in a data race. If you're using unsafe blocks you
60.
by unscaled 11mo ago
I think the original sin of Go is that it neither allows marking fields or entire structs as immutable (like Rust does) nor does it encourage the use of builder pattern in its standard library (like modern Java does). If, let's say, ht

More ›