Patrice Riemens on Sun, 10 May 2009 13:57:28 +0200 (CEST) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
<nettime> Ippolita Collective: The Dark Face of Google (Appendix 2) |
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