> middleware boxes which block any protocol they don't understand-- because, hey, it's "more secure" to default-fail, right?

If the intent is to secure something then failing-open will indeed be at odds with that goal. I suspect you’re not implying otherwise, but rather expressing frustration that such providers simply can’t be bothered to put in the work and use security as an excuse.

That was the model that Microsoft used at the height of their power and dominance in the 1990s and 2000s.

> a monopoly dictate a nice clean spec which they can force-deprecate whenever they want

We already have that at times. Apple forced a change to cert expiration that nobody else wanted, but everyone had to pick up as a result. Google regularly forces new specs, and then decides "actually we don't like it now" and deprecates them, which others then have to do as well. Virtually all of the web today is defined by the 3 major browser vendors.

If all these "specs" actually had versions, and our clients and servers had ways to just serve features as requested, then we could have 20 million features and versions, but nothing would break.

Example with cookies: if the cookie spec itself was versioned, then the server could advertise the old version spec, clients could ask for it, and the server could serve it. Then later if there's a new version of the spec, again, new clients could ask for it, and the server could serve it. So both old and new clients get the latest feature they support. You don't have to worry about backwards compatibility because both client and server can pin versions of specs and pick and choose. You can make radical changes to specs to fix persistent issues (without worrying about backwards compatibility) while simultaneously not breaking old stuff.

But we can't do that, because "cookies" aren't their own spec with their own versions, and clients and servers have no way of requesting or advertising versions of specs/sub-specs.

You could actually implement this on top of HTTP/1.1:

  1. Make cookies their own spec, and version it
  2. Add a new request header: "Cookie-Spec-Ver-Req: [range]"
  3. If there's no request header, the spec is version 1.0
  4. If Server sees a request header, it determines if it supports it
  5. Server replies with "Cookie-Spec-Ver: <version>" of what it supports, based on the request
  6. Client receives the spec it requested and handles it accordingly

This actually makes sense from a programmatic standpoint, because "Cookies" are implemented as their own "Spec" in a program anyway, as a class that has to handle every version of how cookies work. So you might as well make it explicit, and have 5 different classes (one per version), and make a new object from the class matching the version you want. This way you have less convoluted logic and don't have regressions when you change things for a new version.

There's no differences between a monopoly and an open standard when it comes to breaking users. They both would rather not for the same reasons