For years I’ve held Google as the prime example of a corporation throwing its full weight behind the open internet. But it gives me pause when people start saying that Google is “rapidly turning its back on every single open standard”.
It was only back in March, when Google announced that they were closing Google Reader that it became clear to me: Google supports the open web, but decidedly not the open internet. “Web” and “internet” are not interchangeable in this context. The internet is a network of networks that supports all of the computing infrastructure supporting many networks, including the web. The web is just one of those networks, characterized by its use of HTTP(S). The web is consumed using a web browser, but the internet could be consumed my many clients. My fundamental misunderstanding of Google’s position all these years hinged upon my conflation of the web and the internet when thinking about Google’s strategy. There are a few examples of the ways in which Google has chosen not to support open internet protocols.
Google’s motivations become clear when you look at the technologies Google has sought to suppress over the years. Google was instrumental in killing off native email clients by investing heavily in the development of GMail’s web interface. Before GMail (and yes, even today), most other webmail interfaces were considered a weak alternative to using a native client. After GMail was revealed in 2004, the usage of native clients dropped dramatically. This was a major coup: Google managed to trade internet protocols like POP, IMAP and SMTP for the HTTP(S). To be sure, GMail still supports the other protocols, but the product is geared to push users toward the web-based alternatives.
Also on the messaging front, Google announced just yesterday it had made ‘the difficult decision to drop the very “open” XMPP standard that it helped pioneer’. XMPP is what helped Google play in a larger ecosystem of messaging clients from other providers. Now, instead of reading your messages using a Jabber-based client, you’ll read your messages over HTTP(S).
Usenet (newsgroups) is another example of a federated ‘open internet’ protocol that has been around for decades that Google does not support. Google chose to bootstrap their web-based Google Groups product with data from Usenet, but unlike Usenet proper, there is no way to connect to Google Groups with third party software to read content there. In the new Google Groups interface, you can’t find links to RSS feeds for the groups like you could in the old interface. The result? Users are driven to use HTTP(S)-based protocols instead of NNTP (the Usenet protocol).
Google has backed away from open web technologies that operate over HTTP.
The biggest example is their fading support for RSS. Closing Google Reader and ending support for RSS in Google Chrome are the main examples here. RSS is a standard, and allows third-party software to interact with data from across the web seamlessly. It’s very useful to users, but not all that useful to Google.
This mentality has permeated Google’s offerings. In creating their own social network, Google disabled all support for RSS. RSS would have allowed Google Plus users to see updates from the network in third-party clients. That provides a lot of value for the user, since updates could then be filtered, analyzed and aggregated. Google went a step further, however, and decided not to support any write operations in its API for Google Plus. To the end user, this means that there is only one way to post content to Google Plus: through the web interface. Google Plus is essentially a “network” that supports only one client and one “server” implementation.
I know little about how these policies came to be, so discussing motivation is an exercise in speculation.
Google makes money from advertising, and the efficiency of advertising is coupled to how well you target potential customers. At the turn of the century, the best way to do that is by looking at search terms and displaying relevant ads. As computing power has increased, Google has pioneered “big data”, which allows for much more sophisticated targeting.
Facebook has shown that people will happily post lots of information about themselves online. Facebook also discovered a very simple abstraction for profiling users: the “Like” button. The genius of the “Like” button is that it is very low friction – it only takes a second for a user to register his or her opinion. It is also perfect for computers to analyze: it is simply the toggling of a bit (in concept, anyway). This makes much better profiling possible, and brings to the social web Amazon’s “Users who purchased this item also purchased…” functionality.
So, where Amazon had browsing and purchasing history and Facebook had a history of “Likes”, Google had a history of search terms. For a company in the advertising business, Google realized they needed to insert themselves into more user actions so they could build better profiles to target ads more effectively.
That meant building Google Wallet and Google Plus (along with the “+1” button) to get access to users shopping history and social interactions. It also meant building Android and encouraging users to give Google data about where they live and work.
If Google opened up the write API to Google Plus, it would open the door to automated systems posting to the network, reducing the signal-to-noise ratio of Google’s data used to build profiles. It would allow clients to be build that de-emphasized the “+1” button that is so important to collecting data to compete with Facebook.
If Google supported XMPP or RSS, it would drive users away from Google’s own web applications that gather data about what times people visit the site, and how long they look at particular items. Google Talk drives people to open GMail or Google Plus, and the big red button encourages people on GMail to open Google Plus. Google Plus is designed to gather data about user interaction on the network: who a user follows and chats with, what stories a user comments on or clicks “+1” on.
If users can access all the updates with third-party software, none of that can happen.
Collecting information useful to profile users is only one half of the equation. The other half is displaying advertisements to the user. Delivering advertisements via RSS is possible, but awkward. Delivering effective advertisements is very difficult over XMPP or NNTP or SMTP. In other words, every time a user opts to use a third party client connected to Google’s services over an open protocol that is not HTTP, Google not only has trouble building a profile of that user, but Google also has trouble showing them advertisements.
Does the Internet Have a Future?
Some would argue that Google is the internet’s biggest corporate champion (I would!). Despite the my tone thus far, I believe that Google is still an ally in the battle to keep the internet open. But there are other allies as well. The biggest tool we have in maintaining an open internet is the open source software stack. It allows users to pay a small amount of money to host their own sites on services like Dreamhost or EC2 and deploy open alternatives to corporate offerings. When Google Reader closed, I picked up TT-RSS and I’ve never been happier reading RSS. I’m looking to deploy RoundCube to my Dreamhost account as an alternative to GMail. There are open alternatives to social networks as well, like Wordpress and RSS, though none have gained much traction, yet.
On the client side, Firefox remains the best browser in many respects, including extensibility. It is important that in the realm of the web, we don’t develop a browser monoculture, despite the support of at least one Google engineer. Standards that have only one implementation are subject to change much more readily than open standards implemented by a variety of parties, and one of the founding tenants of the web is open, standards-based access.
Even without Google’s unequivocal support, the open internet is alive and thriving. To keep it that way, users need to understand that they give up a measure of choice and privacy when they use centralized, corporate products that force them to use only the web. Sometimes that is a sound choice, but perhaps it isn’t always the best one.