- Latingp - lists.icann.org

Summary of Latin GP Meeting on 30 August 2018
by Pitinan Kooarmornpatana Aug. 31, 2018

Aug. 31, 2018

Dear Latin GP Members, Please find attached the summary of the meeting of the Latin GP Meeting on 30 August 2018. Please let us know if you would like to suggest any edits or additions. Action Items S. No. Action Items Owner 1 Add the description and the access date of the references PK 2 Review the in-script and Armenian cross-script variant for the next meeting. ALL Next meeting: 6 September 2018, 16.00 UTC. This summary and the recording will be posted at the Latin GP wiki page shortly at https://community.icann.org/display/croscomlgrprocedure/Latin+GP Regards, Pitinan

1 0

Latin-Cyrillic variant table
by Tan Tanaka, Dennis Aug. 30, 2018

Aug. 30, 2018

Latin-Cyrillic variant candidates table enclosed …. https://docs.google.com/spreadsheets/d/1_AvaG3vgNsozyNs1Cj68HivcWmV7HRwwXz4… You can copy the table from the sheet labeled “Candidates Only” (Columns B through J). -Dennis

1 0

Re: [Latingp] From IP: Diacritics below a security risk?
by Tan Tanaka, Dennis Aug. 30, 2018

Aug. 30, 2018

Interesting input that we should not take lightly and ought to put serious thought on it. A few things to consider: * Let’s be cautious to not over-produce variants due to corner cases. The example below is a second-level domain name and our work is relevant for the top-level. Unlike second-level, the top level has an extraordinarily high bar for existence (i.e. there needs to be application round in process, there are substantial application fees, technical and financial requirements to run a registry, etc.). Therefore, I find it very unlikely that an entity would even apply for approval for a top-level label that is visually confusable of another. Even in that event, ICANN has other mechanisms (e.g. String Similarity Review, DNS Stability Review) to stop similar applied-for TLDs from progressing in the application process. * Security risk analysis deserves a place in our work, but should first focus on real issues and not hypothetical ones. Do we have examples of this being observed in practice? * This input deviates from past guidance, so we need to assess the ramifications to our principles of inclusion for in-script and cross-script variants. On this note, I appreciate that any additional work will delay our submission to IP before our workshop in early October. But I think it is better that we take the time to deliver a quality work. -Dennis From: Latingp <latingp-bounces(a)icann.org> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org> Date: Wednesday, August 29, 2018 at 2:58 AM To: Latin GP <latingp(a)icann.org> Subject: [EXTERNAL] [Latingp] From IP: Diacritics below a security risk? Dear Latin GP members Kindly find below some feedback from IP for your consideration. Regards Sarmad TO: LatinGP FROM: IP There are recent and widely published examples of phishing attacks using Latin IDNs in which the key features involved were diacritics below the letter. Here is an example: [cid:part1.E6E9F88C.32B00687@ix.netcom.com] Of all diacritics, diacritics below can be difficult to distinguish or be prone to clipping -- there is less space below the baseline than between the typical lowercase glyph and the top of the line. The example given above shows a further interaction with URL underlining - and not all display engines actually do as nice a job interrupting the underline as in the screen shot above. For example, here is how one system will render this (using a designated UI font - Segoe UI): [cid:part2.59964F92.16B1BC0B@ix.netcom.com] Note, this code point (U+1E33) is in the MSR as is (U+1E35 LATIN SMALL K WITH LINE BELOW). [cid:part3.99B9649E.C3C335FC@ix.netcom.com] The second example contains U+1E35 -- while the effect does not show equally at all type sizes, from 12pt and below the LINE BELOW is reliably hidden. Here are the two examples at 10pt [cid:part4.B43CE3FD.8C84EACF@ix.netcom.com] The issue is not limited to "K". We see "B", "D", "L" and "N" with both DOT and LINE BELOW and "M" and "H" with DOT BELOW, all on the same page in the MSR. It can be argued users have no working understanding of typography and would not reliably interpret small gaps or bulges in the underline as being related to an unfamiliar code point. This appears to make all diacritics below security-sensitive, however, the initial determination belongs to the relevant GPs. Note by the way that the Devanagari LGR treats sequences containing NUKTA (a dot below) as variants in at least some cases and recent community comments for that script are calling for more variant sequences. However, while the feature is graphically analog (dot below), each script works differently and there is no single a-priori solution. The IP would like to encourage the LatinGP (and any other GP facing cases like this) to explicitly examine this example and other cases like it, where code points can become indistinguishable in common usage scenarios for IDNs, and formally conclude whether and how to take these into account when designing their LGR. At this point, the IP would expect the GP to: * explicitly discuss this and other scenarios like it * evaluate whether they constitute a security risk to the Root Zone * come up with a reasoned decision as to whether and how to address them in the design of the Latin GP; and finally * document both the decision and its rationale. In coming to a decision, the GP may resolve: 1) to make them variants 2) to list them for attention as confusable 3) to take no action, because the GP feels that they do not represent a special security risk. As part of the review of the Latin LGR, the IP will look at the background and rationale offered by the Latin GP in coming to its conclusion; note that if the IP feels that the facts considered and rationale documented do not support the conclusion reached by the GP it may raise objections at that time.

2 1

Summary of Latin GP Meeting on 23 August 2018
by Pitinan Kooarmornpatana Aug. 30, 2018

Aug. 30, 2018

Dear Latin GP Members, Please find attached the summary of the meeting of Latin GP Meeting on 23 August 2018. Please let us know if you would like to suggest any edits or additions. Action Items S. No. Action Items Owner 1 Review the in-script and cross-script variant google documents ALL This summary and the recording will be posted at the Latin GP wiki page shortly at https://community.icann.org/display/croscomlgrprocedure/Latin+GP Regards, Pitinan

1 0

Latin GP meeting
by Pitinan Kooarmornpatana Aug. 30, 2018

Aug. 30, 2018

Dear Latin GP members , This is a gentle reminder of the Latin GP meeting on August the 30th, 2018, 16:00UTC. AGENDA for the GP call on August the 30th, 2018, 16:00UTC 1. Roll call 2. Progress of the work on Report I have made following changes to the Report document: * Languages Bavarian, Kabyle, Mundati and Tswa have been removed from the column with languages using specific code point, because IP thinks that they have low EGIDS, and these languages need not to be specified as reference. * 2. Following code points from Kabyle, Mundari and Tswa, where only these languages were specified as languages using these code points have been removed: * * 1E0D * * 1E25 * * 1E5B * * 1E91 * * 1E93 * I could not find in online resources any references where listed code points were used. If someone finds the reference for specific code point it can be always added later. * I have removed in References section, the references for Bavarian, Kabyle, Mundari and Tswa * I have added some text about principles for developing cross-script and in-script variants. This text should be corrected according to the principles we adopted during our previous Brussels meeting. * I have added explanation, that section References cannot be arranged as requested by IP, because the relevant data are not collected during language processing. All changes are recorded in the document: https://docs.google.com/document/d/1DhK_YyksaKbNtJ-vN_Q4gsucIpCUt80o2b01Ecc… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> 3. Variants finalization 4. Next telephone conference September the 6th 5. AOB Regards, Pitinan ---------------------------- Link to Adobe Connect: https://participate.icann.org/idn/ *Upon logging into Adobe Connect, a pop up window will provide you the option to Dial Out to your Phone. Enter your Phone Number* (Remember to change the Country Code if needed). After joining the call, as a courtesy to others and the presenters, please MUTE your phone. This can be done by selecting *6 on your keypad. To UNMUTE select *6 again. If you are Unable to log into Adobe Connect and can only join via phone: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=1064158692&num=1-719-… Participant Passcode: 1064158692

3 2

Agenda for Latin GP meeting on August the 30th, 2018
by Mirjana Tasić Aug. 30, 2018

Aug. 30, 2018

Dear GP members, Please find the Agenda for our today call. Regards Mirjana AGENDA for the GP call on August the 30th, 2018, 16:00UTC 1. Roll call 2. Progress of the work on Report I have made following changes to the Report document: * Languages Bavarian, Kabyle, Mundati and Tswa have been removed from the column with languages using specific code point, because IP thinks that they have low EGIDS, and these languages need not to be specified as reference. * 2. Following code points from Kabyle, Mundari and Tswa, where only these languages were specified as languages using these code points have been removed: * · 1E0D * · 1E25 * · 1E5B * · 1E91 * · 1E93 * I could not find in online resources any references where listed code points were used. If someone finds the reference for specific code point it can be always added later. * I have removed in References section, the references for Bavarian, Kabyle, Mundari and Tswa * I have added some text about principles for developing cross-script and in-script variants. This text should be corrected according to the principles we adopted during our previous Brussels meeting. * I have added explanation, that section References cannot be arranged as requested by IP, because the relevant data are not collected during language processing. All changes are recorded in the document: https://docs.google.com/document/d/1DhK_YyksaKbNtJ-vN_Q4gsucIpCUt80o2b01Ecc… 1. Variants finalization 1. Next telephone conference September the 6th 1. AOB

1 0

Re: [Latingp] From IP: Diacritics below a security risk?
by Bill Jouris Aug. 30, 2018

Aug. 30, 2018

I take a couple of things from this letter from the IP: - First, the IP considers security to be a major priority in our consideration of variants and/or confusibles. - In pursuit of that end, the IP considers it important whether users will be able to distinguish between code points. Especially when presented with only one code point, not two alternatives next to each other for comparison. The IP's note talks specifically about diacritics below the line. But those are hardly the only cases where this is an issue. Among languages written using the Latin script, pretty much all of them use the basic 26 letters (codepoints 0061 - 007A). But we have identified over 100 additional glyphs in our repertoire. All of those have one characteristic in common: The vast majority of Internet users are not familiar with a language which use them. Because they are not familiar with those code points, they will have a challenge distinguishing between them. Consider, just by way of example, these 4 code points:- ă (0103) - ǎ (01CE) - ā (0101)- ã (00E3) Someone who is not familiar with more than one of these will, inevitably, perceive the one that he is familiar with whenever presented with any of the 4. People see what they expect to see, what is familiar. That happens even when they might be physically capable of distinguishing between two points IF they were presented with them side-by-side. Because, in the kind of phishing attack discussed in the e-mail, they aren't presented with two options. They are presented by something that looks like what they are expecting to see, and don't see anything sufficiently amiss to doubt it. A similar exercise can be done with - è (00E8) - é (00E9) - ė (0117) Someone who is familiar with two of them can probably distinguish between those two. But someone who (like a far larger number of Internet users) is only familiar with one will see what he knows. And someone who (like the vast majority of Internet users who use the Latin script) is not familiar with any of them will only notice that there is something above the letter -- but not at all what that something is. This is not to say that every letter plus diacritic is a variant of that same letter with any other diacritic. Far from it. But what we do have is something like this. Take the letter A. Our repertoire includes 24 variations, which gives almost 290 pairs. Of those, one (0103 and 01CE) cannot be distinguished by eye at normal type sizes. But another 51 are close enough that a normal user (i.e. someone who is not a trained linguist, who has not spent the last two years immersed in the various Latin script code points) will readily mistake one for another. Now one might argue that all of those should be left as Confusibles. (Ignoring that detail that there are an additional 170 or so pairs which really are confusibles.) But what, exactly, is the benefit of refusing to acknowledge that they are variants? I confess I cannot see any benefit to the Internet user community of drastically constricting what we consider a variant. The closest thing to a benefit that I can see is that, by declining to spend the time actually checking the various pairs, we can finish sooner. But that is a benefit to us as individuals who are on the Latin GP; it isn't a benefit to the people who will be using the results of our efforts. Bill Jouris Inside Products bill.jouris(a)insidethestack.com 831-659-8360 925-855-9512 (direct) From: Sarmad Hussain <sarmad.hussain(a)icann.org> To: Latin GP <latingp(a)icann.org> Sent: Tuesday, August 28, 2018 11:58 PM Subject: [Latingp] From IP: Diacritics below a security risk? Dear Latin GP members Kindly find below some feedback from IP for your consideration. Regards Sarmad TO: LatinGP FROM: IP There are recent and widely published examples of phishing attacks using Latin IDNs in which the key features involved were diacritics below the letter. Here is an example: Of all diacritics, diacritics below can be difficult to distinguish or be prone to clipping -- there is less space below the baseline than between the typical lowercase glyph and the top of the line. The example given above shows a further interaction with URL underlining - and not all display engines actually do as nice a job interrupting the underline as in the screen shot above. For example, here is how one system will render this (using a designated UI font - Segoe UI): Note, this code point (U+1E33) is in the MSR as is (U+1E35 LATIN SMALL K WITH LINE BELOW). The second example contains U+1E35 -- while the effect does not show equally at all type sizes, from 12pt and below the LINE BELOW is reliably hidden. Here are the two examples at 10pt The issue is not limited to "K". We see "B", "D", "L" and "N" with both DOT and LINE BELOW and "M" and "H" with DOT BELOW, all on the same page in the MSR.It can be argued users have no working understanding of typography and would not reliably interpret small gaps or bulges in the underline as being related to an unfamiliar code point. This appears to make all diacritics below security-sensitive, however, the initial determination belongs to the relevant GPs. Note by the way that the Devanagari LGR treatssequences containing NUKTA (a dot below) as variants in at least some cases and recent community comments for that script are calling for more variant sequences. However, while the feature is graphically analog (dot below), each script works differently and there is no single a-priori solution. The IP would like to encourage the LatinGP (and any other GP facing cases like this) to explicitly examine this example and other cases like it, where code points can become indistinguishable in common usage scenarios for IDNs, and formally conclude whether and how to take these into account when designing their LGR. At this point, the IP would expect the GP to: * explicitly discuss this and other scenarios like it * evaluate whether they constitute a security risk to the Root Zone * come up with a reasoned decision as to whether and how to address them in the design of the Latin GP; and finally * document both the decision and its rationale.In coming to a decision, the GP may resolve:1) to make them variants2) to list them for attention as confusable 3) to take no action, because the GP feels that they do not represent a special security risk.As part of the review of the Latin LGR, the IP will look at the background and rationale offered by the Latin GP in coming to its conclusion; note that if the IP feels that the facts considered and rationale documented do not support the conclusion reached by the GP it may raise objections at that time. _______________________________________________ Latingp mailing list Latingp(a)icann.org https://mm.icann.org/mailman/listinfo/latingp

1 0

From IP: Diacritics below a security risk?
by Sarmad Hussain Aug. 29, 2018

Aug. 29, 2018

Dear Latin GP members Kindly find below some feedback from IP for your consideration. Regards Sarmad TO: LatinGP FROM: IP There are recent and widely published examples of phishing attacks using Latin IDNs in which the key features involved were diacritics below the letter. Here is an example: [cid:part1.E6E9F88C.32B00687@ix.netcom.com] Of all diacritics, diacritics below can be difficult to distinguish or be prone to clipping -- there is less space below the baseline than between the typical lowercase glyph and the top of the line. The example given above shows a further interaction with URL underlining - and not all display engines actually do as nice a job interrupting the underline as in the screen shot above. For example, here is how one system will render this (using a designated UI font - Segoe UI): [cid:part2.59964F92.16B1BC0B@ix.netcom.com] Note, this code point (U+1E33) is in the MSR as is (U+1E35 LATIN SMALL K WITH LINE BELOW). [cid:part3.99B9649E.C3C335FC@ix.netcom.com] The second example contains U+1E35 -- while the effect does not show equally at all type sizes, from 12pt and below the LINE BELOW is reliably hidden. Here are the two examples at 10pt [cid:part4.B43CE3FD.8C84EACF@ix.netcom.com] The issue is not limited to "K". We see "B", "D", "L" and "N" with both DOT and LINE BELOW and "M" and "H" with DOT BELOW, all on the same page in the MSR. It can be argued users have no working understanding of typography and would not reliably interpret small gaps or bulges in the underline as being related to an unfamiliar code point. This appears to make all diacritics below security-sensitive, however, the initial determination belongs to the relevant GPs. Note by the way that the Devanagari LGR treats sequences containing NUKTA (a dot below) as variants in at least some cases and recent community comments for that script are calling for more variant sequences. However, while the feature is graphically analog (dot below), each script works differently and there is no single a-priori solution. The IP would like to encourage the LatinGP (and any other GP facing cases like this) to explicitly examine this example and other cases like it, where code points can become indistinguishable in common usage scenarios for IDNs, and formally conclude whether and how to take these into account when designing their LGR. At this point, the IP would expect the GP to: * explicitly discuss this and other scenarios like it * evaluate whether they constitute a security risk to the Root Zone * come up with a reasoned decision as to whether and how to address them in the design of the Latin GP; and finally * document both the decision and its rationale. In coming to a decision, the GP may resolve: 1) to make them variants 2) to list them for attention as confusable 3) to take no action, because the GP feels that they do not represent a special security risk. As part of the review of the Latin LGR, the IP will look at the background and rationale offered by the Latin GP in coming to its conclusion; note that if the IP feels that the facts considered and rationale documented do not support the conclusion reached by the GP it may raise objections at that time.

1 0

Draft in-script variants
by Tan Tanaka, Dennis Aug. 28, 2018

Aug. 28, 2018

Dear Latin GP, Here is the compilation of current in-script variant candidates for our review during tomorrow’s call. https://docs.google.com/document/d/1bKKFHxbjgBd9CIPRiuOsej_3x670yTytUMM32Ou… Talk to you all soon. Best, -Dennis

3 11

Section numbering in Final report
by Mirjana Tasić Aug. 22, 2018

Aug. 22, 2018

Dear GP members, During upload of the new version of the report, Google docs used its own logic, and numbered our Table of content as section one. I have corrected this, now sections has right numbers as it is stated in Table of contents. Regards Mirjana

1 0