Re: [arch-d] Review of draft-nottingham-avoiding-internet-centralization

[Mark Nottingham <[e-mail]>]

Thanks, Jari - that's very helpful.

Just so folks know, I'm responding in the issues created.

Cheers,


> On 21 May 2022, at 12:32 am, Jari Arkko <[e-mail]> wrote:
> 
> Mark,
> 
> Returning to this topic.
> 
>>> Section 6.1 talks about relationship between centralization and privacy, and points out that there's sometimes a tradeoff. I would argue that this is heavily dependent on what we're talking about. We're far along on the mission to encrypt all communications. Many of the remaining privacy issues are made worse, not better, by centralization. E.g., one entity has access to all your mail or browser history or other things. Perhaps the 6.1 language could be improved, as it currently reads a bit like focusing on privacy in standardisation and leaving centralisation to other entities. I’m not sure that’s always desirable, particularly if we want to address privacy.
>> 
>> Agreed - I've created:
>> https://github.com/mnot/avoiding-internet-centralization/issues/27
> 
> Thanks. I added some text proposal on GitHub. Or at least a start for one.
> 
>>> More generally, I think you're missing a subsection on limiting data centralisation to too few hands. Perhaps that could be added?
>> 
>> I'm not sure what you mean here, although it might brush against an issue I recently created:
>> https://github.com/mnot/avoiding-internet-centralization/issues/26
>> 
>> Could you expand / give examples?
> 
> That issue seems to be about something else. 
> 
> But in any case, the suggested text for issue 27 does add some discussion of what the ’data in too few’ hands might imply. Did that text clarify what I meant? 
> 
> (I think it is a bigger issue in the sense that it might be raised on its on subsection as well, but your call on how you want to edit the document.)
> 
>> 
>>> Also, one 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.
>> 
>> Yes - I think that's hinted at in the discussion of 'Decentralise Proprietary Functions' -- but that might not be the best framing, and more examples / discussion would probably help. I've created:
>> https://github.com/mnot/avoiding-internet-centralization/issues/28
> 
> 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
> 
>> 
>>> Section 4.4 inherited centralization — I’m not sure how much network-imposed limitations we have today, or in few years, given that in the western world at least much of the traffic is today encrypted. However, there are situations where government mandates or government - large internet content provider collaboration can create a setup where the user's choices for communication are severely restricted, and consequently, often centralized to few remaining ones. Perhaps you could talk a bit about this.
>> 
>> I agree that's a risk, but I'm not sure it's in-scope for this document. Perhaps it could be worked in as a source of centralisation -- effectively, externally-induced centralisation. I'll track in:
>> https://github.com/mnot/avoiding-internet-centralization/issues/29
> 
> I see that you resolved this, looked initially at least good. Thanks!
> 
> Jari
> 
> 

--
Mark Nottingham   https://www.mnot.net/