[At-Large] R: IGO names: is this worth war?
bzs at TheWorld.com
bzs at TheWorld.com
Thu Nov 3 21:39:45 UTC 2016
On November 3, 2016 at 10:50 evan at telly.org (Evan Leibovitch) wrote:
> So... to industry, the domains of the Red Cross and its affiliates are merely a
> special form of trademark, just like Coca-Cola.
I only mentioned Coca-Cola to point out that at its base the issue of
trademark protection is consumer protection whether you are buying a
soft drink or donating to a charity.
The mechanism used on the web are higher-level SSL certificates on web
sites which, before being issued, verify they are being purchased by
the organization being represented via business listing agencies and
Unfortunately they haven't been very effective because people don't
tend to give much thought to, typically, a lack of certificate if they
are directed to a non-SSL URL.
And lower-level certificates w/o verification appear to be secure to
the site visitor, they just don't get a green bar or whatever it is.
I haven't seen any solution to that problem. "Education" feels like a
futile hand wave.
> From a public interest PoV, I posit that they are vastly different. Coca-Cola
> does not have a business model of soliciting charitable donations, in every
> country, for distribution in other countries. It is not depended upon for
> relief activity or critical medical-related public information. It is not
> recognized by the Geneva Conventions as a foundation of global humanitarian
> activity. Similar things can be said about a number of other international
> agencies (ie, UNICEF, WFP etc), though maybe not quite at that level.
> If ICANN's "community" wishes to maintain oblivion to the distinction between
> the ICRC and Coca-Cola, that is its right. But that should not stop those
> representing the public interest at ICANN -- governments and At-Large -- from
> asserting the distinction, and using whatever bylaw-allowed tools are at their
> disposal to encourage ICANN to balance industry needs with those of the
> non-domain-buying public. If the processes created by ICANN's compact of domain
> buyers and domain sellers -- the GNSO -- cannot accommodate that distinction,
> then the problem is in the process and not in the fact that a distinction
> If the response is that there are indeed specific IGOs -- that face the public
> directly and who trade in international public trust -- that deserve protection
> but that not all IGOs do, that is a reasonable response and IMO a foundation
> for compromise. I would be happy to participate in a group that created
> objective distinction criteria and/or identified the IGOs worthy of global
> protection. I don't think that more than a dozen or so IGOs meet this public
> trust criteria, but those that do are indeed worthy of special treatment.
> But a blanket blow-off of the request to protect at least some IGOs is a recipe
> for a needless showdown. The result of such open hostility will simply
> validate, and indeed expand, negative public perception of ICANN and plant the
> seeds for more Ted Cruz-like attack (which will play right into the hands of
> the multllaterals).
> - Evan
> PS: I am surprised why nobody here has mentioned the "int" TLD, and suggested
> as a partial solution the use and widespread promotion of it as a natural and
> trusted home for IGOs. ICANN's support of such a promotional campaign would
> actually increase its own public trust for it would be seen to recognize and
> address a real problem of abuse.
Blanket blow-off is a problem, of course they deserve better.
But none of this seems to suggest a solution, only reasons to strive
for some solution which in and of itself does have some value.
I think using the .INT TLD could be helpful but misses the main point
vis a vis WHO.BICYCLES etc.
To my understanding of the problem it's not that IGOs et al want some
identifiable domain, they want some way to stop fraudulent domains.
HOWEVER, the higher-level SSL cert could suggest something of a
Register IGOs et al in the TMCH database with a new flag which says to
register a domain in any nTLD using this registered string one must
present a validated SSL certificate identifying the organization
purchasing the string.
For example suppose WHO passes on WHO.BICYCLES, but "WHO" is in the
Another party comes along later and registers WHO.BICYCLES.
Since "WHO" is flagged as I described in the TMCH databases the
registrar must require a validated SSL certificate for that
There are some mechanical details (how does one get a validated
certificate before registering?) which I believe could be worked out.
Lack of such a validated certificate prevents the organization from
Presentation of a validated certificate at least provides some
positive identification of who is now trying to register WHO.BICYCLES.
And validated SSL certificates aren't easy to obtain by miscreants.
However, all this still provides no protection for "confusingly
similar" domains such as WHO-UN.BICYCLES if WHO-UN is not specifically
registered in the TMCH database.
All security amounts to avoidance, prevention, detection, recovery.
1. Can we avoid the problem beforehand?
2. Can we actually prevent the problem (stronger than "avoid").
3. Can we effectively detect there has been a problem?
4. Finally if a problem occurs is there a reasonable recovery
procedure in place?
The certificate suggestion I offered falls into #1, #3, and #4.
Avoidance: Makes it more difficult to register a confusingly similar
string (e.g., if one can't qualify for a validated SSL certificate)
Detection: Helps positively identify a suspected abuser.
Recovery: Provides evidence to take down the offending domain and
pursue remedies by identifying the abuser.
I realize someone will likely jump in here referencing real or
imagined flaws in validated SSL certificates procedures.
That may be so, and they continue to be a work in progress, but they
are a commonly available tool and have some merits in all this.
Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD
The World: Since 1989 | A Public Information Utility | *oo*
More information about the At-Large