Hi Ben, Mark,
At 07:23 AM 19-05-2025, Ben Schwartz 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.
I'll comment from personal experience. Facebook was one of the
social media sites which was blocked at my location. I won't comment
much about the incidents in Kazakhstan except to say that the
landscape has changed over the past ten years.
I would expect to see an extended DNS error protocol-wise (RFC 8914)
as it helps to distinguish between the different failure modes. I
would lean towards informing the user so that he/she has the choice
to do something. Some users worked around the problem within the hour.
I agree that it would be better for the user-agent to display some
information to the user. Otherwise, it would be difficult to
distinguish between technical error and something else, e.g. a
censorship event. I would be less skeptical about the collecting
anonymized telemetry approach if there was some actual incident where
the public report was useful to the affected user-base.
Regards,
S. Moonesamy
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
