True. I'm French native but my English is better (educated in Australia) so this created a weird situation for me where I got 14/20 for advanced words and 19/20 for expert words.
To be fair, I think I messed up a few advanced words by accident but I think the general pattern would hold because many of the expert level words seemed to have French root. So it felt like it got easier towards the end for me. Grandmaster words were a bit weirder on the whole.
I'm an engineer and read mostly non-fiction so this probably explains the gap too.
I'm in Australia and I have view on a mountain so I see too many trees to count. Proximity to a forest was top priority for me and my wife.
Having lived in Europe for many years before, this is something that's most striking about Australia. I live in a state with one of the highest population densities and yet it still feels very sparsely populated relatively speaking.
Leaving a trace is something I've been grappling with which seemed incredibly straight forward initially as an open source developer.
These days, I find myself questioning for whom am I leaving a trace for? What kinds of humans or entities? Do I care about the kinds of entities who will inhabit the future? Or will their value system be so different to my own that I'd prefer not to have anything to do with them.
Beyond human nature itself, I take issue with the trend of how human nature seems to be changing over time; for the worse.
I actually use this line of reasoning to motivate and inspire some of my own art and cultural artifacts. When a far future galactic civilization pauses to ask, “who are we and where did we come from“, they might just look back at the ledger of humanity’s written outputs. In this sense, the entire trace we manage to save to disk could be viewed as a body of work were any of it to survive. Even pieces of work that nobody reads today could have a long line of future audiences and help shape the galaxy’s understanding of its cultural heritage. (These future entities might have far more processing power and bandwidth to spend on the analysis of our work).
This is how I used to see it. It made my work feel special just knowing that other people would use it and appreciate it.
I think because I felt a stronger sense that other people were my kin.
Now I feel like I don't belong, I feel that I am different and I don't know how to interpret other people's appreciation because they probably don't feel it the way I do when I appreciate something. I feel more exploited than appreciated.
Part of me is wondering if some people who used my open source projects thought to themselves "What a sucker... Working for free so I can monetize his work." And getting some kick out of that. There's a fundamental difference of values there. It didn't occur to me that this is the lens through which a lot of people view the world.
To me, true altruism is selfish. If helping people makes you feel good, then you're an altruist.
If helping others doesn't make you feel good innately but you do it all for others then I think there is some self-deception at play. Maybe it's a status or self-image thing? Because being an altruist is higher status and you want to see yourself as high status? I think you can always trace it back to a selfish motive at some level.
Denying the selfish root of altruism can lead to hypocrisy because there is a dissonance between who the individual really is in their natural state and who they want to believe themselves to be. They have to constantly work to be who they aspire to be; it's not second nature to them and they will frequently fall short whenever it slips their mind or when they occasionally give in to natural impulses. Good on them for trying I guess. Better than not trying at all. But they're not an altruist.
I believe Richard Dawkins' "The Selfish Gene" backs me up on this point. Altruism is a either a kin-selection process or a reciprocal (transactional) process.
> I find myself questioning for whom am I leaving a trace for? What kinds of humans or entities?
How's your reasoning there? You only want to be nice to people who have earned it? This sounds a bit too close to the "you have to EARN my respect", which is a hallmark of somebody nobody wants to be around.
You can only control your own actions. If your "good deeds" are conditional or transactional, then that very much diminishes their goodness.
You're right. I have certain values and I'm OK if others expect certain values from me. To me this is ideal. Friendships should not be based on superficial things like money or social status to the point that you have to constantly change yourself over time to maintain alignment.
If you pay attention, you will notice that this is how the vast majority of people operate.
To me, that's transactional. Having fixed core values and expecting other people to share certain core values is not transactional, it's genuine. These are the kinds of relationships which don't require constant maintenance; you can not talk with the person for years and then resume the friendship like no time has passed, no matter how your situations have changed. If you can change your values based on the latest social trends, then you have no values. The friendship is held together by mutual material benefits; that's transactional.
I have no genuine interest in being friends with people who don't have core values. Because then I'd know I'm only in it for the money, and that's a lot of work and stress for me. Maybe second nature to some people. But I'm no good actor. To me it's work.
My view of humanity is most people are actors and most people lie to themselves constantly.
If they had kept their distance, they probably wouldn't exist today. The dependency on government has been critical for any tech company. They'd have been replaced by a different company that is willing to cater to the government's every whim.
That said, the founders of these companies could have lobbied the government to ban corporate lobbying.
It's like; if there's gov money on the table, then it'd be a mistake to let your competitor take it. However, if you ensure that government money is never on the table for anyone, then that's one less thing for everyone to have to compete over and throw money at. Everyone can save their money for other things.
The government should never have allowed political lobbying to become a competitive market.
Also, political campaigns should not be allowed to raise private funds. That is insane. The government should fund all candidates' campaigns and allocate equal funding. Candidates shouldn't be allowed to spend their own money on their own campaign either IMO.
In any case, the landing page needs to be perfect. Anything less and you have 0 chance.
The most important innovation is in sales and marketing.
If you don't have brand recognition, your landing page has to make up for that. Making up the difference seems to be getting more difficult with each passing year. People are extremely cautious and getting increasingly so.
The average B2B user nowadays is literally triggered by anything remotely unfamiliar.
I've never been enticed by a landing page (yes, datapoint of one). It's either recommendation from source I trust (which has included reddit) and some demo/review available somewhere. Never the landing page as they usually took too much scrolling to get to the point.[0].
Better host a quick video demo/video add instead of drowning the user in copywriting.
The landing page is the worst place to get in touch with the reality of the product. Take a STEAM store page, it says nothing interesting about the game, doesn’t even has a gameplay video. Much better to just get to know the product with real people with real stories to tell, then the landing page is just the last place you go to acquire it. I never understood people who actually reads marketing copy and goes “hmm interesting”, it’s so vacuous and boring.
Claude trying to organize and collaborate, expecting reciprocity only works if other agents are as intelligent as you and share your values... And almost certainly neither is ever true in the real world where there are so many agents.
Another point is that managing session data on the server-side is a pain... If your app server goes down, stale session data would be left behind in your session store; it can easily become orphaned... So you need to set an expiry on it to ensure that it will be cleaned up no matter what... But you need to keep extending the expiry while the user is still online. God forbid you create the session data before you set the expiry on it and the operation that sets the expiry fails (e.g. server crashes at the precise moment or some error occurs which causes it to be skipped)... In practice, it's hard to avoid stale/orphaned session data.
And yes, you need to store and manage more data and your session store is an additional Single Point of Failure... With JWT the revocation list is an optional... Your system can keep running without it; it just won't be able to ban users. It's a cleaner separation of concerns without SPoF.
JWTs have so many benefits over session IDs, I could write a book about all the benefits. Sure, there are some tradeoffs but the negatives are typically pretty minor or hand-wavy.
> Another point is that managing session data on the server-side is a pain... If your app server goes down, stale session data would be left behind in your session store; it can easily become orphaned... So you need to set an expiry on it to ensure that it will be cleaned up no matter what... But you need to keep extending the expiry while the user is still online. God forbid you create the session data before you set the expiry on it and the operation that sets the expiry fails (e.g. server crashes at the precise moment or some error occurs which causes it to be skipped)... In practice, it's hard to avoid stale/orphaned session data.
Tell me you haven’t been writing web apps for a long time without telling me. There are many ways to solve the problems you describe here, which have been put into widespread use by web frameworks serving literally billions of users stretching back decades. Why reinvent the wheel with something that wasn’t designed to be a long-lived session store in the first place?
I think the Rails default is quite clever (the entire session lives in a cookie on the client), which gets around most of the problems you specify. But there are many other approaches if that doesn’t work for your use case.
My point and previous commenter's point was more about managing the session data, not the session ID itself.
You're right that now it seems a lot of these session stores like Redis have improved. It seems they now enforce TTL and even provide sliding TTL on read. I haven't touched on this feature in a while but it used to be a major pain before.
These niceties add overhead behind the scenes but manageable... But IMO, it still falls short of the simplicity of just checking a JWT signature. In many situations, the revocation list would be relatively short compared to the number of sessions; it's a lot easier to manage... Also, critically, it's not a Single Point of Failure because the system will keep servicing users even if the revocation list is down... It just won't be able to ban users until it comes back up. This is usually a lesser concern.
> My point and previous commenter's point was more about managing the session data, not the session ID itself.
Yes, I understood that clearly, and it seems that maybe you didn’t understand my post.
In Rails, by default, the session data itself (not an ID) lives entirely in a cookie. No server-side session management logic of any kind is enabled or necessary.
Are there situations where this isn’t the right fit? Of course. But this is one of many solutions that have been in place for decades that don’t involve using a token that is intended for short-lived and/or one-time claims.
Edit: I had a vague memory of having a very similar conversation before on HN, and it turns out it was with you. Feel free to re-read if you’d like a little more context into why I think you’re using JWTs in a way that is, at minimum, not what they were designed for:
I wasn't familiar with the RoR implementation. We may have been talking past each other. I'm thinking about it from an access control PoV.
There are alternatives to JWT which work on the same principle but personally I haven't found any reason to move off a well established and popular format to some unknown format whose drawbacks aren't as well understood or which limits interoperability.
I checked with Claude. It seems that RoR's default is in fact its own custom implementation of a similar mechanism but with encryption instead of just signatures. This is a good approach if you want to store secret data in the session but personally I only store non-sensitive info and I prefer using JWT HS256 which is fast/cheap compared to full encryption. I try to keep my signed data light, especially if it has to be sent over the wire frequently.
I find the JWT approach more minimalist; it's only for determining account ID and privilege level, nothing else and it doesn't have to be secret. I feel like storing anything more than the bare minimum required to determine access to resources is overkill.
> There are alternatives to JWT which work on the same principle
My general position is that JWTs are not well-suited or designed for web app session management, full stop. There are direct alternatives to JWTs like PASETO and Macaroons, and I don't think those are suited for session management either (though in general they are better designed from a security and simplicity perspective).
> RoR's default is in fact its own custom implementation of a similar mechanism but with encryption instead of just signatures
That's pretty much correct, with the caveat that you don't need to add a bunch of machinery with footguns galore on the frontend and backend just to be able to parse them. And as I pointed out in our last discussion, this has been the default session storage mechanism in Rails since years before JWTs existed.
> I prefer using JWT HS256 which is fast/cheap compared to full encryption
This feels like like bike-shedding for all but the largest of apps.
> I try to keep my signed data light, especially if it has to be sent over the wire frequently.
Yes, this is a recommendation for Rails' default session mechanism as well, since most browsers impose a fairly small size limit on cookies (4KiB IIRC).
> I find the JWT approach more minimalist; it's only for determining account ID and privilege level, nothing else and it doesn't have to be secret. I feel like storing anything more than the bare minimum required to determine access to resources is overkill.
There are a lot of other use cases for session data, especially if you're using a full-stack web framework vs. a SPA with a separate backend (I have strong opinions on this as well, but that's a different discussion). For example, Rails has the concept of a "flash" where you can display temporary, ephemeral messages to the user. These are stored in the session, consumed on the next request the browser makes, and then removed.
Exactly, it's like saying that Postgres is insecure because it allows SQL injection attacks when untrusted user input is injected into the query directly.
Not really. Being able to verify a user's signed identity immediately without having to do any database or memory store lookup first is valuable in itself.
With session IDs, anyone can spam/DDoS your system much more easily; they don't even need to be authenticated to waste your computing resources as they can send plausible-looking session IDs and your system will waste a ton of resources querying your session store or database to figure out that the session doesn't exist... It adds a ton of latency and wastes CPU cycles across multiple systems. Also stateful systems like Redis are harder and more expensive to scale than stateless systems like application servers. Not to mention that they may be depended upon by other parts of the application so hitting those too hard can be more disruptive. And that's kind of best-case. Some people use a database to store their session data...
At least with a revocation list with JWT. If the JWT says that the user is user1234, then you know that this is a real, previously logged-in user, they have an account at stake, you can afford to spend a bit of time/resources to check them against your revocation list... And if they are on that list, you can ban their ass and they're done! They'd have to create a new account of they try to spam you again. They can't spam without a valid JWT and they can only get that by authenticating with your server first.
Sure with JWT, some computation is spent on verifying the signature but it's very cheap using the default algorithm and only touches one system... And you only need to call another system once you know that the user is valid.
JWT is much more robust for DDoS prevention because of this. But yeah, you don't necessarily need a revocation list. You can use short JWT expiries with frequent token refreshes. Revocation list is good if you need immediate ban.
Yes but it only impacts your stateless app servers which are easier to scale. Your backend services/stores are protected and not affected by the attack.
To be fair, I think I messed up a few advanced words by accident but I think the general pattern would hold because many of the expert level words seemed to have French root. So it felt like it got easier towards the end for me. Grandmaster words were a bit weirder on the whole.
I'm an engineer and read mostly non-fiction so this probably explains the gap too.
reply