Stop me if I've misunderstood...

Mark Davis ⌛ mark at macchiato.com
Wed Jul 8 23:09:18 CEST 2009


That is, in fact, the current outcome, because of two issues:

   1. There are 4 characters that are valid in both IDNA2003 and IDNA2008,
   but will direct to to different IP addresses. So if you send a friend a URL,
   he could end up going to a different site, if you have different browsers or
   different browser versions.
   2. There is a proposal to add a mapping to IDNAbis that would be "UI
   only", and optional. This is to handle user-expected variant differences:
   case, width,... That would also end up with problems with "bus-ability" in
   that whether a URL gets mapped is left up to the user-agent's choice, and
   what it thinks qualifies as "UI", and even whether the mapping is changed
   (the mapping is a SHOULD). And there is no current requirement that the
   mapping be compatible with IDNA2003, so we get the same problem as #1.

My opinion:

This is a rather bad situation -- for interoperability and security, let
alone the user experience -- but that people in this group just don't
realize it yet because they haven't gotten enough feedback from people who
are concerned with interoperability and security. In particular, I believe
that:

   1. We should have differences from the current state (IDNA2003) that
   cause a URL to go to a different site *only* if there is overwhelming
   justification and little negative impact.
      1. There is convincing evidence that this divergence is necessary for
      two characters: ZWJ, and ZWNJ. Fortunately these are extremely
low frequency
      characters in current URLs within web pages, so the negative
impact is quite
      limited.
      2. There is not overwhelming justification for the two others: es-zett
      (sharp S) and final sigma. As a matter of fact, the German NIC
has come out
      against the former. We do not have enough involvement from the Greek
      community to have any real case for the latter. And these are extremely
      frequent characters in the respective language communities.
      2. We should have a mandatory mapping applied to all lookup (whether
   "UI" or not "UI"), whereby for any cases where IDNA2003 also maps, they must
   have the same result. Failing that, we should not provide any mapping in
   IDNA.

Mark


On Wed, Jul 8, 2009 at 13:03, Gervase Markham <gerv at mozilla.org> wrote:

> I must confess that I've not had time recently to follow carefully the
> discussions about mappings. If that means that some people consign this
> message to the bit bucket, so be it.
>
> At the moment, standard domain names have what I'll call "bus-ability" -
> that is, if you see them in an advert on the side of a bus, you can
> write them down, type them into any web browser or other domain
> name-using client later, and you'll end up at the place intended by the
> creator of the advertisement. IDN domain names under the current version
> of IDN have, as far as I understand it, pretty much the same
> "bus-ability" property. In the IDN case, what the user types has to be
> first normalized, and then converted to punycode. The user in no way
> needs to know or care about this extra technical complexity. It just works.
>
> I would assert that this property is pretty key to keeping the web
> working in a sane and, importantly, secure manner. People convert domain
> names from print/voice/memory to computer and back all the time.
>
> If the standards were to change in such a way that it becomes quite
> legal and conforming that typing a set of characters into browser A
> takes you to website Q, but typing the same set into browser B takes you
> to website R, I would politely suggest that those who wrote the new
> standards had taken leave of their senses. This is a recipe for chaos.
> And phishing.
>
> This incredible outcome is not a serious possibility, is it?
>
> Gerv
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090708/7357d967/attachment.htm 


More information about the Idna-update mailing list