W3C home > Mailing lists > Public > public-i18n-bidi@w3.org > July to September 2011

Re: PRI #185: Revision of UBA for improved display of URL/IRIs

From: Aharon (Vladimir) Lanin <aharon@google.com>
Date: Thu, 14 Jul 2011 16:44:02 +0300
Message-ID: <CA+FsOYYx127TS+KTEx-PTpLFv2ZdfDcvouxf76MjNfULvzS=Mg@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "public-i18n-bidi@w3.org" <public-i18n-bidi@w3.org>
I have submitted another comment to the UTC:

If I understand correctly, PRI #185 proposes modifying the UBA itself, so
all text to which the UBA is applied will reflect it. It also acknowledges
that it will not catch all IRIs, but only a useful subset. It also aims to
improve security, in particular making it more difficult to create malicious
IRIs that mislead the user into thinking that a different entity is being

Unfortunately, I see a problem satisfying all three of these simultaneously.
A malicious author could find an IRI that PRI #185 either does not recognize
as an IRI or thinks that it is an IRI followed by some normal text. Since
the ordering rules proposed by PRI #185 would then fail to apply to all or
part of the IRI, the IRI as displayed by the UBA would still mislead the
user into thinking that a different entity was being addressed. The
malicious IRI would look the same misleading way both in the text of an
document or email and in the browser's address bar, since the address bar is
doing nothing more than calling the usual UBA implementation on its

Perhaps a partial solution lies in requiring UBA implementations to allow
the caller to explicitly request that certain parts of the input text be
displayed under IRI rules (i.e. that field separators have a strong
direction), whether or not they look like an IRI to the UBA. Thus, the
browser address bar could explicitly tell the UBA that its entire text is an
IRI. The result would be that the malicious IRI would lose its misleading
effect at least when displayed in the browser address bar, hopefully being
noticed by the user before typing sensitive information into the page's

Received on Thursday, 14 July 2011 13:44:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:24:39 UTC