- UA-discuss - lists.iana.org

Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
by nalini.elkins＠insidethestack.com April 24, 2017

April 24, 2017

> From: Andrew Sullivan <ajs(a)anvilwalrusden.com> > Subject: Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...] > To: ua-discuss(a)icann.org > Date: Saturday, April 22, 2017, 9:16 AM > On Sat, Apr 22, 2017 at 01:32:08PM +0000, nalini.elkins(a)insidethestack.com wrote> >> For example, you may wish to see the following permutations which have already been obtained. (And, it appears not by Apple) >> >> www.applé.com www.xn--appl-epa.com www.xn--appl-epa.com >> www.applê.com www.xn--appl-jpa.com www.xn--appl-jpa.com >> www.applė.com www.xn--appl-yva.com www.xn--appl-yva.com >> www.applę.com www.xn--appl-8va.com www.xn--appl-8va.com > > Do you think that those qualify as "homographs"? I suppose they might, as might àpple.com and so on, but these at least don't seem to > me to be any different than app1e.com, which we decided long ago was Apple's problem and nobody else's. I guess so. It is just that because of internationalization, so many more of such permutations are possible. I think it might be useful to have another term for this: Here is an attempt: Homograph: a domain name that has characters that are visually indistinguishable (I am intentionally leaving out the font issues) Resembler: a domain name that can be easily visually confused for another well-known domain >From talking to various organizations, "Resemblers" are very definitely a concern. Whether this should be a policy from ICANN, someone else, or left to independent software vendors ala NaliniResemblerAndHomographFinder (tm), is an interesting question. > > This is quite different to the case of true homoglyphs of the sort that Asmus is talking about, where the very same glyph is normally > used in two different scripts such that nobody would be able to tell the difference. One maybe could argue that "аррӏе" is pure homoglyphs > (0430,0440,0440,04CF, 0435), but I think it's tough to argue for it. > > Remember, the IDNA rules are really _quite_restrictive, and if registries also require "same script per label" those restrictions > catch an _awful_ lot of corner cases (that was the outcome of the "paypal" controversy some time ago). > > If you want to argue that policy should be different, that's fine, but it seems to me to require some PDP within ICANN. Note that ICANN is > probably going to propose some rules for variant handling, and combined with the LGR stuff that is working its way through the system > we may find an awful lot of stuff is blocked. One of my guys is working in the LatinGeneration panel if that is what you are talking about. So far, I believe they are at the TLD level. > > In any case, I think our purpose is very badly served by conflating these two different kinds of issues. > Sure.

11 15

Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
by nalini.elkins＠insidethestack.com April 24, 2017

April 24, 2017

--- On Fri, 4/21/17, Andrew Sullivan <ajs(a)anvilwalrusden.com> wrote: > From: Andrew Sullivan <ajs(a)anvilwalrusden.com> > Subject: Re: [UA-discuss] IDN Implementation Guidelines [RE: Re : And now about phishing...] > To: ua-discuss(a)icann.org > Date: Friday, April 21, 2017, 11:42 AM > Hi, > > On Fri, Apr > 21, 2017 at 02:11:37PM +0000, nalini.elkins(a)insidethestack.com > wrote: > > I am certainly in agreement in not living in a fact-free world. So, I am collecting data on such sites. I am in the process of setting up a server > > to monitor 24 x 7 with a homographic domain finder product that we have written. > > > > Is that the homograph finder you had before? I seem to recall discussing some limitations it had some while ago; have those been fixed? > Yes, it is indeed NaliniHomographFinder(tm). And, yes, we have made some changes. As this is a proprietary (not open source) solution, I can only say so much about what we have done. I will make some of our monitoring available for free. For example, you may wish to see the following permutations which have already been obtained. (And, it appears not by Apple) www.applé.com www.xn--appl-epa.com www.xn--appl-epa.com www.applê.com www.xn--appl-jpa.com www.xn--appl-jpa.com www.applė.com www.xn--appl-yva.com www.xn--appl-yva.com www.applę.com www.xn--appl-8va.com www.xn--appl-8va.com You may look up the domain owner for these domains at: https://www.internic.net/whois.html Nalini

4 3

Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
by Asmus Freytag (c) April 23, 2017

April 23, 2017

On 4/22/2017 9:24 PM, ajay(a)data.in wrote: > Take a look at this paragraph. Can you read what it says? All the > letters have been jumbled (mixed). Only the first and last letter of > ecah word is in the right place: > > I cnduo't bvleiee taht I culod aulaclty uesdtannrd waht I was rdnaieg. > Unisg the icndeblire pweor of the hmuan mnid, aocdcrnig to rseecrah at > Cmabrigde Uinervtisy, it dseno't mttaer in waht oderr the lterets in a > wrod are, the olny irpoamtnt tihng is taht the frsit and lsat ltteer > be in the rhgit pclae. The rset can be a taotl mses and you can sitll > raed it whoutit a pboerlm. Tihs is bucseae the huamn mnid deos not > raed ervey ltteer by istlef, but the wrod as a wlohe. Aaznmig, huh? > Yaeh and I awlyas tghhuot slelinpg was ipmorantt! > Try out with friends. If they can that too. > > Some clue from above ? The clue from the above is that most people do not read "letter-by-letter" most of the time, but based on word-shape - and the latter is pretty resilient to alterations in sequences. If we had limited identifier to dictionary words, 90% of non-homograph spoofing would disappear, because many of the spoofs that look like words, aren't in the dictionary. If this weren't the case (and most of the jumbles were words themselves), you couldn't read the scrambled text above, because it would then look like a different text. We didn't adopt this, so we have to look at other means to defend against attacks. The interesting thing is that the letter shapes still matter. Note that the example doesn't simply keep first and last and then substitutes different letters. That means that the use of diacritics, for example, remains highly distinctive; because the marks change the "outline" of the word. A likely exception to that are populations accustomed to expecting diacritics to be optional. Note also, that while you can figure out the intended content of the above text quickly (that is you can "read" it, rather than having to decrypt it letter-by-letter, it still is immediately detectable as being "funny" (misspelled). (Also, the test may be skewed towards English, because there are so many short words in English - all the one, two and three-letter words are retained, and the four-letter words have precisely one possible alternation). Anything that you see in the example that you shared with us? A./

1 0

Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
by ajay＠data.in April 23, 2017

April 23, 2017

Take a look at this paragraph. Can you read what it says? All the letters have been jumbled (mixed). Only the first and last letter of ecah word is in the right place: I cnduo't bvleiee taht I culod aulaclty uesdtannrd waht I was rdnaieg. Unisg the icndeblire pweor of the hmuan mnid, aocdcrnig to rseecrah at Cmabrigde Uinervtisy, it dseno't mttaer in waht oderr the lterets in a wrod are, the olny irpoamtnt tihng is taht the frsit and lsat ltteer be in the rhgit pclae. The rset can be a taotl mses and you can sitll raed it whoutit a pboerlm. Tihs is bucseae the huamn mnid deos not raed ervey ltteer by istlef, but the wrod as a wlohe. Aaznmig, huh? Yaeh and I awlyas tghhuot slelinpg was ipmorantt! Try out with friends. If they can that too. Some clue from above ? On 23-Apr-2017, 00:25:54 Asmus Freytag 'asmusf(a)ix.netcom.com' wrote: On 4/22/2017 9:16 AM, Andrew Sullivan wrote: > > On Sat, Apr 22, 2017 at 01:32:08PM +0000, nalini.elkins(a)insidethestack.com (mailto:nalini.elkins@insidethestack.com) wrote> > > > > For example, you may wish to see the following permutations which have already been obtained. (And, it appears not by Apple) www.applé.com (http://www.appl%C3%A9.com) www.xn--appl-epa.com (http://www.xn--appl-epa.com) www.xn--appl-epa.com (http://www.xn--appl-epa.com) www.applêcom (http://www.appl%C3%AA.com) www.xn--appl-jpa.com (http://www.xn--appl-jpa.com) www.xn--appl-jpa.com (http://www.xn--appl-jpa.com) www.applė.com (http://www.appl%C4%97.com) www.xn--appl-yva.com (http://www.xn--appl-yva.com) www.xn--appl-yva.com (http://www.xn--appl-yva.com) www.applę.com (http://www.appl%C4%99.com) www.xn--appl-8va.com (http://www.xn--appl-8va.com) www.xn--appl-8va.com (http://www.xn--appl-8va.com) > > Do you think that those qualify as "homographs"? I suppose they might, as might àpple.com and so on, but these at least don't seem to me to be any different than app1e.com, which we decided long ago was Apple's problem and nobody else's. The claim that letters with diacritics are homoglyphs of the undecorated letters is rather tenuous. There are some words where diacritics are optional in some languages, and for those words, even a native reader may not notice the difference in spelling, but that is not all that different from "color" vs. "colour". A slightly stronger case might be made that some diacritics are not reliably distinguished from each other. Cedilla and comma below come to mind. There are plenty of examples, mostly in print, that show the use of one in place of the other, even if the language ostensibly calls for a specific one and not the other. Their shapes are not so different that the substitution would always be jarring. Extending that, it's generally the diacritics below that are less readily distinguished from each other; partially that's because there's less real estate in the glyph (and the bottom of the line may be clipped by the following line of text if the spacing is too tight). The real issue with diacritics is when multiple ones are applied to a base letter. While they are supposed to stack neatly outward in the order that they are entered, there isn't room enough at the bottom of the glyph to show that reliably. Also, sometimes diacritics "overprint" instead of stacking. From a perspective of making IDNs universally acceptable, registries should be encouraged to restrict the use of dual diacritics unless central to the writing system, as it is for Vietnamese. The Unicode principle of allowing all combinations is fine for general texts (or more likely, academic texts), but misplaced for identifiers. > > This is quite different to the case of true homoglyphs of the sort that Asmus is talking about, where the very same glyph is normally used in two different scripts such that nobody would be able to tell the difference One maybe could argue that "аррӏе" is pure homoglyphs (0430,0440,0440,04CF, 0435), but I think it's tough to argue for it. "арр" / "app" or "аре" / "ape" would be true homographs (always identical), but the palochka (04CF - "ӏ") is at best a near homoglyph. It renders identical in many fonts, even though it can be rather distinct in others (especially certain console fonts). Since those console fonts are a minority, the Palochka should probably be treated conservatively as a homoglyph. > > Remember, the IDNA rules are really _quite_ restrictive, and if registries also require "same script per label" those restrictions catch an _awful_ lot of corner cases (that was the outcome of the "paypal" controversy some time ago). If you want to argue that policy should be different, that's fine, but it seems to me to require some PDP within ICANN. Note that ICANN is probably going to propose some rules for variant handling, and combined with the LGR stuff that is working its way through the system we may find an awful lot of stuff is blocked. Actually, you can block "an awful lot" and yet not affect the universe of valid labels very much. A case in point is Ethiopic, which for linguistic reasons I won't go into, is best handled by treating a number of code points internal to the script as variants of each other (making them mutually exclusive if they occur as alternates in otherwise identical labels). The linguistic reasons apply, strictly speaking, only to one of the languages (albeit the most prominent one). The concern was raised how that would interfere with the ability to register labels in other languages. For the TLD IDN project we ran an analysis over a corpus of unique words, separated by language. We found that the reduction in available labels was much less than one might have guessed from the considerable number of variants. The reductions came to a few percent, much less than the effect of the languages sharing words that happened to be spelled the same (e.g. like English/French "but" or Englis/German "also"). The main reason for this is that legitimate labels would tend to contain at least one distinct code point, enough to prevent the label from being blocked. (Just as "dapple" is no longer a homograph of any Cyrillic string even if "apple" is.) The other reason is many strings that would otherwise be homographs do not make sense in the other context, and therefore are much less likely to be used for legitimate labels (and only used for phishing). Just like the string "аррӏе" (using Cyrillic code points) makes no sense to anyone using a language written in Cyrillic. For short labels, acronyms etc. might increase the set of legitimate labels beyond the word analysis we were doing, but it would be instructive to run such experiments on Latin/Cyrillic corpora assuming the widest definition of homoglyph variants; if those corpora are not limited to dictionary words, but include names, brands and acronyms, that would yield a pretty reliable estimate. I predict that the overlap will prove smaller than feared, for the same reasons that we found for Ethiopic, some high visibility exceptions notwithstanding. > > In any case, I think our purpose is very badly served by conflating these two different kinds of issues. Agreed. Our purpose is best served by making careful distinctions among these: - identical renders same in all fonts and sizes - near identical may not be perfectly identical but almost - not reliably distinct may be distinct if shown side by side or in some contexts - confusingly similar close enough that it can get misidentified - similar everything else that is not clearly distinct My take is that there is a call for addressing the first two at the level of an LGR (registry policy) and that the third requires some judgement call on whether it's more like the first two, or more like the latter two. A./ > > Best regards, A

1 0

Re : And now about phishing...
by deepak April 22, 2017

April 22, 2017

Hi, These are homoglyph character http://homoglyphs.net/ which can be use in phishing .. RegardsDeepak Singhal From: "Dusan Stojicevic" MailId : [68261406]To: "ua-discuss" Subject: [UA-discuss] And now about phishing...Date: 19 Apr 2017 12:24:34 AM Interesting and possible> https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/ Cheers, Dusan Virus-free. www.avast.com Do not Remove:[HID]20170419002433157[-HID] [XGENFOOTER] [-XGENFOOTER]

11 16

IDN Implementation Guidelines [RE: Re : And now about phishing...]
by Edmon Chung April 22, 2017

April 22, 2017

Starting a separate thread to focus on the IDN Implementation Guidelines Discussion. For the Draft IDN Guidelines you pointed to, please do submit your comments into the still open public comments period (recently extended): https://www.icann.org/public-comments/idn-guidelines-2017-03-03-en To the specific issue of wholescript confusables, there is a further explanation in point 17 why the current recommendation is a "may" rather than a "must"... But if we feel strongly it should move to a must, please do submit your comments in. As for our work at UASG, I feel that it is probably a good idea to collect the counter arguments. I recall there was a phishing/security report a couple years ago that highlighted the issue and indicated that while this (used to be "paypal" example), is possible it is hardly an issue statistically. Does anyone have that report/link? Edmon From: ua-discuss-bounces(a)icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Vittorio Bertola Sent: Friday, 21 April 2017 17:04 PM To: ua-discuss(a)icann.org; Asmus Freytag <asmusf(a)ix.netcom.com> Subject: Re: [UA-discuss] Re : And now about phishing... Il 21 aprile 2017 alle 0.52 Asmus Freytag <asmusf(a)ix.netcom.com <mailto:asmusf@ix.netcom.com> > ha scritto: If you think about it, the following recommendation at the end is anathema to "Universal acceptance": "Zheng is encouraging Firefox users to limit their exposure to the bug by going to the browser’s about:config settings and setting network.IDN_show_punycode to true. By doing this Firefox will always display IDN domains in its Punycode form, something that should make it easier to identify malicious domains, the researcher claims." If you do that, you implicitly assume that only the "non-IDN" links are "real", in other words, you assume an English-only environment. (When stuff is displayed as punicode, you usually can't tell what domain it is, except you can guess for some European ones with very few special characters, but you can't be sure unless the Unicode form is at least also displayed, which I think is not what that config change means). Hello, excuse me if I jump into a discussion having just joined the list, but this issue is really troubling me for at least two reasons. First, many news sources are now filling up with calls and guides for disabling IDNs in browsers altogether, which is a death call for universal acceptance. It all started with this horrible post by Wordfence's CEO, basically equating IDNs to an instrument conceived for phishing: https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/ It would be really good if anyone knew him and could have a chat with him, maybe even convince him to help spreading a better view of the issue. Secondly, browser makers are now reacting in opposite ways: 1) Microsoft's browser (AFAIK) will enable or disable the display of Unicode in the URL bar depending on the operating system's language; 2) Google's browser, with a newly released patch, will not display Unicode IDNs in ASCII TLDs if the IDNs are whole-script confusables ( https://codereview.chromium.org/2683793010 ); 3) Mozilla's browser will explicitly always display Unicode IDNs regardless of whether this may be used for phishing ( https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ <https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ> and https://bugzilla.mozilla.org/show_bug.cgi?id=1332714 ). However, multiple online sources are now advising people to use a Firefox configuration option that allows to disable the display of IDNs altogether. (Don't know about Apple, Opera and others.) As you see, this is going to hamper the usability of IDNs in URLs and, even worse, make it entirely unpredictable, depending on the user's browser choice. The only real solution to this is that all registries treat whole script confusables as variants, so that they cannot be registered to anyone different than the owner of the equivalent ASCII domain. Unicode TR-39 allows to do this programmatically. However, I just checked the proposed draft IDN guidelines that are currently undergoing public consultation at ICANN: https://www.icann.org/en/system/files/files/draft-idn-guidelines-03mar17-en… At point 16, they say that the registry "may" do this, but that should really be a "must". If this does not happen, there will be more of these situations and the risk that all the Western world will then disable IDNs in URLs for good is quite significant. I think that this group could do several useful things: a) promote a better public understanding of the issue, countering the trend that "IDN URLs are for phishing"; b) encourage browser makers to elaborate a common approach; c) push for ICANN and the registries to free the Internet from whole-script confusables. Regards, -- Vittorio Bertola Research & Innovation Engineer Cell: +39 348 7015022 Skype: in-skype-ox(a)bertola.eu <mailto:in-skype-ox@bertola.eu> Email: vittorio.bertola(a)open-xchange.com <mailto:vittorio.bertola@open-xchange.com> Twitter: @openexchange <http://twitter.com/openexchange> - Facebook: OpenXchange <https://www.facebook.com/OpenXchange> - Web: www.open-xchange.com <http://www.open-xchange.com> Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth Chairman of the Board: Richard Seibt European Office: Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 Managing Directors: Frank Hoberg, Martin Kauss US Office: Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.

3 2

Re: [UA-discuss] IDN Implementation Guidelines [RE: Re : And now about phishing...]
by nalini.elkins＠insidethestack.com April 21, 2017

April 21, 2017

Edmon, > it is hardly an issue statistically I am certainly in agreement in not living in a fact-free world. So, I am collecting data on such sites. I am in the process of setting up a server to monitor 24 x 7 with a homographic domain finder product that we have written. I can tell you from my initial testing that there are a surprising number. Currently, they appear to be for domains which are known world-wide. More as it happens... Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. www.insidethestack.com (831) 659-8360 -------------------------------------------- On Fri, 4/21/17, Edmon Chung <edmon(a)registry.asia> wrote: Subject: [UA-discuss] IDN Implementation Guidelines [RE: Re : And now about phishing...] To: "'Vittorio Bertola'" <vittorio.bertola(a)open-xchange.com>, ua-discuss(a)icann.org, "'Asmus Freytag'" <asmusf(a)ix.netcom.com> Date: Friday, April 21, 2017, 3:15 AM Starting a separate thread to focus on the IDN Implementation Guidelines Discussion. For the Draft IDN Guidelines you pointed to, please do submit your comments into the still open public comments period (recently extended):https://www.icann.org/public-comments/idn-guidelines-2017-03-03-en To the specific issue of wholescript confusables, there is a further explanation in point 17 why the current recommendation is a "may" rather than a "must"... But if we feel strongly it should move to a must, please do submit your comments in. As for our work at UASG, I feel that it is probably a good idea to collect the counter arguments. I recall there was a phishing/security report a couple years ago that highlighted the issue and indicated that while this (used to be "paypal" example), is possible it is hardly an issue statistically. Does anyone have that report/link? Edmon From: ua-discuss-bounces(a)icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Vittorio Bertola Sent: Friday, 21 April 2017 17:04 PM To: ua-discuss(a)icann.org; Asmus Freytag <asmusf(a)ix.netcom.com> Subject: Re: [UA-discuss] Re : And now about phishing... Il 21 aprile 2017 alle 0.52 Asmus Freytag <asmusf(a)ix.netcom.com> ha scritto: If you think about it, the following recommendation at the end is anathema to "Universal acceptance":"Zheng is encouraging Firefox users to limit their exposure to the bug by going to the browser’s about:config settings and setting network.IDN_show_punycode to true. By doing this Firefox will always display IDN domains in its Punycode form, something that should make it easier to identify malicious domains, the researcher claims."If you do that, you implicitly assume that only the "non-IDN" links are "real", in other words, you assume an English-only environment. (When stuff is displayed as punicode, you usually can't tell what domain it is, except you can guess for some European ones with very few special characters, but you can't be sure unless the Unicode form is at least also displayed, which I think is not what that config change means).Hello,excuse me if I jump into a discussion having just joined the list, but this issue is really troubling me for at least two reasons.First, many news sources are now filling up with calls and guides for disabling IDNs in browsers altogether, which is a death call for universal acceptance. It all started with this horrible post by Wordfence's CEO, basically equating IDNs to an instrument conceived for phishing:https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phis… would be really good if anyone knew him and could have a chat with him, maybe even convince him to help spreading a better view of the issue.Secondly, browser makers are now reacting in opposite ways:1) Microsoft's browser (AFAIK) will enable or disable the display of Unicode in the URL bar depending on the operating system's language;2) Google's browser, with a newly released patch, will not display Unicode IDNs in ASCII TLDs if the IDNs are whole-script confusables ( https://codereview.chromium.org/2683793010 );3) Mozilla's browser will explicitly always display Unicode IDNs regardless of whether this may be used for phishing ( https://wiki.mozilla.org/IDN_Display_Algorithm_FAQ and https://bugzilla.mozilla.org/show_bug.cgi?id=1332714 ). However, multiple online sources are now advising people to use a Firefox configuration option that allows to disable the display of IDNs altogether.(Don't know about Apple, Opera and others.)As you see, this is going to hamper the usability of IDNs in URLs and, even worse, make it entirely unpredictable, depending on the user's browser choice.The only real solution to this is that all registries treat whole script confusables as variants, so that they cannot be registered to anyone different than the owner of the equivalent ASCII domain. Unicode TR-39 allows to do this programmatically. However, I just checked the proposed draft IDN guidelines that are currently undergoing public consultation at ICANN:https://www.icann.org/en/system/files/files/draft-idn-guidelines-03ma… point 16, they say that the registry "may" do this, but that should really be a "must". If this does not happen, there will be more of these situations and the risk that all the Western world will then disable IDNs in URLs for good is quite significant. I think that this group could do several useful things:a) promote a better public understanding of the issue, countering the trend that "IDN URLs are for phishing";b) encourage browser makers to elaborate a common approach;c) push for ICANN and the registries to free the Internet from whole-script confusables.Regards,-- Vittorio Bertola Research & Innovation Engineer Cell:+39 348 7015022Skype:in-skype-ox@bertola.euEmail:vittorio.bertola@open-xchange.com Twitter: @openexchange - Facebook: OpenXchange - Web: www.open-xchange.comOpen-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738 Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth Chairman of the Board: Richard Seibt European Office: Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 Managing Directors: Frank Hoberg, Martin Kauss US Office: Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.

5 7

UASG - Linkification Review
by Don Hollander April 21, 2017

April 21, 2017

Thank you for those who have responded to the recent Doodle Poll on availability. The time with most people available is the time of this call. Please review these documents before the meeting. Quick Guide to Linkification<https://community.icann.org/download/attachments/56990805/UASG010%20Quick%2…> Linkification in UASG007 <https://uasg.tech/wp-content/uploads/2016/05/UASG007-version-9-2017-02-02.p…> Help Wanted Ad - Evaluation <https://uasg.tech/wp-content/uploads/2016/11/Help-Wanted...-Linkification-E…> Thank you. Don

1 0

UASG @ ICANN59 meeting - Johannesburg
by Don Hollander April 20, 2017

April 20, 2017

Please note for planning purposes, that the UASG is NOT planning any activities at the ICANN meeting in Johannesburg. This is a short meeting and very policy focused. We are planning on participating in the ICANN60 meeting in Abu Dhabi. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

2 1

Re : And now about phishing...
by deepak April 19, 2017

April 19, 2017

Hi, thanks for sharing this phishing technique . but it can be handle easily in email server . RegardsDeepak Singhal From: "Dusan Stojicevic" MailId : [68261406]To: "ua-discuss" Subject: [UA-discuss] And now about phishing...Date: 19 Apr 2017 12:24:34 AM Interesting and possible> https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/ Cheers, Dusan Virus-free. www.avast.com Do not Remove:[HID]20170419002433157[-HID] [XGENFOOTER] [-XGENFOOTER]

4 3