Hi Dan, > On 2 May 2025, at 4:31 am, Dan Wing <danw...@gmail.com> wrote: > > On Apr 30, 2025, at 01:09, Mark Nottingham <m...@mnot.net> wrote: >> >> Hi Dan, >> >> Can you spell out how this intersects with enshittification? I understand >> that there are various centralisation issues and risks inherent in DNS, but >> if you're arguing that this mechanism makes it worse, it's hard to see the >> connection. > > - DNS operator is added to IANA list > - Browsers and other non-browser software query that server for extended > errors > - time passes > - DNS operator increases revenue by encouraging users to visit certain URLs. > For example, mis-typed domains (provided as an example we have seen before). > Someone more creative might envision other bad behaviors if URL is returned.
Got it. My initial reaction is that this is somewhat different -- with mis-typed domains, people got taken straight and silently to Web sites that just loaded into their browsers; here, there's what's effectively an error message with diagnostic information behind another link that they have to click -- and it may be that the link isn't even clickable, it would need to be cut-and-pasted. The countervailing force here is how browsers portray the information to end users -- they have a pretty strong incentive to create UX that doesn't allow such abuse; they also have a pretty good track record (see eg the long journey of TLS security UX). >> My understanding is that the switching costs for resolvers are extremely low >> for most users (hence the rise of public DNS); >> where user action is constrained (e.g,. in an enterprise network), their >> central role is by design (at least by the entity who controls the hardware). >> >> Now, we could talk about defaults and how that inertia tends to empower a >> few operators, but how this mechanism makes that situation worse isn't >> readily apparent. Are you just arguing that we should try to use it as a way >> to limit that tendency? If so, I don't see how it could be used effectively. >> >> Also, the mechanism you do describe -- "users would notice the lower error >> fidelity and browsers would be tempted..." doesn't seem very realistic to >> me. Showing a DNS filtering notification is a positive action, and most >> users won't notice its absence, they'll just see the behaviour they've seen >> to date. Granted, technical folks like us might notice and act, but we are a >> very tiny minority. > > > Agreed. > > Which means users won’t change their DNS server, even when it starts > enshittifying, and even though it’s low switching cost. So users will suffer > when the DNS operator starts doing bad things. If a DNS resolver starts inserting ads / phishing / etc. into responses using this mechanism, I suspect we'd see a couple of responses: 1. Users *would* switch, because a) it's intrusive, b) if the UX folks do their job it's going to be obvious what's happening, and c) because it's likely browsers would only expose the information for resolvers that were explicitly configured (e.g., using encrypted DNS) -- which is evidence that the users who see it have the means to change because they've already made one configuration change. 2. Browsers / clients would hear about such abuse and (eventually) stop their software from displaying information from that resolver. > Users might well notice that browser A (which honors the higher fidelity > error) “works better” than browser B (which ignores the higher fidelity error > because that browser disfavors the user’s choice of DNS server because it > misbehaves). Perhaps that isn’t solvable? But it does mean some users are > going to be harmed when using browser A with that DNS server — and see > whatever the operator wants on that URL. If the user notices and cares about seeing notifications of censorship from their browser AND the DNS resolver is using them for that purpose (i.e., not abusing), I suppose that could be seen as "works better." If either of those conditions aren't true, it's not "working better", right? Cheers, -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
