> Il 27/02/2025 11:18 CET Mark Nottingham <[email protected]> ha > scritto: > > > On 27 Feb 2025, at 8:55 pm, Vittorio Bertola > > <[email protected]> wrote: > > > > This depends on the definition of "censorship", and also on whether you > > envisage this system only for EDE 17 (user-requested blocking) or also for > > EDE 16 and 15, which should be used for law-mandated and > > operator's-own-initiative blocking. > > My interest is only in exposing legally-mandated blocking.
So the draft should mention the other two EDE codes as well. > Personally, I'm concerned that making it too easy to surface censorship will > normalise it -- i.e., it will just become part of how the Internet works in > many places. I'm not going to hang onto that as a primary motivation for the > draft's design, because by nature it's speculative. My perception is that it already is normal in most countries and places, especially if you include anti-abuse blocks in the definition of censorship (though I'm not sure if anyone has reliable data on this). Public resolvers seem to be an exception because they tend to escape national blocking orders. I think surfacing it would increase awareness and complaints rather than normalising it, but as you say, we don't know. > What's more relevant is that it's prudent to be cautious in exposing new > surface area like this, in particular because what you see in a browser is > only between you and the site you're talking to (provided you're using HTTPS, > which basically everyone is now) -- changing that to allow a third party to > interpose needs to be done very carefully, especially when that third party > is unauthenticated. Agreed. > As the draft attempts to explain, that's the root of the threat model here -- > allowing an unauthenticated party to interpose into communication when users > are already easily confused by the underlying technology. Keep in mind that > while enterprise and operator networks might consider themselves as > trustworthy in this regard, many people still get their DNS settings from > DHCP in coffee shops and other places that are inherently untrustworthy. Most people are aware of their untrustworthiness, though, which is not limited just to DNS resolution. It would be nice if devices had a reliable concept of "home network" and "away network" and applied different UXs and protections. [about users picking resolvers wisely] > That sounds nice in theory, but most users accept the default resolver > offered to them by the network. Choice exhaustion is a thing. In the end, whether browsers should, should not or must not take care of vetting the local resolver and network is a policy matter on which stakeholders will have different opinions. In the meantime, if we can improve security by adding some form of authentication of the message, that will be positive. We just need to make sure that the standard potentially supports any number and type of resolver operators. By the way, in terms of substance and at first sight, this draft does not look mutually exclusive to draft-structured-dns-error. Perhaps it is just a matter of adding your fields and the related considerations to that draft. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange [email protected] Office @ Via Treviso 12, 10144 Torino, Italy _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
