<nettime> Ippolita Collective: The Dark Face of Google (Appendix 2)

["Patrice Riemens" <patrice@xs4all.nl>]

NB this book and translation are published under Creative Commons license
2.0 (Attribution, Non Commercial, Share Alike).
Commercial distribution requires the authorisation of the copyright
holders: Ippolita Collective and Feltrinelli Editore, Milano (.it)


Ippolita Collective: The Dark Side of Google (continued)


Appendix 2:  Twilight Zones: Influence and Domination in the Digital World.


Google's Open Source projects are also hosted on sourceforge.net.
There are no significant differences between the sourceforge.net site
and Google's code.google.com, just a few superficial variations in
the graphics. Projects are identical down to the slightest detail,
both code- and interface-wise. The only difference worth noticing
is at the host server level: on code.google.com the name of the
project comes after a dash ('code.google.com/xxx', whereas it's
'projectname.sourceforge.net', a so-called third level domain address.
There are thus two separate and independent accesses to the same
'interzone', yet these interzones belong to two distinct entities:
Google.com and sourceforge.net [This is no longer the case, all Google
F/OSS projects are now exclusively hosted on code.google.com, see
Afterthought 2008].

Domain name is a {core} concept underlying {all} network structures.
Within IT, the term 'domain' points to a {particular} server within
an extremely complex hierarchy, which is managed by a network of
so-called DNSs - for Domain Name Servers. These computers run the
pairing of domain name with the appropriate server and enable anybody
to access addresses typed in by their name.

So, if one for instance, wishes to access {the} google.com {domain}
there is a specific programme on our machine that asks the {local}
DNS which server will respond to the prompt 'www.google.com'. The
DNS network then goes on the look out within its gigantic maps and
data bases for the actual IP number on basis of the 'public' -
i.e. plain language - address we have typed in. This results in a
machine-readable {but not for us} IP number. It communicates this
result to our machine, and we are connected to the site we wanted, or
to any other site we may request.

Simplifying this complex hierarchic mechanism a bit, we might
say that domain names are structured by level. In a typical web
address, levels can be read from the right to the left. The first
level, {the 'Top Level Domain Name', or TLD} is generic (like
'.com', '.org', '.net') or national ({'country TLD'} as in '.jp',
'.it', 'es' or '.tv' {- that's Tuvalu!}). At the next, second level
are the 'real' names of the servers combined to one TLD (and one
only), eg. google.com, eleuthera.it, sarai.net openflows.org or
wijvertrouwenstemcomputersniet.nl Nothing prevents a server from
having the same second level domain name associated with a number of
different TLDs, as with 'google.it', 'google.de', and 'google.fr':
are all valid domain names owned by Google.com . But an identical
second level domain name in combination with different TLDs do not
necessarily represent the same entity. 'ippolita.net is the site of
the Ippolita project {and collective}, whereas 'ippolita.it' refers to
the {Italian} poet Ippolita Avalli, and 'ippolita.com' is the site of
a so named manufacturer and vendor of jewelry.

>From the second level on, further levels management is of the resort
of the second level domain name owners. 'code.google.com' , for
instance, is directly controlled by Google, just as google.com,
or even 'moon.google.com'. {Same applies for names after the dash
following the TLD: google.com/world-domination ;-) -TR}

There are no general rules for third-level domain names: hence
it is OK to think of a suggestive address name, as long as it is
'grammatically' correct {in 'network language'}, as for instance
'del.icio.us' , where '.us' is the TLD for the United States, 'icio'
the name of the server, and 'del' makes the word-play complete. More
commonly, however, third level domain names are used to indicate
specific services: 'www.server.net' will open the homepage {of that
particular site}, whereas 'mail.server.net' will take you to its
e-mail facilities, and so on.

Possibly the best metaphor to describe this hierarchy is that of a
house, where services have a ... service door ('mail.server.net'),
and various components of the site all can be accommodated in their
own 'room' ('www.server.net/images') with the site's main adress
('www.server.net') functioning as the front door that permits further
access.

Google's management of its third-level domain names is not straightforward
at all, and this is precisely the reason why it can be very open and
dynamic ['fluid' in Fr txt]. One will notice for instance that the Moon is
given a third level domain name ('moon.google.com'), but not Mars, who
[which?] is shuffled after a dash ('www.google.com/mars'). Both services
make maps {of these celestial bodies} available and nothing more - their
format is the same.

Conversely, sourceforge.net 's structure is far more rigid, and so is
freshmeat 's (the latter not being used by Google - for the time being).
This holds also true for most other projects-related sites.
Sourceforge.net offers the projects it hosts as a service to users, since
it operates as a portal. This is also why Google's projects there all are
under a third level domain name, just like all other {F/OSS} projects {it
hosts}. The site functions as a instrument for developers communities
/each with their own page/ to build up an ad hoc, richly serviced
environment . All the various communities make use of the services they
need, and sourceforge.net provides them with a personalised and
all-inclusive environment to that effect. Thus Google's position is
{theoretically} no different from that of Gaim  any other software
development community, but then Google is not just 'any other' community
of independent developers... [Google has meanwhile put this possibility of
'misrepresentation' to rest. Cf. Afterthought 2008 -TR]

More 'interzones' have been set up in the meanwhile to manage the areas of
influence of various communities and the possible interaction between
their projects. The Open Source Mozilla and its preset page on the Firefox
browser form a nice example of maximum public visibility {with minimum
effort}. Every time a user installs the Mozilla Firefox browser the first
page to appear will show Google's homepage - with the graphics slightly
modified so as to include Firefox's logo.

Google does even offer a DIY toolbar  on Firefox. Toolbars are graphic
boxes (usually lines or columns) activating their hosting programme's
specific functionalities by way of buttons or other graphic objects.
Firefox's extentions allow for adding various toolbars into the browser at
no costs. Yet what the general public rarely does notice is that such
add-on products are not entirely 'Open Source'. The Google toolbar is not
something one can download from the usual Mozilla extensions site, since
it is a proprietary product. The functioning of the toolbar is enclosed in
a small, dedicated library which doesn't come with a source code. There
exist various 'reverse engineering' (and hence illegal) 'exploits' which
show how this particular extension works and the way data are requested by
the Google site.

The integration between Google and individual {users'} terminals (PC, Pal,
etc.) is becoming tighter and tighter. One of the extensions for Mozilla
Firefox, for instance, is called Google Browser Sync : bookmarks, history,
cookies, remembered passwords, and even pages and windows/tabs left open
during the last session all are saved on-line on Google's servers to be
automatically synchronised at their respective places, to be restored
during the next browsing session. Control over the user now extends to
whatever device that permits access to the Web.

Finally, one can identify a last 'interzone': the realm of users licenses.
Google has endeavored to adjust to the standards set by other 'Open
Source' firms, which all tend to use BSD 2.0 licenses in variously
modified forms (the exception being Novell). This license allows code
sharing, but also provides for a strict control on the distribution of
programs and of their spin-offs. This format enables the creation of
{vibrant} communities, but allows at the same time considerable leeway for
general oversight on the whole production sequence. Any independent coder
doing {software} development for free and making use of this license can
legally see her work being taken away from her at any time {and without
compensation}.

Despite the fact that some Google executives have let it known they were
thinking about a possible license switch towards Apace of MIT type
licenses - they were even talking about GPL -  the truth is that the BSD
license remains the standard for all projects hosted and pushed by the
serach engine. BSD constitutes therefore the license 'interzone' {or
twilight} enabling the firm to attract the fee codes of the F/OSS world -
in order to transform them in its exclusive property.








--------------------------
Translated by Patrice Riemens
This translation project has been supported and facilitated by:

The Center for Internet and Society, Bangalore
(http://cis-india.org)
The Tactical Technology Collective, Bangalore Office
(http://www.tacticaltech.org)
Visthar, Dodda Gubbi post, Kothanyur-Bangalore (till March 31st, 2009)
(http://www.visthar.org)
The Meyberg-Acosta Household, Pune (April 2-11, 2009)
The Bawa-Jonnalagadda Household, Bangalore (April 12-18, 2009)
The Haskel-Huley (London), Bunting (Bristol), Zingas (Glastonbury), and
Bezembinder (Groningen) Households  (April 19 - May 10, 2009)




#  distributed via <nettime>: no commercial use without permission
#  <nettime>  is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: http://mail.kein.org/mailman/listinfo/nettime-l
#  archive: http://www.nettime.org contact: nettime@kein.org