Centralization

[mnot]

Currently, the doc says:

Ensure the Web does not favor centralization.

This is pretty sparse. Arguably, the Web itself is a platform for building heavily centralised services (e.g., Amazon, Google, Facebook); the text above is written as if centralisation is a potential but unlikely pitfall, when the reality is that the platform steers heavily towards it.

I think we need to focus on three things:

1. Define what 'centralisation' means to the Web. People are using the term to mean different things; some common vocabulary and understanding will help communication. Part of this will also be documenting the centralisation risk in the existing Web platform.

2. Ensure that new Web platform features do not introduce centralisation risk. For example, WebRTC is architected to favour building silos, not federated systems. That was a rational choice at the time it was created, because it was obvious that sites had little interest in supporting federation; however, the power dynamics have arguably changed since then.

3. Define new Web platform features that combat centralisation. This might be in concert with legal efforts; for example, many jurisdictions are discussing interoperability standards as a remedy to abuse of power in markets like social networking. W3C could position itself to satisfy some of these requirements.

[cwilso]

Here, too, my intent was to tread somewhat lightly. Where the platform "steers heavily toward [centralization]", we should be working to remove that influence. Where new Web platform features encourage silos (like the WebRTC example you gave), we should work to enable non-siloed solutions.

I do NOT think that we specifically have a principle of "combat centralization", however; it is a quick slip from there to "actively work to make the Web a hostile environment for the likes of Amazon, Google and Facebook", which I don't think is a goal.

(Wording suggestions welcome!)

[mnot]

A bit of a wordy suggestion:

Avoid the formation of 'choke points' in the Web, where one party enjoys its network effects disproportionately. In particular, Web specifications should mandate decentralised or federated operation, where technically possible. When not possible, other mitigations to centralisation should be considered. Note that this does not extend to preventing centralised services to be built 'on top of' the Web. However, when Web specifications extend "up" into application-specific areas, this principle should be honoured.

[cwilso]

I think we're in rough agreement here. I have concerns about putting in text that can (and will) be taken out of context - in particular, "Web specifications should mandate decentralised or federated operation" is concerning out of context, because it seems that one could take it to say, for example, that Twitter is bad because it is a centralised service. I think you are trying to say "don't set up WebRTC to go through only one server" or something like that - even to the point of, say, applying to Google's AMP cache as part of the AMP ecosystem. Is that an appropriate take on your suggestion?

[mnot]

Yes, that's what the last two sentences are trying to do. How about:

Ensure that the Web does not favour centralisation. As the Web has become a platform that other, proprietary platforms are built upon, there is a growing concern about the formation of 'choke points' in them -- where one party enjoys its network effects disproportionately. While we cannot prevent the formation of such choke points in every case (especially considering the need to preserve the Web as a stable platform), we can avoid the creation of new potential choke points in the Web platform, by requiring proposed features to operate in a decentralised or federated fashion when technically possible, resorting to other mitigations when it is not.

[dwsinger]

I think there are two levels here, and the hard one is the second level. The first level is if we design specs that rely on the idea of a powerful center (e.g. a set of servers); that's something we can try to avoid, indeed. But the second is the natural "large player effect" where e.g. everyone uses Internet Explorer because all the web sites test with it, and all the web sites test with it because all the users use it.