Re: [arch-d] Hiding in crowds

Hi

I don't know if this is relevant, but when I saw the question,

> What kind of business model fosters a network of medium size services 
> without aggregating into a much smaller number of very large 
> providers?

I thought of Letterpress Private Presses

Then I extended that to Artists, printmakers, designers of art cards, 
letterpress private presses.

With each of those, the distinctiveness between each person's work is 
what is of appeal. If they all worked as one team and produced one line 
of products, the essence of what exists now would be lost.

So can each service each have its own distinctiveness such that those 
distinctivenesses keep aggregation away?

William Overington

Tuesday 24 May 2022

------ Original Message ------
From: "Christian Huitema" <huitema@huitema.net>
To: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>; 
"Mark Nottingham" <mnot@mnot.net>
Sent: Tuesday, 2022 May 24 At 06:10
Subject: [arch-d] Hiding in crowds
Mark as written a very good description of centralization issues in the 
"internet-centralization" draft. I believe once that is published, it 
may well motivate new studies. The one such study i think of is "hiding 
in crowds", an attitude found in many privacy-oriented architectures. 
Onion routers come to mind: if a single participant was using the onion 
network, her traces would be very easy to track. But if the traces of a 
large number of participants mix into the onion network, her traces 
become as hard to track as footprints on a crowded beach. The onion 
routers alone do not provide privacy, the crowd using the onion does.
The same effect is at play when a crowd of services use ESNI and hide 
their identity behind a single fronting server, or when a crowd of DNS 
clients route their encrypted request through a big recursive resolver. 
But these two examples clearly show the tension between centralization 
and hiding in crowds. If the privacy guarantees are only effective when 
going through the same services as a large crowd, privacy seekers are 
motivated to use centralized solution. Why use ESNI and hide behind a 
boutique front-end when Cloudflare would hide the service in a large 
crowd? Why use a small non-profit DNS resolver when a crowd is already 
using Google DNS?
But then, if maximum concentration provides the biggest crowds, it also 
provide huge risks. So, what to do? We can try placing a relay in front 
of the service, like oblivious DNS proposes for DNS. The relay would 
hide some of the metadata, and perhaps limit the exposure of information 
to the concentrated server. But the relaying service needs a crowd of 
users to provide privacy, which means that we will probably see 
concentration there too.
Or we could try threading the needle, using services that are "just big 
enough" to provide a hiding crowd, but avoid the extreme bigness of 
concentration. Which seems like a weirdly unstable combination, unless 
maybe some kind of economic construct that supports such services and 
also supports entry of new actors. And no, I am not thinking of the 
blockchain for that. But I keep thinking of economics there. What kind 
of business model fosters a network of medium size services without 
aggregating into a much smaller number of very large providers? What 
kind of network architecture would support such deployment models?
-- Christian Huitema
_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss 
<https://www.ietf.org/mailman/listinfo/architecture-discuss>