Paul, > On 30 Apr 2025, at 12:17 pm, Paul Wouters <paul@xxxxxxxxx> wrote: >>> If browsers only display proper error messages when using a few well >>> known DNS servers, than I think that is apparent. >> >> I'd agree, *if* being able to show DNS filtering / censorship error messages can be argued to be a significant competitive advantage for resolvers. > > Isn't that the whole reason for this? Better service to the enduser > instead of vague errors or timeouts ? Or as you wrote in your draft's > intro: > > Because such filtering happens during DNS resolution, there > is not an effective way to communicate what is happening to > end users, often resulting in misattribution of the issue as a > technical problem > > So yes, there would be a browser copetitive advantage of being better. You just switched from competitive advantage for resolvers to that for browsers. Which is the concern here? >> I tend to think about this in terms of getting the message that censorship is happening out there. > > That does not need free form text as I explained in my previous email. > >> One of the assumptions that the draft makes is that it's not feasible to show details on every blocked response, for a variety of reasons. So, it allows browsers to select those that they decide are trustworthy enough to show those messages, in order to get that message out. > > The browser displaying an i18n version of DNS_CENSORED_USG or > DNS_FILTERED_MALWARE or DNS_FILTERED_ADULT does that fine. That's your opinion. I think it isn't sufficient. > The "trustworthy" part is a separate issue I raised in my previous > email, but you completely ignored to response to that. I'll take another look at your e-mail. >> How many resolvers they choose to bless in this fashion is a good question; likewise, questions about how they decide and what governance institutions would be put in place are very good ones to ask. To me, those answers have the most influence over the likelihood of this approach having a centralising effect. > > A lot of words saying "using a few centralized DNS servers blessed by > browser vendors" - clearly my own local home DNS server isn't going to > be one of them. So this is a centralization problem. Ignoring the snark, that's a big jump -- there are a number of nuanced and interrelated problems here that shouldn't be reduced to "it's centralised if I can't run it at home." >> I'd love to hear responses from the browser vendors about this, and would be happy to help sketch out some answers -- although just like in other areas, actually defining those rules and institutions are likely out of scope for the IETF. That doesn't mean we shouldn't be aware of, contribute to, and watch those efforts, of course. > > Not related to my questions and issues raised. Noted, but I still believe it's relevant to the discussion we're having. >>> I'm also not sure what the security model is of this: >>> >>> Generators MUST only use values that are registered in the DNS >>> Resolver Operator registry; see Section 4.2. Consumers MUST >>> ignore unregistered values, and MAY ignore registered values. >>> >>> What prevents an attacking from using the Google DNS ID and then putting >>> a malicious text like "visit www.fbi.dev to avoid being arrested" in the >>> text ? Even if the text is not clickable, some people will fall for it. >> >> The text isn't shown in the current approach taken by my draft; only the URL. >> >> Most of the rest of your comments seem to rely on the text being shown, so I won't respond to them for now. > > A URL is worse than text. It is text that can take over your entire > browser window or OS screen. All the same raised issues apply, so I am > still interested to hear your answers on that. It is obvious either the > user is presented with some "human readable text", or it is presented > with a web page containing "human readable and clickable text". I think it's less obvious than you do, and it very much depends on how the URL is presented to the user. Perhaps the browser UX folks might say more about this. Cheers, -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
