jub0bs

"Stateless" does not seem as strong as "pure", and purity is what I'm after. What about an iterator that maintains no state but prints to the screen? You could describe it as a "stateless", but not as "pure".

Ok, that is annoying. I hope it gets fixed soon.

Your post does show that iterators are somewhat of a leaky abstraction, but I'm not sure I would go as far as calling some of their infelicities "bugs". Whether those infelicities matter in practice is a moot point.

Instead of recovering from what clearly is a bug, why not fix that bug instead?

There are even panics that are intended as irrecoverable: https://cs.opensource.google/go/x/sync/+/refs/tags/v0.12.0:s...

I don't think any reasonable member of the Go community would claim that any aspect of the language and its standard library is perfect. The many open issues on https://github.com/golang/go attest to that.

One example, if I may: the errors.As function is far from ergonomic. It would have been much better if generics had come to the language before that function was added to the standard library. Modern alternatives exist: https://pkg.go.dev/github.com/jub0bs/errutil

One data point showing that Pike's views can be and sometimes are controverted: https://www.youtube.com/watch?v=5uM6z7RnReE&t=18m

actually they always intended to have generics

There was a time when generics were not even on the table. I'm pretty sure I remember an old talk by Rob Pike where he says that much.

People can change their mind as they learn more about the problem space; that should be tolerable.

You cannot use `Access-Control-Allow-Origin: *` indiscriminately, though. In some cases, it can be dangerous: https://security.stackexchange.com/questions/227779/concrete...

I’ve just released jub0bs/cors, a new CORS middleware library for Go, perhaps the best one yet. It has some advantages over the more popular rs/cors library, including a simpler API, better documentation, extensive configuration validation, a useful debug mode, stronger performance guarantees.

Functional options is a creational pattern that remains divisive in the Go community: loved by some, loathed by others. However, the pattern can tremendously improve a library’s API design. Throw in a few twists and unleash the full power of functional options on your Go libraries! (Talk given by Julien Cretel at GopherCon Europe 2023)

Thanks for the kind words!

In this post, I investigate why developers struggle with CORS and I derive Fearless CORS, a design philosophy for better CORS middleware libraries.

I hoped the TL;DR item entitled "SameSite paints a target on your subdomains' back" would be enough to compel readers to get through the whole post... But I understand your criticism; the post is quite long...

By the way, one of the takeaways in the post is that even SameSite=Strict is powerless against (cross-origin) same-site attacks. I would certainly recommend using Strict wherever possible and practical, but Strict shouldn't be misconstrued as a drop-in replacement for anti-CSRF tokens.

Thanks. Yes, that's a good point. The difficulty for me in writing the post was not to spoil how origin and site intersect too early. ¯\_(ツ)_/¯

AFAIK, there is no proposal to add a type of DNS record that would allow you to do that. And I don't think that this type of configuration should be done at the DNS level rather that at the HTTP one.

You'll find an answer in https://web.dev/same-site-same-origin/:

[...] for domains such as .co.jp or .github.io, just using the TLD of .jp or .io is not granular enough to identify the "site". And there is no way to algorithmically determine the level of registrable domains for a particular TLD. That's why a list of "effective TLDs"(eTLDs) was created.

If foo.github.io and bar.github.io were considered same-site, one subdomain could mount cross-origin same-site attacks against the other. I'm guessing that's why companies that have multiple tenants on the same domain (github.io, in this case) ask that the domain be added to the public-suffix list: for isolation purposes. Other examples of public suffixes are azurewebsites.net (Azure App Services) and repl.co (Repl.it).

Apologies about that. There is a TL;DR and an estimated reading time at the top, though. You can also skip the addendum.

You'd be surprised by how many organizations completely disregard the security of their non-essential subdomains. The point of my post is that one subdomain takeover (or some XSS or some HTML injection) on a different subdomain of the same site is enough to bypass the protection that SameSite provides to the origin of interest. And I feel that is something worth understanding well.

Hey! I don't usually hang out on Hacker News. Thanks for sharing the post here :)

Sorry! I like the dark theme the way it is, I'm afraid. Have you tried the light one?