Re: [Mimi] Confirming adoption calls for draft-barnes-mimi-arch and draft-ralston-mimi-protocol

[Rohan Mahy <[e-mail]>]

I wanted to correct myself on one point below.
"how often each client sends messages, " applies to the hub and sending
providers only.

Thanks,
-rohan

On Sun, Mar 24, 2024, 15:11 Rohan Mahy <[e-mail]> wrote:

> Hi Brendan,
>
> You characterized the state of the current draft as "freely" sharing a lot
> of metadata with all the providers. I'd like to examine that a bit more.
>
> Assuming each client follows the recommendation in the draft to use a
> unique pseudonym per group (this implies only joining via join/invitation
> links or knocks), the non-local providers know the following:
> - the authorization policy of the group (broadly),
> - how many MLS clients from each provider are in each group,
> - how often each client sends messages,
> - the authorization role(s) assigned to their anonymized users, and
> - (if they reveal it) if there are multiple devices under the same
> pseudonym.
>
> While a user's local provider (which the user has chosen) is sort of
> outside of the scope of MIMI, when it is a hub provider it will at least
> need to disclose machine-readable privacy information for each of its
> rooms. Each client gets to examine the room policy before they join and
> before they accept any change to that policy. This is already way better
> than the status quo. The metadata privacy extensions that Konrad and
> Raphael are working on further improve the privacy situation.
>
> If you think this is setting the privacy bar too low, I think it would be
> reasonable to provide an outline of how you think MIMI could provide
> similar functionality with even less metadata. IMO this doesn't need to be
> an I-D, but at least a page-long email with bullet points.
>
> Thanks,
> -rohan
>
> On Sat, Mar 23, 2024 at 3:45 PM Brendan McMillion <
> [e-mail]> wrote:
>
>> Providing the same privacy properties as Signal is incredibly difficult.
>> Nobody is asking mimi to do that. However, the mimi protocol could be a
>> neutral way for service providers to synchronize messages related to a
>> given group. Whether a service provider chooses to receive messages in some
>> exceptionally private way or not, would be the service provider's choice.
>> But instead the drafts require duplicating state between the encryption
>> layer and mimi layer, and this presupposes a certain inescapable amount of
>> metadata leakage.
>>
>> On Sun, Mar 24, 2024 at 1:49 AM Rohan Mahy <[e-mail]> wrote:
>>
>>>
>>>
>>> On Sat, Mar 23, 2024, 02:38 Stephen Farrell <[e-mail]>
>>> wrote:
>>>
>>>> Sounds like a classic loss for privacy.
>>>>
>>>
>>> I argue it is the opposite. Today if you want to join a group chat on
>>> any system other than Signal, the participants surrender much more metadata
>>> than would be revealed to other providers under the proposed MIMI approach
>>> with pseudonyms. In addition, the low metadata approaches (using techniques
>>> such as privacy pass) that Konrad and Raphael are nurturing offer
>>> substantial improvements to privacy.
>>> If we publish a specification that requires all providers to provide at
>>> least Signal-level metadata privacy, it is likely that we will end up with
>>> neither interoperability nor privacy for the vast majority of users.
>>> Thanks,
>>> -rohan
>>>
>>>