Hi Tim, sorry the comment was more for Ben :-) on the consumer users use case.
Inviato da Outlook per Android<https://aka.ms/AAb9ysg>
C2 General
From: Tim Wicinski
Sent: Thursday, November 9, 2023 5:21:09 PM
To: Gianpaolo Angelo Scalone, Vodafone
C
:14:26 PM
A: Tim Wicinski ; Ben Schwartz
Cc: Gianpaolo Angelo Scalone, Vodafone ;
dnsop@ietf.org
Oggetto: Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-07.txt
External Email: Be cautious about the sender email address, attachments and
links. If uncertain use Report Message button.
Hi,
I still think that a mechanism to reach an HTTPS resource is needed.
Considering the security implications of rendering directly an HTTPS URI,
It could be an additional field, to be used by the client
* For out of band connection to retrieve the needed page info from
resolvers with high r
Hi,
I think that we have now 2 good potential compromises:
1. A browser interstitial page explaining that the following page is
generated by the service that blocked the actual page, with a button indicating
"proceed to the blocking page" and another "dismiss"
2. A graphical representation
I agree that RFC8914 Extended Errors is an improvement and provides some
awareness on the reason for blocking,
but without knowing the blocking service it is not possible to comply against a
block and eventually request a reclassification.
I am not suggesting to take whatever text arrives from th
I really love this draft and would like to see browser side implementation for
the benefit of customers user experience.
Today several services are implemented on top of DNS to filter malicious or
unwanted traffic in an effective way, but customers cannot distinguish the
blocking from a networ
