On November 3, 2016 at 10:50 evan@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 other documentation. 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 exists.
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 partial solution: 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 TMCH database. 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 organization. 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 registering WHO.BICYCLES. 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. In summary: 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. -- -Barry Shein Software Tool & Die | bzs@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*