Re: [soac-mapo] A proposal: GLOS

[Carlton Samuels <carlton.samuels@xxxxxxxxx>]

My friend and colleague has presented a nifty attempt to square the circle
but as you look at the details, you'd see why it becomes problematic.

It is the objection enterprise itself that is incorrigible. Vest power in
some person or entity - mullah, ICANN morality czar or do-good quango - to
be the sole interpreter of the string will always give the same result; a
squalid suppression of rights to which we are born.

Carlton

==============================
Carlton A Samuels
Mobile: 876-818-1799
Strategy, Planning, Governance, Assessment & Turnaround
=============================


On Wed, Sep 1, 2010 at 9:02 AM, Evan Leibovitch <evan@xxxxxxxxx> 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
>
>