[At-Large] On a "consumer" agenda for ICANN

[Carlton Samuels]

Aye. I know all of those. Afterall, we worked together long enough and
crafted enough statements together where these elements were ID'ed in
context.

But you misconstrued the meaning of the phrase "*withdrawal from**
interaction and use*"!  It really means total cutoff. For even with those
pathways, some maladies would remain live. A new set of actors, all
clustered around data collection and usage, emerge as principal
antagonists.  We are mired in some of the facebook, Google etc issues
already.

My interest is and remains the development agenda. Withdrawal from
"*interaction
and use of the DNS*" is not an option for those of us committed to that
agenda.

-Carlton


==============================
*Carlton A Samuels*

*Mobile: 876-818-1799Strategy, Planning, Governance, Assessment &
Turnaround*
=============================

On Fri, Sep 2, 2016 at 10:05 AM, Evan Leibovitch <evan at telly.org> wrote:

> On 2 September 2016 at 15:36, Carlton Samuels <carlton.samuels at gmail.com>
> wrote:
>
>
>> They could vote with their feet and coin, by withdrawal from interaction
>> and use of the DNS. I should think none of us consider that a viable
>> option.
>>
>
> ​Actually it absolutely is viable, in a manner consistent with what I have
> been saying for many years. And you of all people should know this by now
> :-)
>
> When someone uses a search engine to look for a destination by name or
> caretgory, they are withdrawing from (direct) use of the DNS.​
>
> When someone goes to the Facebook, Google+, Twitter or Linkedin page of a
> destination by name, they are withdrawing.
>
> When someone uses URL shorteners, or QR codes, or mobile apps, they are
> withdrawing.
>
> [ And yes I know that ultimately the above solutions still require some
> kind of name resolution. However these approaches don't require human
> readable-names or working only at the second level, meaning they could all
> be easily serviced within a single TLD and require not a single extra
> second-level domain to be bought. ]
>
> Not only is withdrawing from using "memorable domain names" viable, for
> many it is preferred. I know that I personally use full domain names almost
> never in my day-to-day use of the Web these days. Google facilitated it by
> enabling the bar at the top of Chrome
> <http://www.chromefans.org/chrome-tutorial/what-is-omnibox.htm> to be
> used interchangeably for domain names and search terms; I would argue that
> the Omnibox is a significant reason why Chrome is now more popular than all
> other browsers combined (62% share as of June 2016).
>
> Search engines can be location aware, they can avoid typo-squatting by
> suggesting the right spelling for words, and you don't have to remember the
> oddball TLD for a company that couldn't get its desired .com. Search
> engines were multi-character-set-aware long before domain names (and
> continue to be more diverse in language scripts compared to IDNs). And
> since search is Google's main source of revenue, the company is heavily
> motivated to make it as attractive as possible to end users. By contrast,
> the domain name industry's business model depends not in maximum utility to
> end users, but in greatest possible rent-seeking and speculative value
> extracted from registrants.
>
> ICANN maintains oblivion from this reality by refusing to measure the
> extent of this withdrawal in the context of "Consumer Choice". But
> consider: forsaking "valuable" domain names is a choice both for end users
> (how they reach Internet-delivered content and services) and registrants
> (do they pay the speculator's ransom to get their preferred choice of
> domain name, or do they just get a less-intuitive domain name and invest in
> SEO or a Facebook landing page?)
>
> This option is HIGHLY viable for end users and service/content providers.
> It is not viable for the domain industry since a single TLD could easily
> serve it all, and there are no fees going to ICANN, registries or
> registrars for growth of names at the third level or deeper.
>
> - Evan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://atlarge-lists.icann.org/pipermail/at-large/attachments/20160902/2595f9b9/attachment-0001.html>