hirsin

Pkce is trivially easy to announce support for, you put it in the issuer metadata.

code_challenge_methods_supported

https://datatracker.ietf.org/doc/html/rfc8414#section-2

And specifically Sam goto (Google, fedcm) and Dick Hardt (hello, oauth2 spec writer).

This was originally thought up a couple (5-6) years ago along side fedcm and privacy sandbox, but before SD-jwt was full baked, so it wasn't as clean. The use of SD-jwt is much better for privacy.

Those are the same thing in our system.

There's at least the appearance of causation here, with the FCC Chairman publicly saying that broadcasters could get their licenses yanked if they didn't drop Kimmel, and later that suddenly occurring.

https://www.cnn.com/2025/09/18/entertainment/abc-jimmy-kimme...

I imagine a smoking gun will be demanded by this SCOTUS though, and this kind of stochastic "would be nice if someone..." pressure/threat will get a pass.

We also had yet another delay on the new light rail line because the power lines were stolen... Twice, in a week.

https://www.king5.com/article/news/local/copper-wire-theft-l...

The worst case is when this mentality of "just update your code" leaks out to the rest of us. I'm still scarred from some of the samesite shenanigans, breaking useful (not ads) boxed software because they figured everyone on the internet could "just update" their websites within six months of them putting out a dev blog post.

It's just not an accurate view of how the world works.

I assure you it's far too easy to get as many ip addresses as you want if your interest is in avoiding rate limits.

The MCP server technically doesn't support DCR. The authorization server for the MCP server does, which is a minor distinction.

Have you seen significant need for this? I've been trying to find data on things like "how many MCP clients are there really" - if it takes off where everything is going to be an MCP client && dynamically discovering what tools it needs beyond what it was originally set up for, sure.

They don't care, they still want support and most leadership teams are unwilling to stand behind a stance of telling customers no.

And you're lucky if it's two. If they're not familiar with the rendering engine/docs system/API platform/middleware etc (or just think they aren't), or have low confidence in a debt ridden platform, they'll spend five minutes a day for a week or three theorizing on how it could have gone wrong, debating if, actually, it's correct the way it is, refreshing their knowledge of deep internals, debating if a fix could break something, and so on. Way safer to do that than risk making things worse in an uncertain system.

Hm, I wonder how the double sig problem that SAML would run into will work here. What happens if someone adds an extra sig object there?

That works as long as you have no distinctions between objects of a type. _Which_ calendar can they edit? All of them?

Putting all the repos you can access into a token is a request we get sometimes. It would be... Difficult.

We don't need SDKs, they publish API docs.

We don't need packages or functions, we can just write the code ourselves, every time it's needed.

We don't need compilers, the computer understands assembly already.

It's a mismatch of use - MCP isn't about telling the LLM about the APIs. It's also about encapsulating and simplifying them so the LLM isn't manually figuring them out every single time from scratch.

The point above about enterprise glue is why this is a pull model.

In your push model, the onus is on you to go find the scan from one of five backends, traverse whatever hoops of access are needed, and actually handle the files manually.

In the pull model, each backend implements the server once, the LLM gets connected to each one once, and you have one single flow to interact with all of them.

Touching on tenancy and the "real" gaps in the spec does help push the discussion in a useful direction.

https://vulnerablemcp.info/ is a good collection of the immediately obvious issues with the MCP protocol that need to be addressed. A couple low blows in there, that feel a bit motivated to make MCP look worse, but generally a good starting point overall.

I imagine they'd have all the lovely problems of both EV certs (sure, you're legitimately PayPal Corp, in Malawi) and limited real estate price squeezes.

Curation of "good" or "real" websites has been tried before - I don't envy anyone that wants to try another go at it.

At one point we were looking at moving a bunch of separate domains under a single dotless domain, due to the threatened death of 3p cookies, so that cookies could be dropped directly onto the cctld (think "you're logged into the entire TLD"). As the owners of the cctld it felt like a neat use that technically could work but ICANN and other groups are explicitly against that.

To me it felt very AOL keyword

Indeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms".

The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that they exist.

Give it more than a couple months though and I think we'll see it mature some more. We just got their auth patterns to use existing rails and concepts, just have to eat the rest of the camel.

This is one of the few places I think it's obvious why MCP provides value - an OpenAPI document is static and does no lifting for the LLM, forcing the LLM to handle all of the call construction and correctness on its own. MCP servers reduce LLM load by providing abstractions over concepts, with basically the same benefits we get by not having to write assembly by hand.

In a literal sense it's easier, safer, faster, etc for an LLM to remember "use server Foo to do X" than "I read a document that talks about calling api z with token q to get data b, and I can combine three or four api calls using this http library to...."

No there isn't (a big difference)

Like, really. If I open ms paint and just do some low effort scrawl, I have copyright on that. Level of effort has not ever decided if something is copyrightable or not.

For derivative works, there is real effort required to de distinct from the original. Maybe that's a more interesting discussion... Is low effort use of an AI insufficient to prevent the copyright from reverting to the original authors it was trained on?

No, the exact opposite. This says that if the AI that a bank is paying for locks your bank account in error because your name sounds <ethnicity with a lot of locked bank accounts>, it's the banks problem to fix, not yours to just live with (entirely. You still likely have a problem).

> I don't see 5-10x more useful features in the software I use, or 5-10x more software that's useful to me, or that the software I'm using is suddenly working 5-10x better, etc.

This has bad assumptions about what higher productivity looks like.

Other alternatives include:

1. Companies require fewer engineers, so there are layoffs. Software products are cheaper than before because the cost to build and maintain them is reduced.

2. Companies require fewer engineers so they lay them off and retain the spend, using it as stock buybacks or exec comp.

And certainly it feels like we've seen #2 out in the wild.

Assuming that the number of people working on software you use remains constant is not a good assumption.

(Personally this has been my finding. I'm able to get a bit more done in my day by eg writing a quick script to do something tedious. But not 5x more)

This. It's extremely expensive to keep core functionality like this in a fork. Every single surface that manifest v2 touches (js runtime, extension hosting, permissions, network, APIs, chrome even) that gets changed upstream has to be redone to account for v2. Every new system built into Chrome that only works with v3 has to be effectively back ported to v2.

The only other option is to keep v2 in chromium itself and have Chrome disable it... While still paying the cost of supporting it in all new feature dev.

There's no world where Microsoft spins up a new engineering team solely to deal with the extra cost of keeping v2 around.

That said this sucks. I got my first internship on the Internet Explorer team by talking about how hard it was to install an ad blocker in IE, compared to Chrome.

Twitter has 80% less revenue than it's peak in 2022, less than it had in 2014.

Even if it is more profitable, it's doing a heck of a lot less. The government being 80% less effective would be a very bad outcome here.

It's worth noting that many of these are service agreements, not just data. It's tailored/specialized forecasts that are being built for the customer, not simply selling them the data they give to the public for free. So doing additional work for a fee, not monetizing existing data.

We have an existing oversight body, the OIG, which is a couple orders of magnitude larger than DOGE. And a reasonable statement you could defensibly make is that OIG isn't doing enough to curtail spending, the same way you or I aren't doing enough to prevent bugs in the code.

The only thing DOGE does, that OIG doesn't, is _not_ attempt to understand the value of the work being done.

The people in DOGE are of course a problem, but the process they're following is flawed from the get go, namely "judge programs based on the opinion of some uninformed outsiders".

"generally pro doge" would imply they support what doge is doing, namely shutting things down

It's funny. We get up in arms because our boss's boss's boss wants to decide if the work we're doing this sprint is valuable - there's no way they can begin to understand what it is they pay me to do here! They've got dozens or hundreds of reports, no way they can decide if fixing this CSS bug is the best use of my time.

And then people think they can decide if the radar station detecting low altitude systems near Palau is a good investment or not.

Is this something like inverse gell-man amnesia? You're aware of the value noaa provides so you're skeptical about removing it, but when we turn the page to talk about another agency removal makes sense again?

Not attempting to dunk, I should say, but wondering how this gets modeled and if there's actually a discrepancy there