Hi, I was checking the standard library of the Go programming language and found that the STD3 rules are disabled by default in the current WHATWG URL standard. I was a bit surprised because many Unicode characters in their KC normal forms could introduce forbidden host code points @, #, /, ... that are dangerous or at least misleading. The STD3 check protects us from those dangerous characters. I understand many existing hosts have the underscore _ in their names that is forbidden by the STD3, but by disabling the entire STD3 check, we become vulnerable to many other attacks based on Unicode normalization. I believe this must have been carefully discussed somewhere within WHATWG. If not, I wonder how I should comment on the current URL standard and propose new changes. I am familiar with GitHub operations but I never interacted with WHATWG before, and would appreciate your guidance in making a proposal.

TL;DR: I wish to add a warning about the danger of disabling the STD3 check and, if an application chooses to disable the STD3 check (possibly to allow the underscore), it should verify that forbidden host code points would never arise from normalization and mapping.

As far as I understand, Step 7 does not prevent such attacks. One attack is that the same URL (record) has multiple Unicode normal forms that would be parsed differently. Here is an example:

https://google.com\uFF03@evil.com

A parser would give the following results:

• username: google.com\uFF03
• host: evil.com

But with its NFKC (where \uFF03 is normalized to #):

https://google.com#@evil.com

a parser would give these results instead:

• host: google.com
• fragment: @evil.com

So, the string and one of its normal forms are both valid URL records, but with different structures. The discrepancies can be exploited in many IDNA-aware applications to fool users or even bypass security checking. This attack is known as HostSplit.