ICANN ICANN Email List Archives

[soac-mapo]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [soac-mapo] A proposal: GLOS

  • To: Avri Doria <avri@xxxxxxx>
  • Subject: Re: [soac-mapo] A proposal: GLOS
  • From: Stuart Lawley <stuart@xxxxxxxxxx>
  • Date: Wed, 1 Sep 2010 12:22:27 -0400

A list will not work for the reasons mentioned by Avri.
There is little chance that the list will be inclusive enough to include all 
derivatives and many would be submitters will be too squeamish (understandably) 
to submit many of the outrageous terms linked to subject like Pedophilia etc.


I do think however that it would be useful for this WG to discuss, in principle 
a list of potential real world applications  so that the various viewpoints 
within the group can put forward their views as to whether that "type' of 
string/application is going to fall under these challenges.

.GAY is a good example.


I dont think we should be coy about discussing and using as examples the 
"sensitive" strings we know will likely be applied for in the first round.



On Sep 1, 2010, at 10:18 AM, Avri Doria wrote:

> 
> Hi,
> 
> Thanks for the idea.
> 
> One of my concerns with the proposal is that the list would be infinitely 
> long.  Though perhaps with wildcarding, we could shorten its physical length.
> 
> Another is that I am concerned, and perhaps it is just the occasional 
> perversity of my mind and the variety of strings that occur to me, that some 
> of those strings could be so vile to some people we would not even be able to 
> post the list.  Just imagine ICANN posting a list of the all of the 
> objectionable strings we all can think of in every possible script and 
> language.  Might even be illegal in California (not sure) and we might need 
> to publish it in one of those Freedom of Speech havens.
> 
> a.
> 
> On 1 Sep 2010, at 10:02, Evan Leibovitch wrote:
> 
>> 
>> Hello everyone.
>> 
>> I have been reading many of the dialogues on this list with great interest. 
>> But I've not been participating because I've been working on an approach 
>> that I would like to suggest as worth trying. It allows for both 
>> identification (without limit) of objectionable strings and a commitment to 
>> freedom of expression. Moreover, it reduces ICANN's legal exposure while 
>> proposing a process that less complex, less time consuming, and less costly 
>> than the one currently in the DAG. And, best of all, ICANN has already used 
>> this approach in another contentious context.
>> 
>> The germ of this idea came out of my reaction to some of Antony's comments 
>> from Monday, I will provide detail if there is intrerest in the history. But 
>> for now I will simply introduce this proposal, which I call "GLOS" (at least 
>> as a working title).
>> 
>> 
>> GLOS is an abbreviation for "Global List of Objectionable Strings"
>> 
>> 1) GLOS would be a database populated with a list of strings that parties 
>> (both governmental and non-governmental) may deem harmful or objectionable  
>> to their members or citizens. The database could be operated by ICANN or an 
>> external services provider on its behalf.
>> 
>> 2) For each registered string, the submitter would indicate whether it is:
>> - universally objectionable (ie, under any circumstances)
>> - conditionally objectionable (ie, possibly objectionable depending on the 
>> applicant and/or the TLD's stated purpose)
>> - sufficiently objectionable that the country would likely increase 
>> police/security surveillance of the TLD (and possibly its subdomains)
>> - sufficiently objectionable that the country would likely block access to 
>> the string should it be approved
>> - sufficiently objectionable that the TLD's owners, operators and/or local 
>> agents may be subject to prosecution under local law
>> - sufficiently objectionable that the TLD may be the subject of boycotts, 
>> civil lawsuits or other community action
>> - other details TBD
>> 
>> 3) Each string entry in GLOS would be unique and discrete. That is, the 
>> existence of a string in GLOS explicitly does not allow imply that any 
>> translation, derivative or version in other IDN encodings is also 
>> objectionable. 
>> 
>> 4) Every TLD application would undergo a mandatory check against GLOS early 
>> in its application process, with the results being made publicly available. 
>> Such a report would make clear to any applicant (as well as its 
>> stakeholders/sponsors and service providers) the potential risks of extra 
>> scrutiny, prosecution risk and/or restricted audiences and markets. An 
>> applicant would know in advance how likely (and widely) they would be 
>> opposed should they proceed.
>> 
>> 5) Having presented the report to the applicant (who must acknowledge 
>> receipt and awareness before proceeding further in the approval process), 
>> ICANN itself will not introduce any further obstacles to the application 
>> based on content and makes no judgement on acceptability. The applicant can 
>> proceed with the rest of the application process but is well aware of any 
>> risks that lie ahead.
>> 
>> 6) Cost of maintaining the database is primarily borne by those entities 
>> that create entries in GLOS, preferably on a cost-per-entry basis. This 
>> provides a disincentive against large numbers of frivolous entries and 
>> prevents the database from growing stale (since every entry is renewed at 
>> intervals)
>> 
>> 7) ICANN will track and regularly publish data regarding the global blocking 
>> of TLDs. This will assist applicants and the public by providing a 
>> transparent view of any potential sources of instability, and will also note 
>> (without judgement) countries that opaquely bar strings without listing 
>> their objections on GLOS. While ICANN cannot force or influence governments, 
>> it can perform its mandare by educating the public and calling attention to 
>> potential problem areas. This allows stakeholders to hold their own 
>> governments and institutions accountable.
>> 
>> 8) Non-national-government organizations (religious bodies, cultural 
>> organisations, human rights agencies, regional/provincial governments, etc) 
>> may also add entries to the GLOS; however, they must also bear appropriate 
>> costs and will obviously lack the blocking and prosecution remedies of 
>> national governments.
>> 
>> 
>> In summary, in the context of MAPO I believe that ICANN can best serve its 
>> many communities in an advisory role rather than a judgemental one. Let all 
>> applicants know if their proposed strings offer a potential for trouble, 
>> then allow them to proceed as they wish. Probably most applicants will 
>> withdraw once they see that their proposal will lead to major restrictions 
>> in their potential audience, or even their own possible arrest; maybe their 
>> sponsors/investors will force them to reconsider a tamer approach. However, 
>> if provocation is exactly what the applicant wants, they will be aware of 
>> the consequences.
>> 
>> This also allows for far more of a bottom-up process than we have been 
>> discussing to date. The ability to submit objectionable strings is not 
>> limited to national governments. The applicant must evaluate both the source 
>> and severity of objections listed when considering the GLOS advisory report.
>> 
>> It also IMO has the potential to minimize ICANN's legal exposure. Not only 
>> is ICANN completely staying out of the role of comparing relative morality, 
>> it is providing warning to applicants intended to prevent their own legal 
>> and other consequences.
>> 
>> The existing ICANN approach of this kind to which I was referring is the 
>> Trademark Clearinghouse, which also acts in an advisory role and may not in 
>> it own capacity prevent any TLD from bring created. There are significant 
>> differences between it and GLOS  -- it relies on international treaty 
>> whereas GLOS does not, and submitting entries to the Clearinghouse requires 
>> evidence of entitlement. (By contrast, how does one prove "entitlement" to 
>> be offended?) However, the point here is that ICANN has already demonstrated 
>> a willingness to rely on processes which warn and educate applicants in 
>> preference to mere regulation and restriction. It is proactive rather than 
>> reactive, focusing on prevention rather than punishment.
>> 
>> We already know that countries that want to block will do so regardless of 
>> how elaborate or objective ICANN's processes turn out to be. The principle 
>> of universal accessibility of TLDs is already broken in current practice, 
>> and ICANN really has no control over countries' sovereign capabilities. 
>> Further, there is no punishment ICANN offer that is as harsh as jailing 
>> someone who created a TLD judged hateful (amongst those countries with 
>> hate-speech laws).
>> 
>> We have already realised that the determination of offensiveness is highly 
>> subjective, often politically motivated, and can vary widely from country to 
>> country, community to community, and even year to year. So let's cede 
>> ultimate responsibility for judgements on objectionable strings to 
>> governments -- where it rests anyway whether we like it or not -- and make 
>> sure that ICANN help its applicants fully understand the risks of proposing 
>> controversial TLDs while itself staying non-judgemental. Applicants (and the 
>> greater community) must be clearly made aware that the determination and 
>> fulfilment of the risks -- prosecution, surveillance, blocking, etc -- lie 
>> out of ICANN's control.
>> 
>> Comments?
>> 
>> - Evan
>> 
> 
> 





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy