Re: [soac-mapo] A proposal: GLOS

[Avri Doria <avri@xxxxxxx>]

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
>