avoiding-internet-centralization
avoiding-internet-centralization copied to clipboard
mnot
Discovery / defaults / etc.
Jari says:
[O]ne thing that is not discussed but perhaps should be is the role of discovery. We seem to have an increasing number of solutions that are built for relatively fixed linkages between OS - device - browser - application - network services. For instance, a default service lead to a situation where a vast majority of users will use the default service. From a standards perspective it would be better to build on discovery such that for instance local services can be used. This is of course not always easy, but I think it needs to be looked at, at least on a per-case basis.
This is most closely related to the 'Decentralise Proprietary Functions' section, but it's not obvious / related enough; more examples and perhaps reframing might help.
Here I don’t have a text proposal yet, but maybe one could cover at least the following:
- examples: OS, device, browser, and application systems get built to use very specific services. E.g., the use of DNS resolvers.
- effects: Difficult for other or local services to be used.
- rationale for X to be built with very specific binding to a service: Whoever builds X understands exactly what they need and what is provided by the service. There may also be contracts associated with the use of that specific service.
- issue: While settings can be changed, that is not a practical alternative for vast majority of users
- issue: Sets up a model where only the services that can have a default bundling and a contract e.g. with major browser or OS vendor will actually get used
- issue: Internet and applications become more and more ’packaged’, designed & curated black box services where changing components or parts is difficult
- possible alleviating techniques: Modularity, discovery, indirection
- difficulties: For many functions, it is not ok to use a random thing that someone nearby offers, for obvious security reasons. Indirection and user/os-specificed trusted roots for specific functions may be helpful though.
- other: there’s probably some more considerations that at least I have not figured out yet
I feel like this might be part of a larger issue / discussion regarding consideration of the user -- providing choices, how defaults work, cognitive load considerations (eg how security dialogues in browsers are presented).
I'm trying to rough in something along those lines, but what I'm running into is that while it's easy to point out problems in the ecosystem (as you highlight), it's much more difficult to recommend actions that standards bodies can take to improve the situation, beyond those we already have.
What do you see as in-scope for this document? I.e., what recommendations can we make? Or is it adequate to just point at these things and say "carefully consider these"?
Your new doc version is great otherwise, but I think we still need to do something on this. Let me come back with a proposal per your question marks above...
Isn't the actions for standards bodies somewhat straightforward, still? For instance, due to lack of standards, it has been difficult to upgrade existing DNS servers to use DOH (albeit that is now being fixed in ADD), which lead to a situation where you have to be a party to a deal with Mozilla in order to get into their selected TRR list. Had both discovery and configuration been options from day one, then DOH deployment could have occurred both from the point of view of browsers pushing their model of TRRs and organic upgrades. As it was, more of the former happened. Of course there are many other factors as well (who wants to spend effort on DNS etc) but that's certainly one area where standards organizations could have helped. Removing gatekeepers is a useful service!
And this isn't limited to DNS, of course, or even companies pushing their agendas and standards organizations being the good guys. Sometimes a standards organization has big players that want to keep a feature out so that they get to benefit from whatever current situation gives to them -- something which I recently encountered in an entirely different field. In that particular case it was important that architectures are flexible, components are pluggable, so that the standard organisations don't get to be too much of gatekeepers any more. I guess the flexibility of QUIC for new versions and new functionality is another example of this, something which we can perhaps benefit from in the future.
Obviously those discovery and flexibility mechanisms may also be misused. A dominant player use them to push (perhaps a proprietary version) of their thing, leaving others out.
So, I think standards bodies could have shipped a more complete solution (and the draft already obliquely talks about that). However, an SDO couldn't compel Mozilla (or anyone else) not to use it in a 'locked in' fashion.
Also, one could argue the community wanted to prove the base technology before shipping other components to scale it out (in this case, oblivious DNS is one component that adds some very interesting properties from a centralizaton standpoint). I don't know that ADD is the answer, in that letting a network interpose an intermediary removes much of the value of DoH.
Back to this spec, I'm still struggling to see how it fits in. Discovery is one specific technology area that has impact on centralization, but there are many more -- e.g., identity. So far this draft doesn't go down to the level of exploring specific technological problems. It could of course -- perhaps using DoH as a case study. I'm a bit concerned that it would make the draft more of a political football, however.
Thoughts? Can you give me an indication of how you'd like to see this surface in the draft -- is it fitting into one of the existing sections, or something new like a case study?
See also #54 which might be somewhat related.
To tease that out a bit - #54 might result in a recommendation to assure there are appropriate, well-thought-out points of interoperability in the specifications we create. We could talk about discoverability there as a factor to making that 'pivot point' actually useful / complete.
That said, I'm wary of making blanket pronouncements that discovery is good / desirable - mostly because it ignores issues of trust / safety if you allow anyone to shove something into the users' face as an option.
For me discovery mechanisms are the technical basis to enable broader federation. Only having both open interfaces and discovery makes it possible for new actors to join (without asking the existing actors for permission). Having this said I’m actually not sure you are describing different decentralization techniques in section 3 or just the same techniques (federation?) on different layers…?
One of the reasons I'm reluctant to do something specific about discovery in this draft is that it would create the expectation that it was a complete treatment, and that other aspects that have an important contribution also get equal coverage.
I don't think discovery is that simple. There are tradeoffs in cognitive load for users, security modelling, and trust models for the new actors we're adding. That's not to say that discovery doesn't have a place in a less centralized world, but it's a complex topic that really deserves its own study -- not a brief overview in this draft that's likely to be misinterpreted.
Again, I do see aspects that touch on discovery coming out at a higher level in #54, and I think that's a more appropriate approach for this draft to take.
Mirja, you make an interesting point about the nature of the subsections of 3. I suspect we could recast them in that manner, but many people think of them as distinct options, so it might not communicate as well.