[Mimi] Re: Abuse reporting requirements discussed during the interim

[Rohan Mahy <[e-mail]>]

Well, we really want to not ignore *you*, but we will skip over this
particular *topic* ("dumb Hub" reporting and policy). Looking forward to
your comments about the requirements once you've had a chance to digest
them.
Thanks,
-rohan

On Sun, Aug 25, 2024 at 11:41 AM Deirdre Connolly <[e-mail]>
wrote:

> OK great, ignore me then!
>
> On Sun, Aug 25, 2024, 2:40 PM Rohan Mahy <[e-mail]> wrote:
>
>> Hi Dierdre,
>> Yes, we decided a while ago that in MIMI, messaging providers can have a
>> role in policy enforcement, and that was pretty necessary to meet the
>> requirements / reproduce the functionality in most messaging apps (see the
>> penultimate sentence "facilitate interoperability given the feature set of
>> modern messaging applications"). Note that three of the early implementers
>> of MLS: Webex, Wickr, and Wire all independently came to this conclusion as
>> well.
>>
>> While you can build a system that uses MLS and kicks almost all the
>> decisions and power to moderators and admins who are members of a group,
>> and uses some of the insights of MIMI (for example MIMI content and
>> AppSync), it won't be MIMI if it prohibits the hub from having this role.
>> You could build a client that works in both of these worlds, but that would
>> be out of scope for MIMI.
>>
>> Hope that helps.
>> Thanks,
>> -rohan
>>
>> On Sun, Aug 25, 2024 at 11:17 AM Deirdre Connolly <
>> [e-mail]> wrote:
>>
>>> Thanks for the writeup! A question:
>>>
>>> - Receiver of a message can report it as allegedly abusive to the Hub
>>>> provider.
>>>>      - Why the hub?
>>>>          - Because it knows the policy of the room
>>>>
>>>
>>> Is this always the case? I could envision an MLS deployment with other
>>> useful Mimi 'stuff' that follows a Signal model of keeping per-room
>>> policies, membership, and metadata private from the broader service, and
>>> offloads enforcement it to the inner workings of the private room itself.
>>> In that case, reporting and moderation would be to 'the room' (or
>>> owners/admins in the private room) to action. I could see a further
>>> escalation up the chain from within the private room to The Service level,
>>> which then follows the reporting to the Hub as described here.
>>>
>>> If that sort of scenario is out of scope or not really a thing because
>>> of other Mimi stuff, sorry 😬
>>>
>>> On Sun, Aug 25, 2024 at 1:11 PM Rohan Mahy <[e-mail]> wrote:
>>>
>>>> Hi,
>>>> We had a healthy discussion of the Abuse reporting and franking PR#83
>>>> <https://github.com/ietf-wg-mimi/mimi-protocol/pull/83> at the interim
>>>> on Wednesday. We had a good deal of discussion about the requirements. I
>>>> have attempted to capture the requirements so far in this list.
>>>>
>>>> # MIMI Abuse reporting
>>>> ## Basic premise/scope of the mechanism
>>>> - Receiver of a message can report it as allegedly abusive to the Hub
>>>> provider.
>>>>      - Why the hub?
>>>>          - Because it knows the policy of the room
>>>>          - Because all messages go through the hub (see below)
>>>>      - Sends the plaintext of the allegedly abusive message(s)
>>>>
>>>> This mechanism is about receivers reporting alleged abuse to the Hub
>>>> and the changes to submitting a message necessary for that to happen
>>>> safely. It does not address communication between a Hub and a sender's
>>>> provider or reporter's provider, or future remedies.†
>>>>
>>>> ## Requirements
>>>> ### Message confidentiality
>>>> - Hub can’t read the content of messages unless they are reported
>>>> - Other providers can never read the content of messages using this
>>>> mechanism†
>>>> ### Sender attribution integrity
>>>> - Receiver can’t attribute a bogus abusive message to a sender
>>>> - Sender can’t deny a message they sent
>>>> ### Sender privacy
>>>> - Hub servers need to know the sender of a message (already, in order
>>>> to enforce policies related to which participants can send messages), and
>>>> we can rely on this for this mechanism.
>>>> - Follower servers do not learn the sender of any message using this
>>>> mechanism†.
>>>> ### Original ciphertext of alleged abusive not needed at moment report
>>>> is generated
>>>> - Hubs don’t need to store ciphertext to verify they received a
>>>> particular message
>>>> - Receiving client does not need to store ciphertext indefinitely to
>>>> report a message
>>>> - Desirable that after backing up and restoring history (ex: I upgrade
>>>> my phone), the new client can still report an abusive message
>>>> ### Deployable
>>>> - Not especially heavy to implement for client or server.
>>>>      - Adding extra roundtrips before sending a message would be
>>>> especially painful for clients.
>>>> ### Later work
>>>> - †: There may be additional requirements (Hub reporting its findings
>>>> to sender’s provider) that can be implemented as additional endpoints that
>>>> do not have any client implementation implications.
>>>>      - There are likely to be substantial SLAs between pairs of
>>>> providers which govern how
>>>> - This also does not discuss Remedies that the Hub (or other providers,
>>>> if communicated with them) might take, such as revoking voice, kicking,
>>>> banning, etc.
>>>>
>>>> ## Issue
>>>> A Receiver sending an abuse-report directly to the Hub (not through
>>>> their local provider) sort of violates the principle that we are not
>>>> defining client to server protocol. If a report goes through the receiver’s
>>>> local server, this leaks both the sender’s identity and the message content
>>>> to the receiver’s local server, unless we further encrypt the report for
>>>> the Hub (ex: using the HPKE external_receiver public key of the hub).
>>>>
>>>> Is it acceptable to send reports directly to the Hub (bypassing the
>>>> local provider), or is it better to add HKE encryption of the report)?
>>>>
>>>> Thanks,
>>>> -rohan
>>>> --
>>>> Mimi mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>