Quantcast

Unicode domain names issue (Encrypting a "fake" domain name)

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Unicode domain names issue (Encrypting a "fake" domain name)

Martin Heaps
I was led today to this article - https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/ - about the domain name 'www.epic.com' which can be written using unicode as 'www.xn--e1awd7f.com' to make a fake website look exactly like the URL of the real website.

There is a work around in Firefox for this, but possibly more seriously:

LetsEncrypt has a valid encryption certificate for the fake domain, and in Firefox the domain certificate (when clicking on the padlock icon to view the drop down box) still shows the processed unicode URL rather than the "raw" URL (showing that the Encryption certificate is for "epic.com" rather than "xn--e1awd7f.com" which is the domain given to LetsEncrypt).

This issue is clearly quite serious that certificate names can be manipulated to look like other names in certain situations, further undermining the value of the certificate as an authenticity check.

I would like this post to be a warning, and a sharing of this information, however the issue may well lay at the hands of browsers, but Certificate Authorities should have a premise with Browsers that their certificate addresses can and should only be shown in a set character set and never ever "interrepted" by the browser.

Article date: 14th April 2017.

Links:


- https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/

- https://www.xudongz.com/blog/2017/idn-phishing/

- https://www.reddit.com/r/netsec/comments/65csdk/phishing_with_unicode_domains/
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Martin Heaps

Sorry;  "interrepted" should be "interpreted" .
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Anne van Kesteren
In reply to this post by Martin Heaps
On Mon, Apr 17, 2017 at 4:38 PM, Martin Heaps <[hidden email]> wrote:
> LetsEncrypt has a valid encryption certificate for the fake domain,

It's not a fake domain, it just looks alike, but it's a valid domain
for all intents and purposes and Let's Encrypt should not do a
registrar's job. That registrars allow lookalikes to be assigned to
different entities is a problem.
https://bugzilla.mozilla.org/show_bug.cgi?id=1332714 tracks this.


--
https://annevankesteren.nl/
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Martin Heaps
In reply to this post by Martin Heaps
On Monday, 17 April 2017 16:54:27 UTC+1, Anne van Kesteren  wrote:

> On Mon, Apr 17, 2017 at 4:38 PM, Martin Heaps wrote:
> > LetsEncrypt has a valid encryption certificate for the fake domain,
>
> It's not a fake domain, it just looks alike, but it's a valid domain
> for all intents and purposes and Let's Encrypt should not do a
> registrar's job. That registrars allow lookalikes to be assigned to
> different entities is a problem.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1332714 tracks this.
>
>
> --
> https://annevankesteren.nl/

No, a clear destinction should be made; the certificate is for the domain "xn--e1awd7f.com" but in certain browsers this is presented to the user as "epic.com" . It may not be the certificates authority to provide trust to the user that the domain certified is valid; but they should as a bare minimum have an understanding with browser providers that the certificate name is not misconstrued in any way; and that a certificate for "xn--e1awd7f.com" can never be confused with applying to "epic.com".

THIS is the issue I am raising here.

The word "fake" is probably an inpracise word to use, but in the context that the domain name as registered is perporting to be another domain name it is not; this is fake. The SSL provider; LetsEncrypt in this case seems to not be able to ensure with browsers that there is a clear destinction between the two names of the domain certified by the CA.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Martin Thomson
On Tue, Apr 18, 2017 at 4:43 AM, Martin Heaps <[hidden email]> wrote:
> No, a clear destinction should be made; the certificate is for the domain "xn--e1awd7f.com" but in certain browsers this is presented to the user as "epic.com" . It may not be the certificates authority to provide trust to the user that the domain certified is valid; but they should as a bare minimum have an understanding with browser providers that the certificate name is not misconstrued in any way; and that a certificate for "xn--e1awd7f.com" can never be confused with applying to "epic.com".

Anne is right here.  But so also is Martin (I on the other hand cannot
claim any sort of authority).  Let's Encrypt have a firm policy here;
the line is grey and they are (rightly) uninterested in trying to set
where that line exists.  But a browser might be able to do
something... maybe.

This is a hard problem, because even if this case seems obvious,
others are much less so.  People want to use names they know and that
means using their native script.  There are things that a browser can
do, but the task of effectively communicating the true security status
of a site is one of the hard problems.

We're still open to ideas.  I've heard of many ideas, but the gap
between theory and practice is much larger in practice than we'd like.
For example, we could define a set of characters that form the native
script and warn if characters outside that script are used.  That
would work for browsers in an English-native locale, but would
disadvantage English-speakers from Japan in this particular example,
for whom both of these names appear to be special.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Gervase Markham
In reply to this post by Martin Heaps
On 17/04/17 19:43, Martin Heaps wrote:
> No, a clear destinction should be made; the certificate is for the
> domain "xn--e1awd7f.com" but in certain browsers this is presented to
> the user as "epic.com" .

This is perhaps a philosophical issue, but I see this viewpoint as
(perhaps inadvertently) telling users of non-Latin scripts that they are
second-class citizens.

A better way of looking at it is:

* The internet community wished to make all currently-used scripts
first-class citizens on the web, including allowing people to have
domain names in their own script

* It was discovered that the current DNS did not support using Unicode
directly for this purpose

* An encoding was developed such that domains in non-Latin letters could
be encoded using Latin letters

So the domain "epic.com" is actually the domain "epic.com". The fact
that it's encoded on the wire as "xn--e1awd7f.com" is an implementation
detail that, in ideal circumstances, should never be exposed to users.

> The word "fake" is probably an inpracise word to use, but in the
> context that the domain name as registered is perporting to be
> another domain name it is not; this is fake. The SSL provider;
> LetsEncrypt in this case seems to not be able to ensure with browsers
> that there is a clear destinction between the two names of the domain
> certified by the CA.

Neither browsers nor CAs have a database of all domain names, such that
they can see that one is visually confusable with another. Registries
have this data, and it is their responsibility to deal with this problem.

Gerv

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Igor Bukanov-2
In reply to this post by Martin Thomson
There is a difference between domains for non-latin scripts and an
xn-- domain that represents a name that can also be written using
plain latin letters. It is just too bad that registrars are allowed to
issues such certificates. So as a simple heuristic a browser can show
the domain as xn-- if it encodes a name that does not require xn--
encoding. Of cause that does not help when somebody uses
xn--eic-0ed.com which is eрic.com with the Cyrillic letter "р", but
that is a different and indeed hard to solve problems with homographs
in Unicode.

On 18 April 2017 at 09:34, Martin Thomson <[hidden email]> wrote:

> On Tue, Apr 18, 2017 at 4:43 AM, Martin Heaps <[hidden email]> wrote:
>> No, a clear destinction should be made; the certificate is for the domain "xn--e1awd7f.com" but in certain browsers this is presented to the user as "epic.com" . It may not be the certificates authority to provide trust to the user that the domain certified is valid; but they should as a bare minimum have an understanding with browser providers that the certificate name is not misconstrued in any way; and that a certificate for "xn--e1awd7f.com" can never be confused with applying to "epic.com".
>
> Anne is right here.  But so also is Martin (I on the other hand cannot
> claim any sort of authority).  Let's Encrypt have a firm policy here;
> the line is grey and they are (rightly) uninterested in trying to set
> where that line exists.  But a browser might be able to do
> something... maybe.
>
> This is a hard problem, because even if this case seems obvious,
> others are much less so.  People want to use names they know and that
> means using their native script.  There are things that a browser can
> do, but the task of effectively communicating the true security status
> of a site is one of the hard problems.
>
> We're still open to ideas.  I've heard of many ideas, but the gap
> between theory and practice is much larger in practice than we'd like.
> For example, we could define a set of characters that form the native
> script and warn if characters outside that script are used.  That
> would work for browsers in an English-native locale, but would
> disadvantage English-speakers from Japan in this particular example,
> for whom both of these names appear to be special.
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Henri Sivonen-2
In reply to this post by Gervase Markham
On Tue, Apr 18, 2017 at 12:29 PM, Gervase Markham <[hidden email]> wrote:
> Neither browsers nor CAs have a database of all domain names, such that
> they can see that one is visually confusable with another. Registries
> have this data, and it is their responsibility to deal with this problem.

Indeed, registries could normalize names first to remove diacritics
and then to map confusables to a canonical exemplar of each confusion
group (e.g. map Cyrillic о to Latin o or the other way round) and then
require that names that become the same under such confusability
normalization belong to the same registrant.

Sadly, it seems that .com in particular doesn't care and it seems that
ICANN doesn't care to require this kind of thing. Solving this would
require putting security ahead of greed at the ICANN level, and the
financial incentives (ability to make money by allowing confusing
names to be sold) go against security.

(I think ICANN's failure to solve this doesn't mean that CA policy
should try to solve this.)

--
Henri Sivonen
[hidden email]
https://hsivonen.fi/
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

L. David Baron
In reply to this post by Gervase Markham
On Tuesday 2017-04-18 10:29 +0100, Gervase Markham wrote:
> Neither browsers nor CAs have a database of all domain names, such that
> they can see that one is visually confusable with another. Registries
> have this data, and it is their responsibility to deal with this problem.

So we used to have a whitelist of registries that had sensible
policies for dealing with this, but we stopped using it in
https://bugzilla.mozilla.org/show_bug.cgi?id=843689 .

Should we enable the whitelist approach again?

(One of the big issues with it was that some of the most prominent
domains, like .com, had policies that we saw as unacceptable.)

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Daniel Veditz-2
In reply to this post by Igor Bukanov-2
On Tue, Apr 18, 2017 at 3:03 AM, Igor Bukanov <[hidden email]> wrote:

> So as a simple heuristic a browser can show
> ​ ​
> the domain as xn-- if it

encodes a name that does not require xn--encoding.


​Are there are no legitimate Russian words made only of the 11 or so
letters that look like latin script? Should we tell Russians (and
Ukrainians, Bulgarians, Kazakhs, etc) to get the hell off our American
Internet?​ Should the browser ship with dictionaries of words in those
languages (or a subset using only the confusable characters) and check that
a cyrillic domain name maps to a legit word? What about non-word brand
names? Or the other way checking against English: we could map 'epic' and
'apple' to latin script and find those in an English dictionary. But what
about 'plaece.com', a new hypothetical social brand? Or what if it's a
cyrillic German or French word?


> Of cause that does not help when somebody uses
> xn--eic-0ed.com which is eрic.com with the Cyrillic letter "р", but
> that is a different and indeed hard to solve problems with homographs
> in Unicode.
>

​That one is the easy case: mixing scripts is not allowed. It's extremely
unlikely to be legitimate (the toys-Я-us brand notwithstanding) and that
domain will only be shown in the punycode form​.

-
​Dan Veditz​
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Boris Zbarsky
In reply to this post by Martin Thomson
On 4/18/17 6:03 AM, Igor Bukanov wrote:
> There is a difference between domains for non-latin scripts and an
> xn-- domain that represents a name that can also be written using
> plain latin letters. It is just too bad that registrars are allowed to
> issues such certificates. So as a simple heuristic a browser can show
> the domain as xn-- if it encodes a name that does not require xn--
> encoding.

Note that this would not have helped with the "epic.com" case,because
the actual Unicode characters involved were not ASCII and hence did need
the xn-- encoding.

-Boris
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Eli the Bearded
In reply to this post by Igor Bukanov-2
In mozilla.dev.security, Daniel Veditz  <[hidden email]> wrote:
> > So as a simple heuristic a browser can show
> > the domain as xn-- if it
> encodes a name that does not require xn--encoding.
>
> Are there are no legitimate Russian words made only of the 11 or so
> letters that look like latin script?

The original example was one.

U+0435     е     CYRILLIC SMALL LETTER IE
U+0440     р     CYRILLIC SMALL LETTER ER
U+0456     і     CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I
U+0441     с     CYRILLIC SMALL LETTER ES

Which is a given name. It's better than the old ѕсоре example, which
doesn't seem to have any Russian look-a-likes.

Elijah
------
has seen ѕсоре.com next to рaypal.com in IDN warning documents
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Kai Engert-4
In reply to this post by Gervase Markham
Trying to come up with some ideas, without knowing the history of ideas already
discussed.

Could the browser UI always display the xn-- encoding in addition, if it isn't
plain ASCII, like:
  URL bar showing: https:// www. еріс .com (xn--e1awd7f.com)

If there's worry that the hostname could be very long, longer than the user's
display, which results in the trailing (xn--) not being inside the visible
display, maybe the URL bar display could alternate between showing the nicely
rendered hostname, and the xn-- name, for 2 seconds each?

Alternatively, could the URL bar show the name of the identified script?

https:// www. еріс .com (cyrillic)

Maybe "cyrillic" and the subset of the letters in that script could be displayed
using highlighting, like a different color (same color for the word cyrillic and
the cyrillic letters), or underlining?

https:// www. epic .com (cyrillic)
              ----       --------

How about indicating the script as part of the protocl? Absent means
latin/ascii.

https-cyrillic:// www. epic .com

Kai

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Kai Engert-4
How the ideas could look like with URLs that include a path:


On Tue, 2017-04-18 at 22:13 +0200, Kai Engert wrote:
> Trying to come up with some ideas, without knowing the history of ideas
> already
> discussed.
>
> Could the browser UI always display the xn-- encoding in addition, if it isn't
> plain ASCII, like:
>   URL bar showing: https:// www. еріс .com (xn--e1awd7f.com)

https:// www. еріс .com (xn--e1awd7f.com) /more/of/url.html


> If there's worry that the hostname could be very long, longer than the user's
> display, which results in the trailing (xn--) not being inside the visible
> display, maybe the URL bar display could alternate between showing the nicely
> rendered hostname, and the xn-- name, for 2 seconds each?
>
> Alternatively, could the URL bar show the name of the identified script?
>
> https:// www. еріс .com (cyrillic)
> Maybe "cyrillic" and the subset of the letters in that script could be
> displayed
> using highlighting, like a different color (same color for the word cyrillic
> and
> the cyrillic letters), or underlining?
>
> https:// www. epic .com (cyrillic)
>               ----       --------

https:// www. epic .com (cyrillic) /more/of/url.html
              ----       --------


> How about indicating the script as part of the protocl? Absent means
> latin/ascii.
>
> https-cyrillic:// www. epic .com

https-cyrillic:// www. epic .com /more/of/url.html

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Kai Engert-4
Another idea, inspired by the UI for sites having an extended validation (EV)
certificate:

If the URL isn't plain ASCII, but a better rendering is available, then display
the better rendering to the left of the URL bar, but display the URL itself in
plain xn-- style.

For an extended validation site that used non-ascii characters, the URL bar
could look like this:

[lock] [company name(country)] [cyrillic: epic.com] https://xn--e1awd7f.com/

non-EV:

[lock] [cyrillic: epic.com] https://xn--e1awd7f.com/

Highlighting could be used to make it likely that [cyrillic epic.com] is
properly noticed.

Maybe the extra term "cyrillic" isn't necessary, when this approach is used.

Given that the location to the left of the URL is already being used to display
browser determined/approved information, this could be seen as the appropriate
place to display pretty hostname renderings.

Given that the https:// location is a "technical" string, and given that the
underlying standards allow ascii characters here, only, maybe this could be an
acceptable compromise?

Kai

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Kyle Hamilton
In reply to this post by Kai Engert-4
Why not display the encoding of the host name in the area with the
security indicator, to the left of the address bar?  That is the area
where security-related displays are already made.

-Kyle H

On Tue, Apr 18, 2017 at 1:13 PM, Kai Engert <[hidden email]> wrote:

> Trying to come up with some ideas, without knowing the history of ideas already
> discussed.
>
> Could the browser UI always display the xn-- encoding in addition, if it isn't
> plain ASCII, like:
>   URL bar showing: https:// www. еріс .com (xn--e1awd7f.com)
>
> If there's worry that the hostname could be very long, longer than the user's
> display, which results in the trailing (xn--) not being inside the visible
> display, maybe the URL bar display could alternate between showing the nicely
> rendered hostname, and the xn-- name, for 2 seconds each?
>
> Alternatively, could the URL bar show the name of the identified script?
>
> https:// www. еріс .com (cyrillic)
>
> Maybe "cyrillic" and the subset of the letters in that script could be displayed
> using highlighting, like a different color (same color for the word cyrillic and
> the cyrillic letters), or underlining?
>
> https:// www. epic .com (cyrillic)
>               ----       --------
>
> How about indicating the script as part of the protocl? Absent means
> latin/ascii.
>
> https-cyrillic:// www. epic .com
>
> Kai
>
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Boris Zbarsky
In reply to this post by Kai Engert-4
On 4/18/17 4:52 PM, Kyle Hamilton wrote:
> Why not display the encoding of the host name in the area with the
> security indicator, to the left of the address bar?  That is the area
> where security-related displays are already made.

Here's a question that I think any proposal here should be able to
address:  Given two strings of glyphs, both non-ASCII, which are
homographs of each other, does the proposed solution help?

I think showing two different blobs of "xn--****" noise does not help
distinguish cases like that, unless someone is doing a careful
side-by-side comparison.

-Boris
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Kai Engert-4


On 18 April 2017 23:00:24 GMT+02:00, Boris Zbarsky <[hidden email]> wrote:
>Here's a question that I think any proposal here should be able to
>address:  Given two strings of glyphs, both non-ASCII, which are
>homographs of each other, does the proposed solution help?
>
>I think showing two different blobs of "xn--****" noise does not help
>distinguish cases like that, unless someone is doing a careful
>side-by-side comparison.

IIUC, Dan said, mixed scripts are always shown as xn--, never rendered.

I think that means, if thete are two different domains, that are rendered similarly, must originate from two different scripts.

If correct, then displaying the name of the script next to the rendering (cyrillic: epic.com) could be sufficient to allow them to be distinguished, without requiring comparison of the xn-- strings?

Kai
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Boris Zbarsky
In reply to this post by Boris Zbarsky
On 4/18/17 5:32 PM, Kai Engert wrote:
> IIUC, Dan said, mixed scripts are always shown as xn--, never rendered.

Who said anything about mixed scripts?

> I think that means, if thete are two different domains, that are rendered similarly, must originate from two different scripts.

Yes, correct.  Like the cyrillic/latin case here.

> If correct, then displaying the name of the script next to the rendering (cyrillic: epic.com) could be sufficient to allow them to be distinguished

To be clear, that wasn't the proposal I was replying to.

Will be display "Latin:" next to every non-punycode domain, so we're not
making non-English-speakers second-class citizens?

-Boris
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unicode domain names issue (Encrypting a "fake" domain name)

Kai Engert-4
In reply to this post by Kai Engert-4


On 18 April 2017 23:32:44 GMT+02:00, Kai Engert <[hidden email]> wrote:

>
>
>On 18 April 2017 23:00:24 GMT+02:00, Boris Zbarsky <[hidden email]>
>wrote:
>>Here's a question that I think any proposal here should be able to
>>address:  Given two strings of glyphs, both non-ASCII, which are
>>homographs of each other, does the proposed solution help?
>>
>>I think showing two different blobs of "xn--****" noise does not help
>>distinguish cases like that, unless someone is doing a careful
>>side-by-side comparison.
>
>IIUC, Dan said, mixed scripts are always shown as xn--, never rendered.
>
>I think that means, if thete are two different domains, that are
>rendered similarly, must originate from two different scripts.
>
>If correct, then displaying the name of the script next to the
>rendering (cyrillic: epic.com) could be sufficient to allow them to be
>distinguished, without requiring comparison of the xn-- strings?
>
>Kai

But it would require that users notice that the shown script name isn't the expected one.

Could the browser use the configured default language, to know the expected usual script, and use special hightlighting (looking like a warning) whenever the domain uses a non-matching script?

A user having configured russian as their language would see the term cyrillic in neutral display. Users not using a cyrillic language would see the term cyrillic with a visually emphasized highlighting.

Kai
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
123
Loading...