I agree with the importance of user agents "exercising judgement" about these incident information sources. An "open" policy would invite a variety of abuses.
I still don't see why IANA should be involved. The JSON could equally well be structured as a list of URLs. The user agent would presumably apply a domain-name allowlist. The draft says it aims to enable notification "without requiring the [web browser] to independently track which URLs are in use". I don't understand this sentence, so I don't know if it is meant as a justification. (The current design does seem to require the browser to keep an embedded database of URL templates.) I can imagine some possible motivations for the registry-based design: * To make an "open" policy impossible to implement carelessly or by accident. * To bias the inclusion negotiation between user agent vendors and prospective incident information sources in some way. * To require public disclosure when this specification is deployed privately within "enterprise" networks. * To facilitate domain name changes for incident databases. * To save bytes on the wire. These arguments all strike me as weak or flawed in various ways. Whatever the reasoning, I would like to see a clearer rationale for the design in the draft, if only to help future IETF participants to assess if it is working as intended. I do think we should expand the text about other ways that user agents can limit and deter abuse and security problems: * Considering the current mode of DNS configuration (e.g. automatic vs. manual) and level of transport security (e.g. authenticated vs. opportunistic TLS) when assessing whether to display reports. * Approving particular (resolver, database) pairs based on the resolver's documented reporting plans. * Requiring filtering databases to use an "https" URI scheme. * Rejecting or warning about incident reports that are expired/closed. (This might require additional standardization work.) * Collecting and publishing anonymized metrics about usage of this specification. --Ben Schwartz ________________________________ From: Mark Nottingham <[email protected]> Sent: Thursday, February 19, 2026 8:31 PM To: Paul Wouters <[email protected]> Cc: [email protected] WG <[email protected]>; David Adrian <[email protected]> Subject: [DNSOP] Re: New Version Notification for draft-nottingham-dnsop-censorship-transparency-00.txt Hi Paul, > On 20 Feb 2026, at 12:16 pm, Paul Wouters <[email protected]> > wrote: > > On Fri, 20 Feb 2026, Mark Nottingham wrote: > >> Subject: [DNSOP] Fwd: New Version Notification for >> draft-nottingham-dnsop-censorship-transparency-00.txt >> Based on discussion at the interim, this draft is renamed and contains a >> proposal for Privacy Considerations. > > Why the draft name change? I thought this looked familiar and then > re-found draft-nottingham-public-resolver-errors. The diff between > that and this is fairly small: As discussed in the interim, the old name was no longer applicable, and potentially confusing. > I still do not like how the IANA registry and browser adoption of > certain lists becomes yet another centralization point in the internet. > > Why not use a _prefix within the configured resolver's namespace to > point to the reporting database url prefix? This would be a much better > decentralized method that wouldn't give further centralizing browsers > an additional benefit of "better error reporting". > > Why is a filtering ID needed? Doesn't the QNAME already provies a globally > unique identifier? It would make things less depending on filter vendors' > references. It would also prevent abusive IDs that embed javascript or > otherwise try to mislead by adding some identifier in it, eg > > id="123 > https://urldefense.com/v3/__http://www.malicious.com/why-did-my-dns-get-filtered__;!!Bt8RZUm9aw!_HkKWQIocUlhLbWXPht48lrFMnkddCotI6cxO-j7Jp2krPeVqKyGYOApfQ9Lp4GhauQGovWnX3DHvvEz8amKr1im_g$ > " > > That is, if I run a pihole filter in my network, how can my browser use > a reporting service without me needing to hack the browser for it, or > be forced to use quad(1,8,9) for DNS resolving to get decent error reporting? > > If I run my resolver on 192.168.13.13, why can't extended errors be > defined to be at > https://urldefense.com/v3/__https://192.168.13.13/dns-filter-error/qname/__;!!Bt8RZUm9aw!_HkKWQIocUlhLbWXPht48lrFMnkddCotI6cxO-j7Jp2krPeVqKyGYOApfQ9Lp4GhauQGovWnX3DHvvEz8akZmw2rBw$ > > The extended errors would come from the same source as the query, so > either both are untrusted or both are trusted. > > That is, I strongly prefer a method that people can rollout that does > not depend on a "golden list" added to browsers based on some IANA > registry (and bags of money for certain business models) So, that gets us back to putting links from _any_ DNS resolver on the internet in front of end users. As we've said in a few different ways, that's a non-starter; it's a phishing vector and will be a huge headache for pretty much everyone. We need _some_ mechanism to make this safe. Our original approach was to only selectively support some resolvers (namely, widely recognised public resolvers). That (deservedly) got pushback for creating pressure for centralisation. This approach breaks from that by only selectively supporting some Web sites as "databases" of filtering incidents. The initial example (and I believe what Chrome wants to support) being https://urldefense.com/v3/__https://lumendatabase.org__;!!Bt8RZUm9aw!_HkKWQIocUlhLbWXPht48lrFMnkddCotI6cxO-j7Jp2krPeVqKyGYOApfQ9Lp4GhauQGovWnX3DHvvEz8anBZt6d_w$ - originally started by Wendy Seltzer, now run by Harvard Law School Library system. What exactly is the "bags of money" model you have in mind for Harvard here? Cheers, -- Mark Nottingham https://urldefense.com/v3/__https://www.mnot.net/__;!!Bt8RZUm9aw!_HkKWQIocUlhLbWXPht48lrFMnkddCotI6cxO-j7Jp2krPeVqKyGYOApfQ9Lp4GhauQGovWnX3DHvvEz8an7QBkNog$ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
