Hi Ben, That's a good point -- we need to differentiate between what the protocol provides to client software and what that software exposes to end users.
Successful mitigation of the attacks we're talking about comes down largely to how (and when) the information is presented to users -- and finding the right way to do it is likely to take some experimentation and iteration. So, to me, constraining what appears in the protocol is not a good way to addressing these risks. Highlighting their nature and suggesting strategies is likely to be more successful. Cheers, > On 20 May 2025, at 12:23 am, Ben Schwartz <[email protected]> > wrote: > > > From: Mark Nottingham <[email protected]> > > > First, two things that I don't _think_ are being disputed: > > > 1. Surfacing censorship events to end users is desirable, because it a) > > avoids user confusion / misattribution of the problem, and b) allows end > > users to be more fully informed. This is becoming a more urgent problem, > > thanks to current events. > > I don't necessarily view this as desirable. Specifically, I see an important > distinction between informing the user and informing the user agent. > > I feel that informing the user agent is potentially desirable. It can react > in various useful ways: > > * Interpreting the censorship as damage and routing around it. > * Collecting anonymized telemetry on censorship events to produce a public > report. > * Potentially notifying the user at an appropriate level of detail. > > Surfacing censorship events to the user is often difficult, inappropriate, or > counterproductive, depending on factors such as the user's technical skill > and the applicable legal frameworks. I am reminded of a string of incidents > in Kazakhstan [1], which were successfully resolved without any specific user > messaging in client software. Attempting to explain the precise situation to > those users might have increased the risk of panic and confusion. > > --Ben > > [1] https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
