Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.
Контент доступен только на следующих языках
The Intellectual Property Constituency (IPC) appreciates the opportunity to provide input on the String Similarity Evaluation (SSE) Data for the New gTLD: Next Round. Our primary concern is ensuring the SSE data is adequate to help protect against visual confusion in the gTLD namespace (including, e.g., typosquatting or brand impersonation) across all scripts, thereby protecting consumers and Intellectual Property (IP) rights.
Input on Code Point Pairs and Similarity Categories
The IPC supports a comprehensive and cautious approach to string similarity, prioritizing user and consumer protection from confusion. Therefore, we generally advocate for including code point pairs that present a reasonable risk of visual similarity, even if only in specific contexts or font styles, and assigning a higher (more restrictive) similarity category where warranted in order to ensure the strings are referred for a manual review.
Missing Visually Similar Pairs
We recommend a comprehensive re-evaluation of all Latin, Greek, and Cyrillic script common character sets to ensure no visually similar pairs, particularly those that may be classified as Highly Confusable (Category 2) under various font renderings, are missing. A thorough check for potential near-homograph pairs across different scripts is essential.
Specific Example: We believe a strong case exists for adding the pair of the Greek letter Omicron (O) and the Latin letter O (U+004F, U+039F) if it is not already included.
Suggestion: U+004F, U+039F, 2
The IPC does not propose the removal of any currently included pairs (Category 1, 2, or 3) at this time, as we prioritize IP protection and preventing consumer confusion. We believe it is safer to be over-inclusive in string similarity to mitigate abuse.
It is difficult to identify specific pairs that require a re-categorization change. However, we urge ICANN to err on the side of caution. Where a pair is currently listed as Similar (Category 3), but a reasonable person could perceive it as Highly Confusable (Category 2) in common fonts, we recommend upgrading the category to 2. This would apply to many common cross-script homoglyphs.
The IPC is concerned that automatically setting "imposed" pairs to Category 4 (Distantly Similar) may overlook real-world confusion risks introduced through transitivity. If a string $A$ is highly similar to string $B$ (Category 2), and $B$ is highly similar to $C$ (Category 2), the string similarity of $A$ versus $C$ should be reviewed carefully.
We believe any "imposed" pair that links two strings that have a significant, well-established visual similarity in general usage should be elevated to Category 2 (Highly Confusable). This requires a case-by-case review of the "imposed" set against real-world domain name examples.
Choice 3: Other, please provide detail.
The homoglyph similarity between the ASCII code points U+0069 (LATIN SMALL LETTER I) and U+006C (LATIN SMALL LETTER L) is a well-known and significant source of string confusion, particularly in modern font renderings. gTLD applications are generally case-insensitive but their visual representation in web browsers is case-sensitive (mixed-case is often what users see and type). The highest risk in the case of mixed case scripts would appear to be where the character in question is the initial letter of the word/string, since this is the situation where mixed cases are most naturally displayed in written text. That said, there could be concerns also at other points in the string. This similarity must be captured adequately, and so the IPC supports assigning a higher-level risk categorization in order to ensure that such situations are referred to manual review, but with the expectation that the evaluation panel will take into consideration the position of the character within the string when determining the actual overall string similarity. Choice 1: Included in the similarity set with visual similarity Category 1 for the homoglyphs. The IPC chooses Choice 1. This pair represents an identical or near identical (homograph) risk to the end-user when viewing mixed-case domain names. This high-level categorization is necessary to prevent trademark abuse via this common form of character substitution.
The IPC acknowledges the extreme complexity of visual similarity analysis for Han script characters. While the methodology for the New gTLD: Next Round represents significant progress, we remain concerned about capturing all potential visual similarity, especially due to regional font variations and stylistic rendering differences (e.g., simplified vs. traditional forms).
We urge ICANN to ensure that the analysis incorporates the perspectives of IP owners who have experienced brand abuse involving Han script variations. A particular focus should be placed on high-frequency, complex characters that may have small, easily missed differences that an abusive registrant could exploit. We recommend external validation by native CJK speakers with expertise in IP or security.
Choice 2: Other, please provide details.
The IPC agrees with the analysis in Appendix A, which focuses on the transitive inclusion of ASCII similarity due to uppercase-lowercase conversion and variant definitions. This transitive analysis is a necessary component of a robust similarity set.
The IPC stresses that the overall goal of the String Similarity Evaluation is to protect end-users and trademark holders from deceptive domain registrations, including in the gTLD namespace. This data set will form a critical foundation for preventing brand abuse and consumer harm in the next round of gTLD applications. Therefore, the guiding principle for finalizing the SSE Data should be caution and restrictiveness. Where there is ambiguity or a potential for confusion, the more restrictive similarity category (Category 1, 2, or 3) should be chosen. The SSE data should be a living document, subject to review and update as new homoglyph threats emerge.