Browser IDN display policy: opinions sought

[Eric Brunner-Williams]

Apologies in advance. I wrote this note yesterday, and the note I
posted a few minutes ago this morning, after thinking about the "stale
knowledge" part of the solution proposed by Jonathan Frakes.

Eric

> (1) Most browser vendors ...

are likely to implement independent policy evaluations, as mailer and
mail filter vendors did circa 2002 when one or more then new
namespaces were ... not to their taste, and as a major mail and
resolver response to a event not addressed by some source of policy
(sitefinder and the fixes).

> Convincing them that
> they should not be worried about such threats is probably a lost
> cause.

they may not share a critical material dependency with other sources
of policy, particularly those interested only in a small subset of the
several suites of technologies these vendors are primarily concerned with.

> (2) ... it is fairly
> clear that the potential for confusion with a 37 character
> repertoire is far less than the potential with a repertoire of
> circa 50K characters or more. 

demonstrably true where the registration policy allows replication of
the ownership and use patterns established in the .com namespace.

counter-examples may exist where the registration policy does not
allow replication of the ownership and use patterns established in the
.com namespace.

> (3) If protection is going to be offered via ...

it is likely to take more than a single form.

> (4) Thare is actually an IDNA2008 requirement that registries
> handling IDNs establish policies for the strings that they are
> willing to accept for registration.

the motivation for conformance is variable. for a set of registries a
source of motivation exists, at least in theory.

> (5) Independent of how it is accomplished --or whether, in
> today's environment, it can be accomplished at all-- it is clear
> that the problems that could be evaluated and protected against
> at the client UI end of things would be much reduced if there
> were effective push-back against, or prevention of, deliberately
> problematic registrations and delegations of names.

several similar observations have been made in the past.

the circa 2004/2005 .cat registry operator implemented a registration
restriction policy which did (and continues) not allow replication of
the ownership and use patterns established in the .com namespace.

the circa 2009 IRT made, inter alia, an implementable recommendation.

the GAC has on several occasions made recommendations to this effect.

the FTC last week made just such a recommendation.

these recommendations have not been adopted by registrars, nor by
registries, while they remain outside the contractual obligations of
these entities to a source of policy. the necessity for repeatedly
making such policy recommendations may arise from the absence of
acceptance of such by a policy adopting entity of some relevance to
our problem domain, though, as i noted earlier, they have been adopted
by more registry operators than just the operator of .cat.

from where i sit it seems quite reasonable for application vendors to
be "policy aware" and distinguish between any two namespaces with
substantively distinct registration (and related, eventually we could
get to default TTLs and tolerance of fast flux hosting and other
well-known features of the landscape), and signal that to their users
or whatever consumes state and logic their applications produce.

after all, if browser vendors are expected to distinguish between
signed and unsigned zones and their leaves, why shouldn't they
distinguish between zones based upon other empirically observable
semantic differences?

-e