What rules have been used for the current list of codepoints?
Gervase Markham
gerv at mozilla.org
Fri Jan 5 17:05:43 CET 2007
Martin Duerst wrote:
> At 19:06 06/12/15, Gervase Markham wrote:
>> This is the policy that Firefox adopts; we currently display IDN domain
>> names for around 30 TLDs, the registries for all of which have
>> anti-spoofing policies. Any registry with such a policy is welcome to
>> ask to be included in the list, and we will ship the list change in our
>> next security update.
>
> I don't like this, because it's technology policing policy, and
> it could be misused in all kinds of ways. It may put a heavy
> burden on browser makers: Is 'any policy' good enough? Checking
> the policy takes work. Where do you draw the line between good
> policies and 'not good enough' policies?
The line's really not that hard to draw in practice. I agree it's work,
but there's currently no better solution. And it has the massive
advantage of allowing each registry maximum flexibility to adapt their
IDN policy and acceptable character set to local conditions.
> Do you check not only
> for the existence of a policy, but also for actual implementation/
> enforcement? If yes, how? If not, why not?
Not actively; we rely on user-based policing. But we feel registries
have a strong incentive to comply with their own policies. After all,
having us issue a security update and all of your IDN customers come
screaming at you because their IDNs no longer work in Firefox isn't good
for business. Particularly as the upside (a few tens or hundreds of
dollars from a few more domain sales) is so small.
> What if a registry
> has a very good policy, but doesn't make every detail of it
> public?
Then we assess them on what is public. Those who rely on these policies
for security (registrants, browser users) have a right to know what they
are.
> Why do you think you know, better than others, what the
> right policy is?
Because it's not rocket science. A specified, limited set of characters
and either no confusables, or a bundling/blocking policy.
> Do you reserve the right to retract a TLD from the
> list even if their policy doesn't change, but you find out that
> it left some loophole open?
Yes.
> And how long does it take to get a
> security update out,
See our release record for details; it can be a few weeks, or a few days
if there's a big rush (which there wouldn't be for an addition, although
there might be for a removal).
> and how does the need for a security update
> negatively affect the deployment of IDNs?
Hopefully not too much. We have a very good percentage of upgraders
because of the auto-upgrade mechanism. But the sooner registries get in,
the more ubiquitous support for them will be.
>> It should not need to be the user's responsibility to avoid
>> being taken in.
>
> Well, yes, but ultimately, users have to learn that there are
> some dangers on the Internet, the same way visitors to the US
> (and most other countries) have to learn that there are some
> places you better don't go to.
Indeed. But the places you'd better not go to are generally pretty
obvious in real life, whereas the entire point of the problem on the
Internet is they are near-indistinguishable from the safe places.
Gerv
More information about the Idna-update
mailing list