- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Thu, 14 Jul 2011 16:44:02 +0300
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "public-i18n-bidi@w3.org" <public-i18n-bidi@w3.org>
- Message-ID: <CA+FsOYYx127TS+KTEx-PTpLFv2ZdfDcvouxf76MjNfULvzS=Mg@mail.gmail.com>
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 addressed. 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 contents. 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 inputs. Aharon
Received on Thursday, 14 July 2011 13:44:46 UTC