The only problem the author points out is that he doesn't like the Cantril Ladder question.
I get it if you feel like that question falls short of representing your own personal concept of happiness, but that question is the standard in positive psychology research for measuring self reported subjective well being, and hardly enough to say the report is "beset with methodological problems".
They give several well-considered criticisms of the question - it leads people to focus on socioecomonic status, it doesn't correlate with other measure like whether they report experiencing joy recently, etc. It's not much of a defense to simply say "well, it's the standard".
My criticism is about how the dramatic language differs from the banal content of the article.
Titling it "The World Happiness Report Is a Sham" and calling it "beset with methodological problems", I would expect some more serious scientific malpractices, like data fabrication, calculation errors, sampling problems, p-hacking, etc., not "I think there are some problems with this variable".
Disagree. Whether I'm entirely fabricating data that claims A by writing numbers into an Excel sheet, or whether I'm doing a survey that measures B and then claim it means A, isn't materially different in outcome. The outcomes are just as bad, and that's what people care about. Maybe you as a researcher care that the former is more immoral, but to everyone else it doesn't matter.
I think there's a difference in outcomes between fabricating data, and getting data that still remains validly gathered, but measures something subtly different.
And I think the general public can make meaning of that
difference and have a stake in both – in the same way that the general public knows that stock market values and economic security are different things, even though people still have a lot riding on retirement plans based on stock investments.
Is joy related to happiness, or are they two separate concepts? That depends on your cultural background and the languages you speak.
The World Happiness Report can be traced back to the UN General Assembly Resolution 65/309, which was proposed by Bhutan. Therefore the intended definition of happiness in this context is similar to the one in Bhutan's Gross National Happiness index.
The more practical problem is that the samples used in the Gallup World Poll are for largely unavoidable reasons small and not representative of entire country demographics; in particular respondents can skew richer and more educated than their national average in poorer countries.
> """
I'm strongly in favor of blocking post-install scripts by default. :+1:
This is a change that will have a painful adjustment period for our users, but I believe in ~1 year everyone will look back and be thankful we made it. It's nuts that a [pnpm|yarn|npm] install can run arbitrary code in the first place.
"""
There is actually a good reason not mentioned, not to name tools by their purpose:
- the purpose will change
Your "silicon-valley-bank-integrator" tool will eventually need to be updated to do something else.
Or your "login-page-config-service" tool may eventually do more than just logins.
Using gibberish or mythological names gives a nice memorable name that doesn't lead (or mislead) you to believe it does a particular thing which may or may not be correct anymore.
Also, being too precise and succinct about what the tool does ends up in a race for the name in competing implementations.
Project names should be unique enough to allow them becoming their Id,
- It allows to find the project.
- It allows the project to change, extend it's scope or narrow it.
Having an Id is really important, making that Id related to the project's original intention is nice, but secondary. (as long as it doesn't change enough that it becomes misleading).
"purpose will change" argument actually proves the opposite point. When a tool's scope expands beyond its name, the descriptive name tells you something went wrong. But even if so, if you have to rename "login-page-config-service" to "auth-config-service" it is not really a big deal, renaming will be much cheaper if you're renaming to descriptive names. Most importantly though, I wouldn't optimize to avoid renaming (happens once, maybe twice in a project's lifetime) by making discovery hard (happens every single time someone encounters the tool).
> renaming will be much cheaper if you're renaming to descriptive names
Idk, renaming things that shipped is a PITA.
Say you wanted to rename `fish` to `a-decent-shell`.
- Packages in all distros would need to be renamed.
- Configuration for all systems using/having fish would need to change.
- Scripts would need to change, from the shebang to the contents if necessary.
- Users would need to understand that they now need to search documentation using the new name.
- Documentation would need to be migrated to new domains, sed-replaced, and reviewed.
All this migration would require some synchronized, multi-step process across multiple distros and deployments.
> Say you wanted to rename `fish` to `a-decent-shell`
You just made my argument. Renaming is hard precisely because you shipped with the wrong name. That's why you should get it right from the start.
Every cost you listed [distro packages, configs, scripts, docs, domain] exists whether you rename to something descriptive OR another random word. The migration pain is identical. "Fish" → "decent-shell" costs the same as "fish" → "zephyr." My argument was that this renaming won't be necessary if you started by picking up the proper name at the first place, and it's very unlikely to have the need to rename it. We shouldn't be optimizing to avoid renaming. That's trading a rare maintenance event for permanent cognitive overhead.
> Renaming is hard precisely because you shipped with the wrong name. That's why you should get it right from the start.
No, it's just because the goddamn string Id appears in way too many places and you can't sed-replace the entire world at once. It doesn't matter if the string was cute, fancy, or you found it to be a good name.
A good reason to use arbitrary code names before assigning a more helpful name upon release of something deemed to now be generally usable, beyond developers with caveats.
I like this approach. Use a cute, fun, memorable name internally for stuff getting off the ground. Once it becomes user facing, the internal name becomes a fun note on Wikipedia and the world sees the actual calculated name.
> If you need a sequential ID, just use an integer
Are monotonic/sequential ULIDs as easily enumerated as integers? It's the ease of enumerability that keeps a lot of folks away from using sequential integers as IDs
Sorry, I'm not familiar with the ULID spec. You seem to be, hence my asking. Are you saying monotonic/sequential ULIDs are just (or just as easily enumerated as) Base32-encoded integers?
Oh and yeah, I guess I do think lots of script / AI kiddies would be discouraged by, or fail to see an opportunity when presented with, something that does not look like the numbers they saw in school.
That is a good point. Injection rates were higher with older population. I would say that younger immune systems are more robust, potentially leading to exaggerated inflammatory responses to spike protein, which could heighten neuro-inflammation and cognitive impacts.
Not much attention given at all to explaining what order in which these should be read or what optimality means. This is just a list of books some guy is proud to have read
Lists like these are almost always more accurately titled "How I wish I'd been taught X" and are aimed squarely at a student who has never really existed, one who simply learns whatever is put in front of them and can therefore be steered by a heavy stack of "the best" books away from all the mistakes and dead ends and frustrations that real students face. Real pedagogy's tougher than that!
It's "terrible" because the author can describe exactly one phishing vector?..
Have you ever tried resetting a password before? Passwords have a similar phishing vector, plus many other problems that magic links and one-time login codes don't have.
If six-digit login codes are less secure than passwords, the reasons why are certainly not found in this article.
> Visit our website. Create an account. Verify your email. Create a project. Add your credit card. Go to settings. Create an API key. Add it to your password manager. Drop it in your .env file. Download our SDK. Import it. Pass your env var in. Never share your API key. Make sure you never commit it to source control.
None of this "BS" actually goes away with self-signed JWTs, right? Just replace mentions of "API Key" with public/private key and it's otherwise a similar process I think.
1. With self-signed JWTs, you could start consuming APIs with free tiers immediately, without first visiting a site and signing up. (I could see this pattern getting traction as it helps remove friction, especially if you want to be able to ask an LLM to use some API).
2. Compare this scheme to something like the Firebase SDK, where there's a separate server-side "admin" sdk. With self-signed JWTs, you just move privileged op invocations to claims – consuming the API is identical whether from the client or server.
3. The authority model is flexible. As long as the logical owner of the resource being accessed is the one signing JWTs, you're good. A database service I'm working on embeds playgrounds into the docs site that use client-generated JWKs to access client-owned DB instances.
For web dev, where, sadly, it's the norm to have about 13 different services for a website, it would greatly simplify having to herd 13 API keys around
Yeah that's not happening. In fact most services with free tiers still ask for a credit card number, and if not still ask for a lot of information. It is a marketing scheme after all.
> you could start consuming APIs with free tiers immediately, without first visiting a site and signing up
I’m yet to see a website that provides an API and doesn’t have a ToS that you have to agree to. Unless you control both parties, or you expose your service only to pre-vetted customers, there is no legal department that is going to allow this.
you put as part of the claims in the jwt that you agree to the TOS (may be something like { ... TOS:www.service.com/tos.txt, TOSAgreed:true ... }), which you sign. Then this is an explicit agreement from you as a client.
Correct, because to fully leverage self-signed (or distributed or decentralized or whatever) JWTs you have to handle identity in a different way than typical consumer auth works on the Internet today.
Right now, user identity is ~based on email, which is in practice very often delegated to a third party like gmail, because most people do not host their own email. So identity = foo@bobsemailservice.cool. To properly validate self-signed JWTs you'd have to instead either host or delegate distinct JWKS endpoints for each identity. Then identity = https://bobsjwkshost.fun/foo. You still have to create and verify an account through a third party, otherwise, your self-signed JWT is just as credible as a self-signed TLS cert.
In both cases the underlying identity model is actually based on DNS, IP, and internet domains - whoever controls those for your email/JWKS controls what gets served by those addresses. So to fully self-host email or JWKS you need to own your own domain and point email/http to IP addresses or other domains. And you need to have something servery running under that IP to handle email/https. That's a big hurdle to setup as is, but even so, all this really does is kick up identity delegation one more notch to the IANA, who decide who owns what domains and IP addresses, by delegating them to registrars and regional Internet registries, with further delegation to AS to actually dole out IP addresses to proles.
I recently started the process of becoming a registrar and securing my own IP addresses and realized THERE ARE STILL MORE LAYERS. Now I have to pay a whole bunch of money and fill out paperwork to prove my business' legal legitimacy and get the stupid magic Internet numbers we call IP addresses. Which then relies on my country's legal and financial systems... And by the way, this part is just completely infeasible for a regular user to actually follow through with (costs are high five digits USD or low six digits USD, IIRC, takes a ton of time).
Because the IANA is a stodgy bureaucratic Important Institution That I Cannot Change, IMO the best way to implement self-hosted auth is by making it as cheap and simple as possible to register a domain and serve email/jwks on it. If we pay them even more money they'll give us a TLD which we should be able to make available for $0.20 (IANA base registration fee because of course) or just eat the cost and make it free pending some other verification process. And then we can set up a portable "serverless" JWKS/SMTP handling tool that people can run.
I've been thinking about this self-hosted identity/auth problem quite a lot and I think there's no ideal solution. If you're fully decentralized and trustless you're probably using "blockchain" and won't have enough throughput, will lock people out of everything online if they lose a key, and will still probably make consumers pay for it to stave off sybil attacks. Also, to use the internet you have to trust the IANA anyway. So just upgrade every authenticated user into their own identity provider and make it extremely cheap and easy to operate, and at long last you can get those precious seconds back by signing up for Internet services with a JWKS path instead of an email address.
> In both cases the underlying identity model is actually based on DNS, IP, and internet domains - whoever controls those for your email/JWKS controls
Hmm I wonder if you are thinking that the JSON webkeys of the user need to be hosted publicly. I don't think they technically do. It's a common convention to do so (especially at some well-known URL).
But the user actually could instead send their public key on each and every JWT-bearing request they send, and as long as that public key is both (1) pre-registered with the API owner and tied to some identity the API recognizes as some authorized user and (2) can successfully be used to validate the signature, it should work just fine.
How do you pre-register them then? What prevents someone else from trying to register or push my JWKS to the API owner? If you are in an open security context (eg the Internet) you would then still need another way to handle Identity
Exactly my complaint. You still have to go into some web portal and install your public key, I guess.
> What prevents someone else from trying to register or push my JWKS to the API owner?
Well for one thing they wouldn't have access to your public key since you won't be hosting them publicly somewhere. But for another thing it will be useless to them unless they have access to your private key
I get it if you feel like that question falls short of representing your own personal concept of happiness, but that question is the standard in positive psychology research for measuring self reported subjective well being, and hardly enough to say the report is "beset with methodological problems".
reply