2,303 karma · joined July 25, 2018
It's quite interesting how quality of life gets inverted in non intuitive ways. If you travel to a "developing country" you notice you are no longer bombarded with ads. Watching YouTube is close to the premium experience, bc the country presents no ad revenue to Google. You then travel to a "developed" country and you can't watch a 5 minute video without watching 2 ads.
Everything is a transaction, it is too easy to transact. People used to just write, to just make music. Sure, they need to eat, but they lie. You hear people that make insane amouns of money asking for a coffee. imho, writing is a thing you to to share knowledge, to have a conversation, to learn, etc. It is a way to also get people to know you better, and maybe learn about the things you do that they would want to pay for. So unless writing is your full time job, asking money for it leaves a bad taste.
I could be stretching, but to me, this is very conscious and intentional work, perfected through experience and there are many way to get it wrong. What exactly would we call this?
We need to stop redefining terms.
Isn't this conflating encryption with trust? Of course whoever claims to encrypt your data needs to be trustworthy, and whether they actually are is another matter, but If my app allows you to generate a client side key, export it and use it to encrypt data client side and we only get the encrypted data, that is verifiably valid encryption.
I could be malicious and also send a copy of your actual plaintext to the server as well, but that is trivial to check (unless I'm being targeted and I am the only user that gets the malicious code, still, I can check). It's a risky proposition for an organization with vested interest in being seen as pro privacy.
But I get it, different conversation if the government coerces you, and the outcome depends on your bank account and ability to handle pressure.
It all seems to behave correctly and then you run your test suite, and your e2e tests start failing in weirs ways, a few but not many accounting discrepancies, and everything else passes. You spend a lot of time asking it to explain what's happening, you give it the data to browse, and it keeps giving you very plausible explanations of "found the issue, the data shows this clearly, there fore the bug is here, all I need to do is fix this thing", and it does this, and it still fails.
When you open the hood, man, the code salad, the 100s of unnecessary, and complex and duplicate abstractions, the stacked mistakes and lazy corrective attempts, the comment pollution that overrides your instructions across sessions.
You realize that there are things and concepts that it just cannot wrap it's "mind" around and you need to grab the wheel for a bit, make the corrections, remove all the comment litter, commit and then hand the wheel back and tell it to "look at the last commit so see what I mean. explain to me what you did wrong and update all documentation, memory and context with this new understanding".
So if you have no experience in the field, you won't even know how to test, how to find that there is an issue, the appearance of "working" and the AI's confidence will trip you in prod so hard.
The tiniest feature becomes a chess game with unpredictable interactions, not enough tests, etc.
You’ll notice this when you get fed up from going in circles, go peek under the hood and notice it’s been trying to implement your changes while preserving the comments it left before. You’ll even notice it adds to those comments and the code starts creating weird complex branches and abstractions and remains incorrect.
I am now telling it to not leave any comments in the code, but make the code itself be self documenting and clear. No comments.
But if we go with that, and downgrade it to somewhat stateless, I think it maintains it's value proposition well, since I have not seen many JWT applications be fully stateless, especially wrt authorization. So I took advantage of that and bolted this so you can use in during your existing authz flow. So pushing to later does not mean let's pull user data later (that does not change the cost). I mean do it when you have the data so you don't have to pull it just for this.
2. Secrets are encrypted at rest, you decrypt them in memory. Of course, if your app encryption key leaks someone can decrypt all those secrets, but this is an attack surface that already exists. Not trying to address that. Also, each user has their own secret, so you have one app level signing key, and N user signing keys, you need to leak all those and then get the app encryption key to decrypt all of them.
"Compared to a stateful session system with split-tokens" - sure, let me just tell every company that is using JWTs to migrate immediately to stateful session tokens. One sec...done, tomorrow will be a better day for all of us :-)
In all seriousness, I posted this a while ago asking for feedback, HN seemed more interested in AI than actual meaningful conversations. I appreciate the feedback and will update the description and make the examples more clear. The intention there was to compress as much as possible and letting readers implement their use of it where it matched their existing setups.
Regarding your link, I took a quick look (saw it a few years ago, forgot about it), but seems I inadvertently built option 6 "Rotate a user scoped signing key lazily, during authz, on pre validated tokens". This is fundamentally different has a new security and usability posture. And it's still not a session token as it keeps all JWT properties that people are using it for (I make no judgement of whether it's the best solution for them, only that they're using it).
Thanks for the feedback, there is room to improve there.
I have been using this for a while, and I haven't managed a revocation list, I haven't done user queries at the boundary and users are able to logout and instantly invalidate their JWT. I honestly haven't seen this elsewhere without overhead.
Or if you are doing inter service communication, you can use your app secret to validate that the token can actually cross your infra boundary (no user query here), and each internal service can then validate it in their scope, or if a passthrough (like a proxy), just forward it like an envelope.
What this does is give you 2 secure layers, therefore saving you from a lot of the compute (drop expired and globally invalid tokens at the boundary), kill db round trips meant only for token validation (attach to an existing user query you already do) and kill revocation list management.
Storing a user's secret, the same way you store your applications secret does not make it more or less stateless.
In since you now have 2 layers of protection, you don't actually need to verify agains a user's secret immediately, you simply need to check that the token is valid using the app secret. The subset of valid tokens that you need to check is much smaller than the universe of all the unexpired tokens your application has issued.
If you have a security incident and need to revoke tokens for only a subset of your users, now you don't need to rotate your app secret and invalidate every single token and break every single session. You can simply log those users out.
Is author's brain stateless -- my bad, I thought this was not reddit
Why not an epoch? because this gives control to the user. They can now logout regardless of token ttl. The point is not obsessing over crypto, JWTs are a cryptographic solution, it's what makes them stateless and I have nothing agains cookies or any other session token. I use them interchangeably.
My pain point was that whenever I needed to use a JWT or whenever I worked a company that used JWTs, their main frustration was "oh but then we can't revoke them easily without maintaining a revocation list". Well now they don't have to.
Telling them just migrate to "this or that technology" is not how this works.
Human powered proof of humanity. Nothing on chain, no blockchains. Just DNS / SSL like decentralization. V0 is admittedly less decentralized as a POC (I control the registry and provider), but anyone can implement the protocol and make this truly decentralized.
Registry (even the current one) is meant to be government by multiple independent entities.
Shared before, didn't get much feedback. I've used AI extensively but very thoughtfully. This is very much not vibe coded.
The ecosystem includes 3 apps:
https://humanidentity.io: people signup and get verified here
https://app.humanidentity.io: platforms signup here and manage their oauth
https://protocol.humanidentity.io: documentation, meant to be operated by a governance body
https://platform.humanidentity.io: example platform. You can signup in https://humanidentity.io and then login via oauth here