It's not just understanding the codebase, it's also stylistic things, like "use this assert library to write tests", or "never write comments", or "use structured logging". It's just as useful --- more so even --- on fresh projects without much code.
Honestly, everything I have written in markdown files as AI context fodder is stuff that I write down for human contributors anyway. Or at least stuff I want to always write down, but maybe only halfway do. The difference now is it is actually being read, seemingly understood, and often followed!
Yeah I agree. I think the best place for all this lives in CONTRIBUTING.md which is already a standard-ish thing. I've started adding it even to my private projects that only I work on - when I have to come back in 3 or 4 months, I always appreciate it.
My current thought is that (human) contributors should be encouraged to `ln -s CONTRIBUTING.md CLAUDE.local.md` or whatever in their local checkout for their agent of choice, have that .gitignored, and all contributors (human and LLM) will read and write to the same file.
The "new" thing would be putting CONTRIBUTING.md into subfolders as appropriate - which could often be quite useful for humans anyway.
Yeah I think having a docs/contributing folder or equivalent, essentially referenced/linked in the CONTRIBUTING.md makes a bunch of sense, but I'd leave that kind of thing more or less up to the project
If there were already a universal convention on where to put that stuff, then probably the agents would have just looked there. But there's not, so it was necessary to invent one.
Reality is just that people neglected onboarding docs until LLM-based coding agents put them in a position to directly benefit from having more knowledge of the codebase explicitly written down.
You could get this page down to under 100 words by simply having it say "the name of the file LLM agents will look at for instructions on the repo is AGENTS.md; that's it, that's the standard".
It's a real problem! Every agent right now has their own weird filename. I love David Crawshaw's sketch.dev, but for reasons passing understanding they choose "dear_llm.md" for theirs.
Or, equivalently, to enable the largest number of customers to use the product, by decreasing prices for smaller customers and increasing them for large ones.
This pops up on HN about once a year, and it's worth calling out that the SSO tax has mostly nothing to do with technology or with support costs and mostly everything to do with market segmentation. One of the clearest segmentation signals you get is that bigger, less price-sensitive customers all require SSO (because their SOC2 attestations require it).
You can get irritated about pricing systems that soak price-insensitive customers, but remember that the big price-insensitive customers pay for the price-sensitive customers, which is why this kind of segmentation is practically universal.
> In reality, without market segmentation a singular price for everyone would fall much closer to the enterprise price than the non-enterprise price.
That totally depends on the relative elasticity of supply and demand.
It’s not very intuitive, but price discrimination (usually) results in too much demand for a good/service and a deadweight loss of consumer surplus. In the worst case scenario all consumer surplus can be arrogated to the producer, and an extreme oversupply of the product. Imagine a cheap drug that could be sold for whatever amount of money the consumer had available.
Price discrimination allows producers to capture consumer surplus from consumers with a greater WTP than the otherwise price, and to offer the product at a lower price to those with a lower WTP.
In a monopoly, this means that the quantity supplied may be greater, but it would still be no greater than under perfect competition (necessarily so since the monopolist would never offer the product at a lower price than their MC, which is where price would be under PC). You can see this because there is no consumer that would buy under price discrimination that wouldn't buy under PC, and everyone with a WTP greater than MC buys either way.
Anyway, I agree that price discrimination results in the producer capturing more consumer surplus, but it can potentially be beneficial for those with a lower WTP in return for hurting those with a higher WTP.
There are many arguments I've heard about price discrimination being annoying, but deadweight loss is not one of them. Quite the opposite, fixed prices in the presence of undeserved pricing power results in a less than socially optimal amount of production, and price discrimination tends to reduce that.
To say nothing of the implicit argument that software service providers have undeserved pricing power; I think that's begging the question, but it's not really relevant to my quibble here.
Why not? Just like some companies offer discount plans that come with no/very limited tech support, and others charge 10 or 20x for the same product bundled with a high level of support.
Most of the big players like Microsoft charge enterprise customers for support on top of everything else. And this "premium support" still sucks. Microsoft outsources to Accenture who then outsource again to some random dopey small companies in the middle East so you get calls in the middle of the night from Qatar by someone who has no more knowledge than what the docs say. Which you've already read yourself otherwise you wouldn't have gone through the hassle of logging a ticket. Because outsourcing causes barriers between the people who built the thing and the people who support it.
In most of these cases we either give up because the support is so useless, or someone high up calls Microsoft and gets the case escalated away from Accenture to someone in Microsoft who actually knows something.
Personally if I were a CIO I would really be pissed at having to pay for this kind of "support". But yeah these guys rub shoulders with Microsoft all the time who tell them it's all amazing.
> The right way to think of the "SSO tax" (where companies charge extra for security features) is "You are being offered a dual use product backed by a strong engineering team for far less than it would otherwise cost, with sophisticated enterprises picking up the slack."
That said, TLS/SSL used to be the preserve of the enterprise too (or at least the ecommerce site).
There are lots of free options, including 3rd party servers and libraries. I'm hoping eventually SSO will be, if not in free versions, at least not isolated to enterprise plans.
Many "softer" forms of SSO have trickled down too. Google + Microsoft OAuth are ubiquitous today without any upchage. OAuth from a Google Workspace account managed by an IT admin has many of the same security guarantees as SAML or OIDC from a Google Workspace account, at least for a small player. There are some sketches like https://easie.dev/ that explore this further.
> and it's worth calling out that the SSO tax has mostly nothing to do with technology or with support costs
I'm surprised this is at the top. My experience, and the experience of nearly all the commenters below, is that SSO is by far the biggest support burden they have.
SSO costs extra because it costs extra to support them. Market segmentation is a nice side effect though.
To add an anecdote from the other perspective, I was the PM for the authn/z capabilities of a big enterprise platform.
SSO was one of the greatest support burdens due to the numerous protocols we supported and the vast array of sometimes bizarre, often complex auth environments across the customer base.
The biggest hidden cost came from the complete lack of consistency in auth implementations from 3rd party vendors, i.e. it wasn’t enough to implement the SAML/OIDC/etc specs, because many of the systems our customers wanted to connect with had not implemented to spec.
This is all prior to dealing with 2FA which was definitely another major factor.
If you just supported OIDC, you'd still have upcharged for it, at least unless you had an ideological reason not to (we don't, for ideological reasons, but I sort of rue that decision).
I realize in retrospect my comment was probably confusing as written.
The company didn’t charge extra for SSO despite the support cost, also for ideological reasons. But they were also singularly focused on large enterprise customers so it was table stakes. Plenty of other platform modules to upsell.
My point was mostly to highlight that it can be costly for a bunch of reasons.
> The major identity support cost is 2FA, because people constantly lose it, and you need to design and manage an account recovery process.
Some of this is self-inflicted, e.g. a few of my banks only support 2FA via their own apps, so while I'd never lose my TOTP code, it's a hassle every time I lose my phone. (Or it breaks, is stolen, etc.)
I ran a company that did price segmentation on SSO, and it's the other way around. The burden of supporting the buggy piece of crap that is SAML SSO is the cost of the privilege of being able to perform such sharp segmentation.
It's not that small companies don't want it, it's that they're capable of not getting it. Larger companies aren't: one thing their SOC2 auditors will actually be able to evaluate is whether all their vendors do SSO.
Agree, I have implemented a few provider and every time they implemented their own interpretation of the spec. In the end you end up checking each provider to make sure everything works as expected.
It's segmented even in OSS software to the point where it's the first thing I have to check when deciding what software is going to run on my home server.
> mostly nothing to do with technology or with support costs
Support costs aren't zero though. I work for a company with a lot of corporate customers and we get loads of SSO support tickets. People are always misreading the docs, (mis)configuring things against our recommendations, migrating systems, merging systems (due to acquisition etc)...
Also, enterprise customers are way more work, the sales cycle is longer, the compliance and onboarding stuff takes more time. There's a very legitimate case for building that into one's pricing, and it's really the same reason these companies appear price insensitive. If they had people lining up to give them a better price, they'd presumably take it.
I run a very small business, SSO is still very high up on my feature priority list, and I have passed on software/services I would have otherwise used for competitors that offered SSO at a lower entry-point.
I think the implication is that without a few whale customers, the minimum price would be significantly higher for everyone. The SSO whales subsidize everyone else.
I sort of feel that the way most software pricing works is that it is the big customers who pay for features in everything and the small customers get brought along for the ride, in short I think it's the same as SSO for basically all functionality.
I expect like any industry, most SaaS operations are floated by a smaller number of whale customers, and everyone else is running a lot closer to (or at) break even in terms of cost, but serve as advertising, testing, and vendor-validation that allows that next whale to pull the trigger.
It's true both in the micro sense ("We wouldn't have developed the headache that is SSO without a cornerstone customer demanding it and paying $XXXk"), and in the macro sense ("Our business would not be a going concern without the significant revenue provided by enterprise customers")
Interesting. I wouldn't have thought that running an SSO integration is that painful. I've done it before, albeit for a single enterprise client, and while annoying at first, after delivery was just like another feature.
The real issue is not the first one, the issue is the 2nd and 3rd, and 10th, will all have some minor idiosyncrasy. There are other posts in this thread that discuss it more in depth - I have only enough personal experience to know that this particular stove is hot.
Thank you for adding some sanity to this discussion – this is ultimately a matter of economics, and the R&D effort to add and maintain these features is not trivial.
I think you missed the point. The costs isn't insomuch R&D, it's in support. Users struggle with SSO and so we get tickets; techs answering tickets costs money.
> but remember that the big price-insensitive customers pay for the price-sensitive customers
You mean they more than make up for the loss of those customers? What is the underlying cost on the service? Isn't the profit margin here absolutely absurd since the underlying cost to the vendor is basically zero once their implementation is written?
Yes - it's an enterprise versus SMB distinction that doesn't require asking questions like "What's your revenue?" in the qualification. Enterprises need it. SMBs don't.
If you want to fit the word "should" in there somewhere, you can. I think SSO is important, and it would be one of the first 3 things I would stand up at any new shop I went to, but I can think of more important security things that nobody really thinks should be equally distributed across companies.
So the price insensitive get the security the price sensitive can’t afford.
That’s the same logic some use to explain why university fees have to exist opposed to being tax funded, because otherwise the poorer would finance the education of the wealthy totally ignoring that higher costs are the barrier that makes less likely that the poorer can study in the first place.
You can moralize it all you want. All I'm saying is: the alternative to the SSO tax isn't that everyone gets the features they want at the price they want: it's that the price of the low-end product goes up and the price of the high-end product goes down. If you care about distributional effects, that seems like a step backwards.
Of course physical media as a whole is still way down. Streaming outearns physical by a lot. All physical media is less than half what just blu ray was 10 years ago.
I think this is overly complimentary to big business and what's essentially predatory pricing.
The reality is you can't just carve out on feature and say "we pay for this." I mean that's true of a lot of things. The big revenue generators pay for a lot of things, but how things are billed is important. Remember, not to long ago people paid for Netscape, but now its laughable to pay for a browser. Its arbitrary to have this 'buffet' mentality and seems purposely shaming towards people who rightfully complain about ridiculous pricing structures like this.
I'm also skeptical that SSO costs vendors money. Maintaining and supporting an authentication database is a huge expense. For every SSO client, its one less Adobe or whatever account that needs to be hosted. Less helpdesk tickets about password resets, etc. SSO tends to be once and done. Hosting millions of accounts and being the sign-on provider for them is not 'once and done.'
Lastly, a lot of orgs don't do this. A lot arent SOC2. That means they'll just use whatever account the vendor supplies, and most likely without MFA, but their SSO would have provided that, thus making everyone more vulnerable. This is a great example of how exec salaries and stock buybacks and other things have priority over security because security is seen as a cost-center and without litigation or law, stuff like this becomes the norm. Oh and now there's one more source of passwords out there and another potential hack.
This is just greed and predatory. Its not the wonderful largess of big companies. It fact, its quite the opposite.
> Less helpdesk tickets about password resets, etc.
Pretty much everyone knows the password reset flow these days. Even if they do manage to lose access to everything somehow, the process to restore is mostly standard. On the other hand, SSO issues are long, annoying, and involve engineers rather than first level support. Source: my weeks long support tickets with Okta.
Sane SSO from clients with clean setups doesn’t cost vendors much money. But take it from someone who has done this work: that’s rarely the case for the megacorps who want SSO integration. They tend to have horrifying AD/Oauth monstrosities, with back-compat requirements that will break your mind and sysadmins of questionable competence. These require lots of bespoke code and lots of meetings— meaning, lots of man-hours that senior ICs are not spending on product— to get right.
That’s where a lot of the money for SSO is going, and you can’t exactly say “the price depends on how shit your backend is”, so it has to be enough to prepare for the worst.
Sure sounds like you haven’t done SSO operations for a large SaaS provider. Because it’s much, much more support and engineering work to integrate every random SSO provider, each with wildly customized differences for each customer, all totally opaque to the application provider, versus just having a single unified login system that your support staff has necessary visibility into.
Small orgs don't need to be SOC2 to have client contracts that require SSO. This is absolute fucking evil behavior and this page shouldn't exist anymore in 2025.
Evil feels strong? Small companies benefit from having the basic feature set subsidized by big cos. It's kind of hard for me to imagine a scenario where pricing of a saas product could be _evil_. you can just choose not to do business with them!
I think there were two sets of 7 total vulnerabilities at the same time so they might be perceived as one event? I don’t know for sure, the wording was kind of ambiguous.
> Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory on the target device and perform cache poisoning attacks against the target environment.
> These vulnerabilities are also tracked as ICS-VU-668462 and referred to as DNSpooq.
Transport security decisively addresses query ID prediction attacks, without requiring forklift upgrades of the entire DNS infrastructure of the Internet, and has the benefit of working for individual sites even when not widely deployed elsewhere. If the concern is transactional attacks like this dnsmasq thing, advocating for DNSSEC instead of DoH/DoT seems like engineering malpractice.
Transport security protects the channel, not the data. DNSSEC protects the data so that the channel doesn't matter. Given how the DNS is deployed particularly in enterprise environments, there have been too many times when protecting the channel simply meant data corruption crept in someplace in the sometimes ridiculous chains of forwarders and caches.
Oh, and it doesn't appear dnsmasq supports DoH/DoT forwarding (not positive as I don't use it and haven't looked at the code). It does support DNSSEC.
At multiple points on this thread you tell other people here that DNSSEC is the correct solution both for this dnsmasq security issue and for query ID prediction attacks generally. All of those are channel attacks that have nothing to do with the authenticity of DNS records.
I happen to think DNSSEC, writ large, is also engineering malpractice, but when I use that term just upthread, I was referring to your insistence that people deploy a top-down data authentication mechanism in order to resolve a trivial transaction spoofing attack, given the availability of multiple existing tools that decisively address those kinds of problems without any of the expense and coordination required for DNSSEC.
You're all over this thread and every other DNS thread, even the ones that don't have much to do with DNSSEC, constantly complaining about DNSSEC. Why?
Last time you were arguing DNSSEC wouldn't solve BGP hijacks because whoever was hijacking the DNS server would just hijack the web server instead.
I archive linked it because you’re in this thread, and you operate that site. I’m removing any conflict of interest by posting it as an archive. I even used IA just to remove any hint of bias I suppose. I don’t want you doing timing attacks against me for posting it here now, or against those who may visit it later, nor do I want you to poison my DNS! I don’t even know enough about these exploits to know if it’s technically possible, but I know that you almost certainly do! I don’t think you would do this, but you’re in a position to do so.
I did not mean it as a slight by doing so. I meant it as an acknowledgment of the sensitive nature of these issues, and part of my work as an amateur journalist and archivist. I say amateur because I do not do this work for personal benefit or gain, but because I like researching and learning myself, and I don’t believe in putting a light I also read by under a bushel.
While searching for your post on archive.today or whatever their name is, I saw that it had also been archived without a trailing “/“ which redirects to the one with a trailing slash, so depending on how I parse what you said and how you originally posted it and how the redirect is implemented, I could see how that statement might be ambiguous but that kind of thing might be handled by your webserver software. I don’t think that it’s worth mentioning, but you did say it’s always been at that URL, which I don’t dispute. I’ve never known it to be at any other URL.
I'm just giving you shit. Thanks for posting it. You're not wrong: I have longstanding strong feelings (much further back than that post) about DNSSEC, both because I had to implement it, and because I remember it being used as an excuse not to randomize DNS requests. Also: I tilt at a lot of windmills, and this particular evil giant is on the verge of collapsing!
I think there's a lot of reasons why DNSSEC is moribund. It was a necessary accompaniment to IPSEC back in the mid-1990s when everybody assumed we'd be all v6 all IPSEC by 2000. Then Kashpureff's bailiwick attack happened, and we got this:
... but the bailiwick caching behavior was a straight-up bug, and rand(3) was enough to make QID spoofing more annoying to exploit than it was worth. Something like 5 years later we had the birthday attack, but I don't recall anybody taking it especially seriously --- maybe because at roughly the same time, DNSSEC was going through the "typecode roll" that took us from DNSSEC to DNSSECbis, and nobody was confident about pushing DNSSEC at that point; the TLDs weren't even signed.
Then 5 years after that we got Kaminsky. There's a spark of interest in DNSSEC after that... but all the vendors who hadn't already adopted DJB's randomization immediately did, and Kaminsky's attack stopped mattering.
By this point I think it was clear to everybody that protecting transactions wasn't going to be the motivating use case for DNSSEC, so people shifted to DANE: using DNSSEC as a global PKI to replace the X.509 certificate authorities. But DANE flat-out never worked; you couldn't deploy it in a way that was resilient against downgrades, so there was simply no point.
Then Google and Mozilla killed several of the largest CAs, and used their market power to force CT on the remaining (and thoroughly cowed) CAs. And LetsEncrypt happened. So modern concern over replacing the X.509 CAs registers somewhere in seriousness alongside Linux on the Desktop.
People try to come up with increasingly exotic reasons why we'll be forced to use DNSSEC with the WebPKI; it's not so much DANE anymore as it is resilience against BGP attacks and validation of ACME DNS challenges. It's all pretty unserious.
Meanwhile: unlike DNSSEC, which has seen only marginal adoption over 30 years, DoH has caught fire. Within the next 5 years, it's not unlikely that we'll come up with some deployment scenario whereby CAs can use DoH to secure lookups all the way to authority servers. We'll see. It's a lot more likely than a global deployment of DNSSEC.
There's just no reason for it to exist anymore.
I have a lot more reasons than this not to like DNSSEC --- I actively dislike it as a protocol and as a cryptosystem. But those are just my takes, and what I've related in this comment is I think pretty much objectively verifiable.
I'm unclear there is a security issue with dnsmasq -- maybe leaving a transaction alive too long (but then again, what does "too long" mean these days?). However, I haven't looked into the "vulnerability" referenced to be sure (the "malformed name" aspect of the report doesn't fill me with confidence).
I contend that creating signatures over the data at the sending side and then validating those signatures at the receiving end is superior protection to encrypting the channel over which the data is transmitted. Protecting the data is end-to-end. Protecting the channel is hop-by-hop. If you could ensure that the client speaks directly to the authoritative(s), the protection would be equivalent. But that's not how the DNS is operationally deployed (dnsmasq is a perfect example: forwarders really shouldn't exist).
I would agree with you that operationally, DNSSEC deployment is lacking (i.e., water is wet) and the requirement for both the authoritative side and resolving side to simultaneously implement is a (very) heavy lift. However, even your Tranco stats show that there are pockets of non-trivial deployment (e.g., governments) and I believe the trend is increased deployment over the long term globally.
Fortunately, it's not either/or. I personally prefer DoT/DoH to a trusted (i.e., that I run) resolver that DNSSEC validates. Unfortunately, as dnsmasq doesn't appear to implement forwarding to DoT/DoH resolvers, you're left with DNSSEC or not using dnsmasq (which is what I gather you're recommending).
So you're saying the end user does not care about the data (IP addresses, mail servers, etc.) for the domain names they're trying to reach and they'd be perfectly happy (say) going to the IP address of an attacker controlled website instead of their bank? Interesting position.
They're being contrarian and pedantic for the sake of being contrarian and pedantic. No, DNSSEC doesn't protect anything the user cares about because it protects IP addresses and the user doesn't care about IP addresses. Yes, DNSSEC protects the user because it blocks one vector by which they can be redirected to a phishing site.
Because it's a bad idea! Identity is much more complicated than any sane cryptographic protocol can express. You can see why instantly when people suggest things like Metamask as a solution to the problem: durable long-term strong cryptographic identity with no account recovery.
Was that link supposed to make a point? I think it needed a summary from you. ;-)
As far as I can tell, HN receives a new submission on average every few minutes. Nobody can possibly click all the links and read all the articles. So, HN readers need some way(s) of determining which articles are likely interesting and which are likely not.
Imagine if HN submissions included only the URL and not the article title. That would be silly, right? But why would it be silly? Because then you'd have little idea what the article is about, unless the URL itself encoded words that explain it.
If we admit that HN readers need some kind of guide to the vast number of articles submitted, then I don't see why it's so far-fetched and seemingly unholy for the submission to add a brief summary.
I actually want to read interesting articles. I'm perfectly willing to "work a little", as it were. There are interesting articles that I miss, that I would read, if not for the uninformative article titles, and that's unfortunate, I think.
It can be actively exploited in the same way that TCP initial sequence numbers can be exploited: when something else goes horribly wrong in the protocol stack. Contra the claim across the thread that the fundamental fix to this problem is DNSSEC (which is never going to happen), the real fix for all this stuff is not to trust this layer of the TCP/IP stack for authentication in the first place: you do cryptography, at the transport layer (not in the name lookup) so that IP address spoofing doesn't matter in the first place.
reply