Is a registry needed? #345
Description
In #288, I raised an issue arguing against registries in general. @npdoty suggested I create a new issue for that discussion. I've combined my two comments over there to frame the fundamental question about a registry.
Registries create overhead, security risks, and barriers to entry.
Without a compelling argument why these problems are worth it, I'd argue the downsides outweigh the benefits.
Please discuss.
As I brought up at the GDC session on barriers to global adoption, I would prefer to see the registries removed entirely.
A few points:
Registries
- Act as a barrier to adoption
- Squelch innovation.
- Propagate Western technocolonialism
- Don't actually improve the security of the system
- Put the W3C in an inappropriately elevated position
- Are primarily a first-mover advantage that controls and limits adoption, rather than advance it
- Create a novel and unnecessary attack surface
Registries act as a barrier to adoption
It is inevitable that any registry we make will not be available in all the languages in the world. This puts anyone who is not a native English speaker at a disadvantage. This is a known problem for W3C specifications: it's hard to maintain localized versions. Further, if the information to be placed in the registry MUST be in English, that is also a barrier to those developers who work in a different language context. IMO, developers should be free to innovate in their own native tongue and use that technology regardless of whether or not they can convince the W3C to add it to a registry (for whatever reason they might be denied, including using a name that someone else also uses).
Registries squelch innovation
There's a reason there isn't a required registry of websites. As TBL stated in his first publication describing the web as a whole, https://cds.cern.ch/record/369245/files/dd-89-001.pdf he explicitly called out the importance of NOT restricting the nature of the content on the web:
the method of storage must not place its own restraints on the
information.
and
The system must allow any sort of information to be entered. Another
person must be able to find the information, sometimes without
knowing what he is looking for.
and
Non-Centralisation
Information systems start small and grow. They also start
isolated and then merge. A new system must allow existing
systems to be linked together without requiring any central
control or coordination.
and
The only way in which sufficient flexibility can be incorporated is to
separate the information storage software from the information
display software, with a well defined interface between them. Given
the requirement for network access, it is natural to let this clean
interface coincide with the physical division between the user and the
remote database machine3.
This division also is important in order to allow the heterogeneity
which is required at CERN (and would be a boon for the world in
general).
In short, a registry creates restrictions, which goes against the very intent of the World Wide Web, which was specifically designed to allow massive innovation without centralized authorities vetting each new feature or content. This will limit adoption.
Registries propagate western Technocolonialism
This is a well-known point of historical contention. Registries for the web, specifically DNS and IANA IP blocks, have been widely criticized for enshrining a particularly western, and even American position of privilege. For example, the US got to decide that all .gov domains are for the US government, and initial DNS specification couldn't handle non-western text. Any system that defers to a single registry run by a western-biased organization will propagate the kind of technocolonial perspective that places non-Western, non-English speaking, non first-moving parties at a specific, structural disadvantage that is not easily remediated. This will limit adoption.
Registries don't actually improve the security of the system.
While a registry could attempt to vet any particular proposal, there is no guarantee that (a) the vetting is thorough, correct, and still valid, nor (b) that any given implementation of that protocol is implemented in a way that realizes the intended security guarantees. At best, it blesses "well-known" and popular technologies at the expense of perhaps more secure, more trustworthy alternatives. The fact that a protocol is listed in a registry is likely to create a false believe that it is of high quality and that any implementations claiming to use that protocol are also, therefore, somehow trustworthy. In reality, implementers considering which protocols to support should investigate the protocols themselves with their own concerns to see which best fit their needs. For any given use case, any particular protocol might be grossly inappropriate; imo, there simply is no way for a central organization to effectively vet all the possible technologies that might be useful. This will create a false sense of security rather than invite a healthy skepticism.
Registries put the W3C in an inappropriately elevated position
Although all of us here are, necessarily, supportive of the W3C as a standards development organization (or we wouldn't be here having this debate), there is no reason to believe that the W3C has the capability and moral authority to actually stay on top of real-time vetting of protocols as imagined by this specification. The W3C is not a cybersecurity response agency. We simply don't have the operational processes in place to maintain an appropriate posture with regard to the security of any given protocol. Even if a protocol were reasonably well-vetted by security minded professionals, there is no infrastructure or processes to maintain that assessment over time. The fact is, the W3C is just one of many organizations that have opinions about the quality of different protocols. Placing our own assessments over those of other, often more qualified, organizations would do a substantial disservice to the actual security of DCAPI implementations, by inducing trust because a protocol is listed in the registry despite the inherent inability for the W3C to stay on top of emerging cyber threats (at least with its current operational funding an processes). Best case, the W3C can advocate for those protocols its members approve of, but asserting that such a registry is any indicator of deployed security quality would be a gross misrepresentation.
Registries are primarily a first-mover advantage that controls and limits adoption, rather than advance it
Registries fundamentally keep things not in the registry in a relegated position. Whatever rules one must satisfy to get into the registry comprise real and unavoidable barriers to anyone not already in the privileged club. If you take the misguided DID Method registry, you'll see what I mean. In two separate incidents, the registry maintainers relied on flawed analysis that forced real innovators to adopt lesser alternatives than simply calling their DID method what they wanted. In one case, it was an ineffective policy about who actually controls an entry. In another, it was a flawed legal argument that allowed a community member to shout down a legitimate entry without effective due process that actually engaged the rule of law (it was an alleged trademark matter). While both of these were eventually resolved (both in a flawed manner, imo), they illustrate the fundamental function of the registry was NOT to embrace innovation, but rather to contain it, to limit it, not advance it. This will limit adoption and usefulness of the DCAPI.
In fact, any registry that is not a listing of requirements, e.g., protocols that are mandatory to implement, will only be able to exclude unlisted protocols, since inclusion in the registry won't ensure that any implementation actually supports any given protocol. With that lens, the only function of the registry is to limit the set of supported protocols.
Registries create a novel and unnecessary attack surface
Once you rely on registries, those registries become their own attack surface for security considerations. It will be possible
a. to get a spec listed in the registry inappropriately
b. for entries in the registry to be inappropriately removed
c. for entries in the registry to be inappropriately updated
A strong set of institutional processes can minimize the impact of these attacks, but as long as there is a registry, it, by itself, creates threats that can be entirely avoided simply by designing without a registry.
IMO, all we actually need are mechanisms for which components can self-identify the protocols they support and the browser deals which matching both ends of the credential exchange as a dumb pipe, supporting whatever can be supported in the architecture. Which is to say, I fully realize that a deployed piece of software is not going to randomly suddenly be able to support a new protocol, but the decision to support any protocol is far less the purview of the W3C as much as the responsibility of implementers. In fact, I expect there will eventually emerge meta-protocols that allow the equivalent of media codecs to be downloaded on the fly to support additional functionality. Any kind of restrictive registry would make that sort of dynamic flexibility functionally impossible.
There is sometimes an argument raised that without a registry, you can't know what protocol someone is actually referring to. This problem as solved rather elegantly with GUIDs, used by Microsoft to securely identity COM interfaces created by anyone without a centralized registry. Yes, there were directories of a sort which could give you the GUIDs for commonly used interfaces, but the technology worked: it enabled any programmer to define their own COM interface that immediately had interoperable semantics (for identification of the COM interface) so it could be used by any COM-enabled software that knows to look for that particular interface.
I would suggest considering ways that we can remove the registries entirely, all of them.
In my second comment
Do you have any suggestions of replacements for the existing registries of which you are aware, at W3C or elsewhere?
Yes,. First, I'd separate this into two functions.
First, for run-time matching, use GUIDs or DIDs or even URIs (RDF style) to allow components to self-describe using globally unique identifiers (which painlessly refactors to URIs without needing to distinguish nuance between URIs, URNs, and URLs). This includes formats that self describe, as well as protocols. The developers of components simply publish the globally unique identifier for their component in their specification and developers decide at dev time which components they want to support, then implementations communicate which components they support at run time.
Second, for discovery, use directories, search engines, and LLMs. Developers, at dev time, are going to use the web and associated mechanisms to learn about interesting components, just as we do today for nearly all technology we incorporate in our applications. The thing about these kinds of services is that there are no gatekeepers for the meta platform: each directory, search engine, or LLM gets to decide which components it indexes. Reciprocally, developers can use any discovery tool to find the technology they are interested in, without deference to a systemic limitation on the platform. Decentralized discovery is how the Web works. Let's keep using that rather than impose the W3C as a gatekeeper for systems built on its technology.
FWIW, I don't consider automated discovery to be a problem worth solving as streamlining automated downloads of untrusted algorithms without human evaluation is a known security problem. Manual discovery through the web helps ensure that developers are in the loop when incorporating components. Perhaps more to the point: I don't think the convenience of automated discovery is worth the centralizing costs, especially in light of the increased security risks of adding that capability.
I wonder whether any (probably not all) of your objections might be solvable by adjustments to those registries?
First, turning them into directories for discovery would be a big help. There's nothing wrong with a spec listing related technologies as an aid to developers. It's when you make it a "registry" that leads to conversations like this, where people expect registration to be required and hence, it seems reasonable to make listing in the registry have normative requirements, which is what is proposed in this issue.
Second, remove any requirements other than editorial review for inclusion, making it clear that the list is a curated list maintained by specific editors, and not an official registry that has normative impact. I don't mind if the editors have opinions, but I do find it challenging when rules are imposed on the registry to exclude "bad" listings because they don't satisfy some obscure, political, or ideological reason and hence establish a false notion of approval by the W3C as a whole, rather than the independent opinion of respected editors.