On Tue, Apr 18, 2023 at 7:49 AM Ralf Weber <d...@fl1ger.de> wrote: > Moin! > > On 18 Apr 2023, at 13:11, Benjamin Schwartz wrote: > > > The draft's opening words are "DNS filtering is widely deployed for > network > > security". This is true, but by far the "widest" deployment of DNS > > filtering is for authoritarian national censorship, to prevent citizens > > from engaging with forbidden ideas. > > Do you have any data to back this claim up?
According to Freedom House, 64% of Internet users "live in countries where political, social, or religious content was blocked", and "51% live in countries where access to social media platforms was temporarily or permanently restricted". ( https://freedomhouse.org/report/freedom-net/2022/countering-authoritarian-overhaul-internet) In my experience, DNS-based censorship is used for a majority of these blocks (often in concert with other methods). ... > Ok, so for me sub errors are useful as they can give some further > information > on why something was blocked, and that information can be conveyed to the > end user. The EDE categories are rather broad and hence don’t give enough > information on why exactly a site is blocked. Now we could also use free > text, which is a problem for people operating in multi language > environments > or let each resolver operator pick there own, but maybe some categories > that > we all can agree on would be good to put in here. > ... I understand the use case, but I'm not sure this is amenable to standardization. Here are some lists of categories commonly used for this kind of filtering: * Cloudflare: https://developers.cloudflare.com/cloudflare-one/policies/filtering/domain-categories/ * Cisco Umbrella: https://docs.umbrella.com/umbrella-user-guide/docs/dns-content-category-settings * BlueCoat: https://sitereview.bluecoat.com/#/category-descriptions These lists seem highly subjective, proprietary, dynamic (but also ossified), contentious, and likely to raise serious ethical issues (e.g. https://blog.cloudflare.com/the-mistake-that-caused-1-1-1-3-to-block-lgbtqia-sites-today/). A durable agreement between the many filter operators (to agree on the classification) and browser vendors (in order to show user-facing error messages) seems unlikely in general and inappropriate for the IETF specifically. If the suberror field is mainly for communication from resolvers to browsers, then any solution should only move forward if it's satisfactory to both camps. I can't speak for either one, but I think the localization problem sounds easier than the categorization problem. I can also imagine using something like a URN scheme registry to punt categorization out to one or more third parties.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
