Hi Ben, I agree that the rationale for the registry should be clearer, and I'd say that in general the registry is something that the WG could discuss -- I don't think anyone is lie-down-in-the-road about it.
And of course the security considerations and related aspects should be refined. Cheers, > On 21 Feb 2026, at 3:34 am, Ben Schwartz <[email protected]> > wrote: > > 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 SchwartzFrom: 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) > beinghttps://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] -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
