headers
John C Klensin | 1 Mar 03:12

Re: Re: character tables


--On Sunday, 27 February, 2005 20:19 -0800 Erik van der Poel
<erik <at> vanderpoel.org> wrote:

> John C Klensin wrote:
>> 
>> 	(i) ICANN is still assuming that this is a registry
>> 	issue.  As such, if someone else starts guessing at what
>> 	a registry is doing, we may get into trouble, especially
>> 	since the tables may not show all of the relevant
>> 	registry rules and restrictions.
> 
> Hmmm... GNU libidn already seems to be trying to use
> machine-readable tables. I had a look at the GNU libidn page:
> 
> http://www.gnu.org/software/libidn/
> 
> It has a copy of an expired Internet Draft by Paul Hoffman:
> 
> http://josefsson.org/cgi-bin/rfcmarkup?url=http://josefsson.or
> g/cgi-bin/viewcvs.cgi/*checkout*/libidn/doc/specifications/dra
> ft-hoffman-idn-reg-02.txt
> 
> This draft seems to be talking about bundling and blocking,
> which your draft talks about too. What happened here? Did Paul
> decide to let his expire?

Yes.  Paul more or less gave up (he can explain that decision; I
won't try to do it for him), then generously consented to the
inclusion of some of his text and definitions, and even more of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam M. Costello | 1 Mar 08:02

Re: something a little lighter for the weekend

Doug Ewell <dewell <at> adelphia.net> wrote:

> There may be 52 scripts currently encoded in Unicode, but I am sure
> Unicode does not claim that is the total number of scripts in the
> world.  Others can and will be encoded.

Michel Suignard <michelsu <at> windows.microsoft.com> wrote:

> The 2 current amendments of ISO/IEC 10646 (The ISO sibling of Unicode)
> being processed are adding about 10 new scripts.  And a new amendment
> will be initiated in September with few more scripts.  Any scheme
> based on a finite number of scripts is doomed.

Of course the number 52 would not be hard-coded into the policy.  It
would be expressed as "the number of Unicode scripts supported by the
latest version of IDNA".

Unicode tends to grow linearly, not exponentially, so that shouldn't
present a scaling problem.

AMC
Permalink | Reply | 1 comment |
headers
Gervase Markham | 2 Mar 12:50
Picon
Favicon
Gravatar

Re: nameprep2 and the slash homograph issue

Erik van der Poel wrote:
> Here I agree with you. I'm not going to try to come up with the wording 
> for that, but this morning I started to think that the right-to-left DNS 
> and IDN spoofing problems *could* be addressed at the UI level by 
> providing a *tool* that security-conscious users could *choose* to use.

While security-conscious users are always less at risk than ordinary 
users, thinking in terms of a tool is IMO wrong.

> I'm thinking of a tool that might be implemented as an extension for 
> Mozilla, for example. It would offer to display domain names in the safe 
> order, i.e. left-to-right for users whose main language is 
> left-to-right. I have not heard of any UIs that offer top-to-bottom in 
> their menus, dialogs, etc, so I would guess that this would be omitted 
> in the extension too, though right-to-left might be offered for 
> right-to-left users (many of which are in the Middle East -- Hebrew and 
> Arabic).

The problem this is supposed to mitigate is mitigated in Firefox by the 
domain-only indicator in the status bar.

> In addition, such a tool would offer to display domain names in a clear 
> font, unlike the sans-serif that is commonly used today. This would make 
> the distinction between lowercase l and digit 1 clearer. And it would 
> separate the domain name from its context, e.g. using color.

Assuming we could determine such a font, why would we not always use it? 
Why wait for a tool to be deployed?

Gerv
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gervase Markham | 2 Mar 12:55
Picon
Favicon
Gravatar

Re: process

Erik van der Poel wrote:
> 1. Is this the right time to start working on Internet Drafts leading up 
> to new version(s) of the IDNA RFC(s)? If not, when?

IMO, no. Nothing like consensus has yet emerged. However, I feel that 
the way forward will become clear eventually - we aren't going round in 
circles. It's just a big issue.

Gerv
Permalink | Reply | 0 comments |
headers
Gervase Markham | 2 Mar 13:03
Picon
Favicon
Gravatar

Re: Re: character tables

Paul Hoffman wrote:
> Yes. It turned out to be a bad idea that got more complicated and less 
> justifiable (that is, worse) with each rev, so I let it die. Others 
> (notably JET) tried different things.

Paul,

Could you tell us more about the problems you found with the ideas of 
bundling and blocking?

Gerv
Permalink | Reply | 11 comments |
headers
Paul Hoffman | 2 Mar 01:16
Picon
Gravatar

Re: Re: character tables

At 12:03 PM +0000 3/2/05, Gervase Markham wrote:
>Could you tell us more about the problems you found with the ideas 
>of bundling and blocking?

It was impossible to come up with a bundling scheme that kept 
everyone happy. The needs of the Chinese language communities for 
bundling were different than the needs of the Scandinavian language 
communities, which in turn were different than the needs of the Indic 
language communities, which were different than the needs of the 
Arabic language communities, and so on. Then toss in the communities 
that truly want multiple scripts but want to avoid homograph attacks 
(yes, we really did think about that years ago...), and your brain 
starts dripping from your ears.

Other folks with more brains or who are less prone to dripping are 
welcome to try to fix this for the world, or at least for one 
community as the JET folks did.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 10 comments |
headers
Erik van der Poel | 2 Mar 02:05

Re: nameprep2 and the slash homograph issue

Gervase Markham wrote:
> While security-conscious users are always less at risk than ordinary 
> users, thinking in terms of a tool is IMO wrong.

Perhaps I was wrong to use the word "tool". There is a fundamental 
tension between security and user-friendliness. Some applications and 
vendors have a history of making their user interfaces *too* friendly, 
thereby neglecting to warn users of potential security risks. Other 
vendors have tried hard to strike a balance between security and 
seamlessness. I believe Netscape and Mozilla have been in this camp 
since Day One.

I hope that mozilla.org will deploy a better solution than the TLD and 
domain black/whitelists that have been discussed.

>> It would offer to display domain names in the 
>> safe order, i.e. left-to-right for users whose main language is 
>> left-to-right.
> 
> The problem this is supposed to mitigate is mitigated in Firefox by the 
> domain-only indicator in the status bar.

I just double-checked Firefox 1.0.1, and it just says "Done" at the 
lower left. Then I tried a secure (https) site, and, lo and behold, I 
saw the "domain-only" indicator at the lower right, next to the padlock 
icon. This is very good news (to me). And thank you for educating this 
particular user (me) about this security issue. As I have often said, 
education is key.

A couple of questions/comments: It might be nice to have this
(Continue reading)

Permalink | Reply | 2 comments |
headers
Erik van der Poel | 2 Mar 02:48

Re: Re: character tables

Paul Hoffman wrote:
> At 12:03 PM +0000 3/2/05, Gervase Markham wrote:
> 
>> Could you tell us more about the problems you found with the ideas of 
>> bundling and blocking?
> 
> It was impossible to come up with a bundling scheme that kept everyone 
> happy. The needs of the Chinese language communities for bundling were 
> different than the needs of the Scandinavian language communities, which 
> in turn were different than the needs of the Indic language communities, 
> which were different than the needs of the Arabic language communities, 
> and so on. Then toss in the communities that truly want multiple scripts 
> but want to avoid homograph attacks (yes, we really did think about that 
> years ago...), and your brain starts dripping from your ears.

Yes, as a long-time internationalization engineer, I can imagine that it 
was difficult to come up with a single set of guidelines for all of the 
world's registries. (In addition to language differences, some comments 
on this list have led me to believe that there are also protocol 
differences between the registries, i.e. VeriSign's multiple versions of 
RRP vs the EPP that Edmon Chung seems to have been working on vs fax and 
sneaker net vs any others?)

However, I note that this particular conversation is between a browser 
developer (Gervase) and one of the IDNA authors (Paul), neither of which 
is a registry representative, so why exactly are you 2 having this 
conversation? :-)

Sorry, I'm half joking. Half, because you two have every right to 
discuss whatever you wish. The other half because I believe browser
(Continue reading)

Permalink | Reply | 9 comments |
headers
Erik van der Poel | 2 Mar 05:47

Re: Re: character tables

> However, I note that this particular conversation is between a browser 
> developer (Gervase) and one of the IDNA authors (Paul), neither of which 
> is a registry representative, so why exactly are you 2 having this 
> conversation? :-)
> 
> Sorry, I'm half joking. Half, because you two have every right to 
> discuss whatever you wish. The other half because I believe browser 
> developers can afford to focus more on their end of things.

Sorry, I've been told that this half-joking thing was confusing, and I 
now believe I shouldn't have tried to be so cute.

All I'm trying to say to *Gervase* is that it doesn't really matter 
*what* characters are allowed to be registered in a registry, as long as 
the browser takes steps to warn the user when something phishy might be 
going on, e.g. a slash homograph, or a Cyrillic small 'a' when the user 
was probably expecting a Latin small 'a'. As I have pointed out, the 
registry does *not* have control over higher-numbered level domains. 
E.g. .de controls the 2nd level domain (2LD), but not the 3LD, 4LD and 
so on. That is where the slash homograph problem *really* matters.

> Instead, I wish the browser developers would 
> focus more on the *user*, who may be "surfing" from one site to the 
> next, spanning the globe, and crossing language boundaries.

Sorry, this may not have been the best logic to use in my argument. It 
would have been better to talk about phishers, who often spam users with 
email containing URIs that *could* contain IDN labels with dangerous 
homographs at any level of the name, 2LD, 3LD, or whatever.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Gervase Markham | 2 Mar 09:56
Picon
Favicon
Gravatar

Re: nameprep2 and the slash homograph issue

Erik van der Poel wrote:
> Perhaps I was wrong to use the word "tool". There is a fundamental 
> tension between security and user-friendliness. 

Well, maybe. I'm not convinced the tension is absolute, but I agree you 
need to work very hard indeed to get both.

> A couple of questions/comments: It might be nice to have this 
> domain-only display even for non-secure sites (http).

We are probably going to change this for 1.1. It takes some careful 
thought so as not to confuse people.

> Also, do you know 
> what happens if the domain name is very long? 

It just gets very long, currently.

> Finally, do you have any 
> thoughts about the slash homograph problem? Thanks.

Well, the current domain indicator will show the domain, slash 
homographs and all. We're still developing our response, but it's likely 
that we'll have to blacklist this character. Opera's new beta already 
has a small set of characters it doesn't allow.

Ideally, we wouldn't be acting unilaterally on this one, and would be 
doing the restrictions based on consensus. But before we can go there, 
we need to figure out what we think is needed first. That process is 
still going on.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane