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

[Mark Nottingham <[e-mail]>]

Hi Jari,

> On 24 Mar 2022, at 10:49 pm, Jari Arkko <[e-mail]> wrote:
> 
> Hi Mark,
> 
> And thanks for writing this. I think this is spot-on, and a very useful document. And understanding an issue even if you can’t always do something about it is important.

Thanks.

> I did have a few comments, though. Mostly in the category of perhaps-you-could-also-talk-about-these:
> 
> 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

> 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?

> 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

> 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

Thanks for the review!

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