Why Using TLDs for Filtering is Ineffective, Harmful, and Unnecessary
There have been proposals to the ICANN to create top-level domains such as
".xxx" (See the ICM Registry
fact sheet on their .xxx proposal) or ".adult" for "adult material" and ".mobile" for content that has
been tailored to the characteristics of mobile devices (e.g., that have small
screens and less memory than a desktop computer). In this paper we survey the
reasons why creating new top-level names as a means for creating subdivisions
of the Internet is ineffective,
harmful, and
unnecessary. This paper
summarizes some of the issues raised by
the creation of content- or
device-oriented top-level domains; it provides little detail.
This document represents the opinions of the author, or more
precisely, summarizes what the author has understood from discussions
on this topic that have taken place as part of the author's work at
W3C. This document does not represent the consensus of any W3C group
or the W3C as a whole. It is a draft document and may change at any
time.
On the surface, the primary reason for creating a top-level domain such as
".xxx" is to allow software to filter content more easily that some might
deem offensive to themselves or their children. Top-level domains do not
allow effective filtering for the following reasons:
- Creating ".xxx" provides no guarantee that all "offensive" material
will be confined to these domains. Policing the Internet to ensure that
no such material appears outside of ".xxx" is difficult and costly
due to complications of International law and the sheer size of the
Internet.
- Similarly, creating ".mobile" provides no guarantee that all material
in the ".mobile" domain will be well-suited for mobile
devices. Indeed, it would be highly undesirable to create a
top-level domain where only a small set of publishers controlled
the content published in those domains.
- Perhaps initially, searching and filtering will be improved as
the space is filled by content from large mobile
providers. Over time, it will become difficult to ensure that
deployed content evolves with changes in technology.
Ultimately, the utility of a site depends on other factors than the
domain name; trust derives from reliability and persistence, which are
social issues, not technological issues. ICANN should not mislead the
public by setting expectations that become more difficult to
satisfy over time and as the amount of content and number of
content providers increase. ICANN should not mislead policy
markers by suggesting that certain technical approaches may solve
social issues.
- Arbitrary boundaries undermine
persistence over time, as technology and society evolve. A bare
ankle one hundred years ago may have ended up classified as .xxx.
- Many entities with an established presence in existing domains such as
".com" would be unlikely to "pack up and move" to ".xxx"; this would be
disruptive to their business. Instead, they would likely purchase a new
domain name in ".xxx" and maintain their ".com" presence
(e.g., by redirecting requests to the .com name to .xxx). Filters based
on the name alone (as opposed to information available through the
transfer protocol) would miss the connection.
- Anyone can register a domain name and map it to an arbitrary IP
address. Thus, I could register "takethat.xxx" and point it at my
competitor's site "teddybears.example.org". This would likely fool
filters based on ".xxx" to keep out legitimate requests for information
at teddybears.example.org.
- The definition of what is offensive obviously differs greatly from
country to country, from year to year, and from person to person. If bare
ankles are considered obscene in some cultures, but are permitted in
photos of Web sites in France selling sandals, then individuals wishing
to keep photos of bare ankles out of their home using filtering on ".xxx"
are unlikely to succeed. How will sites about safe sex or AIDS be
treated? Who will establish what is art and what is pornography?
- Companies protect their trademarked names. IBM is likely to purchase
"ibm.xxx" to protect their trademark (not to mention that they would
certainly be loathe to allow pornographers to own "ibm.xxx"). The
creation of new top-level domains leads to a rush to rent domain names,
which is burdensome and imposes extra cost.
- Suppose a ".mobile" domain is created for content tailored to mobile
devices. Suppose also that ".xxx" is created and ICANN mandates that all
sexually explicit material appear in that domain. What does that mean for
content providers that wish to provide sexually explicit material that is
tailored to mobile phone users? Suppose that China mandates that all
businesses put content in the ".cn" domain. What should a Chinese adult
shop do? Experience shows that deriving information from content
(e.g., google) or metadata is a more effective approach than
embedding metadata in names. Strict association of content types
with names does not scale.
- Device-independent design promotes robust content that may be
repurposed in many contexts, some of which the designer may not even
have foreseen. For instance, content that does not rely on the
capabilities of a particular environment (e.g., a desktop computer
with a large color monitor) is more likely to be usable in a variety
of other environments, such as on mobile devices, by people with some
disabilities, and in environments that may appear in five or ten
years. Creating a special area of the Web "just for mobile content"
may have the effect of reducing the flexibility of general-purpose
content. This will have a negative effect on a number of communities,
including users of mobile devices, who may find themselves only able
to access a limited portion of what the Web has to offer. A more
constructive approach to improving the experience of users with mobile
devices is to make all content flexible. Device-independent
design saves money for content providers who only have to manage one
copy and one URI, instead of multiple sites for different
devices. Content designed this way is also generally easier to
maintain over time. Users also benefit since more of the Web
becomes available to them in more environments.
- Attempts to create subdivisions of the Internet based on content may
very well lead to privacy violations. It is easy to imagine some
governments monitoring users who seek out information in a ".xxx"
domain. In the case of ".mobile", I may want some users to know that
my Internet-enabled point-of-access is a cell phone, while I don't
want others to know; putting metadata into the name limits my
flexibility (not to mention limiting number portability).
- Adding a top-level domain for each special interest is likely to lead
to substantial burden in administration of the DNS, as well as increase
the likelihood of error and failure. Using the DNS to create a
centralized "yellow pages" of content types is very likely to
fail. Indeed, one reason the Web has succeeded is that it does
not mandate a single classification: no single classification
of content
types or device types or other topics will meet the needs of every
community. The Web allows each community to maintain a
presence in the way best-suited to that community, unconstrained
by the needs of other communities.
- It is a strength of the Web today that it is possible to reuse much
content in a variety of situations. Subdividing the Web not only requires
increased effort by content providers (to build many specific Web sites
instead of one generally useful Website), it increases the burden on
software developers (who may have to implement multiple standards), and
inconveniences users (who may not be able to access content because they
don't have the "right" piece of hardware, software, or human capability.
Attempts to subdivide the Web have failed because ultimately the end user
loses (cf. the "browser wars" and the defunct WAP Forum). Part of
the value of the Web derives from there being one
Web.
- RFC 1591 set expectations about how the initial top-level domains were
to be used. In particular, ".com" was intended for "commercial entities"
and ".org" was intended for "miscellaneous" organizations. In practice,
today there is no real distinction between ".com" and ".org" and nobody
cares or is inconvenienced by that fact. For instance, ibm.org simply
redirects to "ibm.com". Also, when I seek to register a domain name, I am
usually given the choice of one or all of "myfav.org", "myfav.net", or
"myfav.com". The top-level domain doesn't matter to me; what matters to
me (for purposes of branding) is the part that comes before the top-level
domain. Other examples: ".tv"
- Experience shows that the companies prefer ".com" for their
primary top level domain in the market. Some companies in Germany
use domain names ending in ".ag", but not as their primary domain
name since it is less familiar to people than ".com".
- Companies can design their content to work well on multiple devices,
including mobile devices. This can be achieved through existing
technologies such as style sheets [CSS].
- Companies can identify content that is suited for mobile devices using
existing protocols, such as Composite Capability/Preference Profiles
[CCPP]. If they wish for the word "mobile" to appear in the name, they
can already create "mobile.mycompany.com".
- Client-side filtering products are widely available.
- Companies can use metadata labeling mechanisms more
effectively.
- Registrars
- In the case of .xxx, pornographers.
Professional pornographers benefit from
improved branding, likely
safe harbor from legal woes, and there is likely to be a decline
in "amateur" pornography as some people may not wish to migrate to the
new TLD.
- [CCPP]
- Composite
Capability/Preference Profiles (CC/PP): Structure and Vocabularies
1.0, W3C Recommendation, G. Klyne et al., 15 January
2004.
- [CSS]
- Cascading Style Sheets,
Level 2, W3C Recommendation, B. Bos et al., 12 May 1998.
- [RFC 1591]
- Domain Name
System Structure and Delegation, IETF RFC 1591, J. Postel,
March 1994.
- [RFC 3675]
- .sex Considered
Dangerous, IETF RFC 3675, D. Eastlake 3rd, Motorola
Laboratories February 2004.
- [TIMBL-TLD]
- New top
level domains considered harmful, Tim Berners-Lee essay.
The author has gathered material from a variety of sources,
including discussions within the W3C Team, the W3C Technical
Architecture Group (TAG), with Joseph Reagle, with Andrew McGlaughlin,
and from RFC3675. The comments
sent to the ICANN Forum on the .mobi proposal were also very
interesting. Those comments and this summary intersect somewhat, but
also raise important points about the proposed
organizational structure, DNS behavior, and anti-trust.
Ian Jacobs, W3C
Last modified: $Date: 2000/01/01 00:06:47 $ by $Author: ijacobs $