The problem was that the server hosting the SWF and JS file didn’t serve them anymore, instead giving a 403 – access refused error. To mitigate this problem I’ve uploaded the SWF file to Google Code and used the JS file from the Google Ajax Library and bought the plugin back to life.

So, if you are using the plugin and you are subscribed to my feed, go to the original (now updated) post and use the new code.

Thank you and sorry for any inconvenience caused!

Recently I found a simpler (read: somebody else does the hosting for me :-)) solution to the problem thanks to the securitygarden blog: WorldTimeServer.

To get the clock, you have to do the following (it is a little non-intuitive, but bear with me):

• Go to their Current Local Times around the world page and select the location on the right you would like the clock to show. Your selection is saved in a cookie
• Now go back to the front page and select “Get free, cool and customizable analog clocks to embed on your web pages or blog site”. From here you can select if you would like a 12H or 24H clock and customize the colors.

While this solution is not as powerful as my original suggestion (one particular missing feature is that it doesn’t convert in-line dates as the original one did – but I didn’t use that feature as much as I originally imagined anyway), but it is much simpler (and doesn’t oblige me to keep up a PHP hosting service).

Enjoy your time!

Picture taken from Robbie-73’s photostream with permission.

Below you can see the pipe, which is relatively simple:

The code consumes the result of the pipe as JSON and generates the flash object. It is adapted from the original include code. If you wish to use it, you should edit the Yahoo Pipes URL (replace it with your blog URL and the number of tags you wish to show), the text color (on the line with “tcolor”) and possibly the size of the flash. The weird method for constructing the links is necessary because Blogger seems to “muck” with the code otherwise.

<div id="tagCloudContainer"></div>
<script type="text/javascript">
var tagCloud = {
  'storeCloud' : function (obj) {
    var baseUrl = location.protocol + "//" + location.host;
    var cloud = '';
    for (var i in obj.value.items) {
      cloud += "<" + "a " + "href='" + baseUrl + "/search/label/" + obj.value.items[i].title + "' style='8'>" + obj.value.items[i].title + '<' + '/a>';
    }
    cloud += '<' + '/tags>';    
    tagCloud.cloudTags = cloud;
    setTimeout(tagCloud.renderTagcloudCallback, 100);
  },
  
  'renderTagcloudCallback' : function () {  
    try {
      swfobject.embedSWF('http://hype-free.googlecode.com/svn/trunk/blog/tagcloud.swf', 'tagCloudContainer', '230', '240', '7', '',
        { 'tcolor' : '0x666633', 'mode' : 'tags', 'distr' : 'true', 'tspeed' : '100', 'tagcloud' : tagCloud.cloudTags },
        { 'wmode' : 'transparent', 'allowScriptAccess' : 'always' });      
    } catch (err) {
      alert(err);
      setTimeout(tagCloud.renderTagcloudCallback, 100);
    }
  },
  
  'init' : function () {
    var script = document.createElement('script');
    script.src = 'http://ajax.googleapis.com/ajax/libs/swfobject/2.2/swfobject.js';
    document.getElementsByTagName('head')[0].appendChild(script);
    
    script = document.createElement('script');
    script.src = 'http://pipes.yahoo.com/pipes/pipe.run?BlogUrl=http%3A%2F%2Fhype-free.blogspot.com%2F&Topcount=10&_id=xKTkgQsT3hGl4j3nJpREag&_render=json&_callback=tagCloud.storeCloud';
    document.getElementsByTagName('head')[0].appendChild(script);    
    return this;
  }
}.init();
</script>

If you are reading this in your RSS reader, visit the blog to see it in action.

Update: it seems that the Flash file can’t interpret tag names with special symbols in them (like ‘). Because of this I modified the pipe so that such tags are filtered out. This will result in some top tags not being displayed (if they contain special characters), but I considered this the right solution, because even if they were displayed, clicking on them wouldn’t result in anything. Credit goes to Evie for finding this issue.

Update: the S3 instance hosting the flash file and javascript (halotemplates.s3.amazonaws.com) went away (thanks to Soufiane for pointing this out). So I’ve downloaded the latest version of the WP-Cumulus and uploaded the SWF file from to Google Code. The SWFObject library is also served from there. So to everyone using the old version: please update to the latest code posted above to make it work again. Sorry for the disruption!

Update: The update broke the “clickability” of the links, since it seems that the new SWF file requires absolute URLs for that. This is now fixed in the script above.

Update: Yahoo pipes changed their backend and thus some adjustment was needed in the pipe which was done.

The problem however is ease of use and distribution. You have to (a) know that this software exists and (b) know how to download and install it.

An other option would be to use a platform which is already widely distributed to make the delivery easier. Some of the options would be:

• Flash – version 10 has a JIT compiler for the ActionScript part
• Javascript – Chrome has a JIT compiler and Firefox 3.5 will hopefully have one (which can already render some 3D in real-time)
• Java and Silverlight 2 – they have more advanced JIT compilers, but are not as widely available as the first two options

There is some performance loss when we compare these technologies to native code (up to 90%), but we have at least two factors working in our favor: we can work on a large scale and the performance of these technologies will improve in the future.

Now, it is not all rosy:

• The most popular technologies (Flash and Javascript) do not support threading or setting the priority for the process AFAIK. This means that, in order to make the calculation unobtrusive, it must be chunked up into very small pieces (less than 1 second) and insert pauses between them
• The computation performed by a single person is very limited, especially if the business model is to place the code on webpages, because the time spent on a webpage is small. This means that the task must be such that it can be chunked up into very small pieces

One company which is making a play for this market is Plura Processing (see also their blog). Disclaimer: I have no relations with the company, I just found their idea interesting. From what I understand, they use Java for the processing part and target pages which have a longer “stay-time” (like pages containing Flash games) and they have a revenue-sharing model with the webpages who embed their applet. Cool!

Picture taken from Shahram Sharif’s photostream with permission.

Update: reduced the number of tags to avoid hogging the CPU.

Update: the server hosting the javascript / flash files went away, so I’ve moved them to alternative locations. See this post for the details.

While pondering different possible solutions, I thought of two things:

• First: why doesn’t Google Reader just put HTML extracted from clients in an IFRAME from a custom / randomly generated subdomain (ie. qwefwer.googlereader.com)? The IFRAME could have no border and the appropriate width-height (and the correct overflow style), making it indistinguishable from a plain page. The idea being that the same origin policy would prevent malicious JS fiddling with elements it shouldn’t. However this was probably harder and possibly less secure than going with the whitelisting.
• Second: I observed that Google Reader allows Flash to be embedded in the blog posts. Or at least I thought it did. So I’ve said: aha! I can embed flash, flash can execute Javascript, so I can execute Javascript!

Unfortunately (fortunately?) this is not the case. They seem to employ a whitelisting solution, removing any embed/object tags which specify a source that is not on the whitelist. As far as I can tell the whitelist is not public, but it includes at least some online video services. BTW, if you wish to the Google Reader traffic in Fiddler, don’t forget that responses are GZIP compressed, which Fiddler doesn’t decompress automatically

Where does this leave us?

No javascript for you! Unless you find some kind of security hole in one of the whitelisted Flash movies. If you do however, you can take over the whole session, because your JS will run in the context of the Google Reader.

I don’t know what kind of filtering is applied to other objects (Java Applets, Silverlight, etc), but from what I’ve seen I assume that they would be filtered out.

It would be very nice if they would adopt the IFRAME approach, because that would mean both more security and the possibility for them to enable full JS / object support.

In a way the World Wide Web is a marketing companies wet dream: just image, tracking the moves of the users, building a profile which lists their potential interests (as it can be inferred from the list of visited sites and the frequency of the visits). Using this they can show ads which they consider will be relevant to us. Of course they don’t do this out of the goodness of their hard. They do it because you have a higher probability of reacting to the advertisement if it’s relevant to you.

Here are the means I know of which can be used to accomplish this:

• Tracking cookies or third party cookies – this is IMHO a bad name (from a technical point of view), and I’ll explain in a minute why. But first lets answer the question: what are cookies? Cookies (or HTTP State Management Mechanism as it is referred to by the official RFC) are opaque tokens (from the point of view of the client) which contain some information which helps the server side application identify the fact that different HTTP requests are part of the same session. This is necessary, since the HTTP protocol does not define any method for creating, tracking and destroying sessions. That is, whenever you request an object from the web server it will treat it as separate request, having no idea what you requested earlier. The cookie is used as token in the following way: the server says to the client take this piece of information and return it to me on subsequent requests. This way it can determine if the request is part of the same session (because it can hand out a different value to each client and when the client returns the information, it can identify the session it is part of). Before you ask: you can’t use IP addresses as a reliable unique identifier because of proxies and NATs. You can observe two things here: this behavior is entirely voluntary on the clients part (it may choose not to return the token) and that it applies to every HTTP transaction, not just HTML documents (including images, flash animation, java applets, etc). Of course the standard defines a policy which specifies in which requests should the cookie be returned. The elevator speech version of this is: cookies will only be sent back to requests targeted at the server it was originally sent from and to elements the path of which is prefixed by the path contained in the cookie (for example if the cookie was set by the object located at http://example.com/set/a/cookie it will be sent in all requests which are targeted at the example.com server and contain in the url /set/a/cookie). Now how is this used to track you from site to site if the cookie is only returned to the server it was originally sent from? Enter the advertisement companies: they serve up ads from the same server to many webpages. This means that those webpages contain links to elements (usually images, flash animation or javascript) which reside on the server of the advertiser. This means that if you view a page which contains advert from a given company, it can set a cookie, which will later be sent back to it when you view an other page (possibly from an other server) which contains advert from the same company (because in both cases the object – image, flash, whathever – came from the same source the cookie was set – the server of the advertiser). This is called a third party cookie because it is set by a different entity than the server you see in your address bar. However I think that this is a bad name since it implies that some kind of spoofing is going on, like a server is setting a cookie for an other server – which by the way is explicitly prohibited by the standard and won’t work in any modern browser. To sum up:
  • Applicability: (almost) every browser supports it. The standard itself if relatively old (almost 10 years)
  • Customizability: Current browsers offer ways to set a policy on what cookies should / should not be accepted both in a whitelist and blacklist format. Usually they do not include the option to view the cookies stored on the machine, but there are many free third party tools / extensions which enable you to do this.
  • Risk of disabling it: if cookies are disable altogether, many sites which have a member-only area will break and the user will be unable to log-in. Disabling of third party cookies breaks pages which host elements fetched from a third party server (which represents a small but growing percentage of the web in the age of mashups)
• Flash Local Shared Objects (AKA flash cookies) – As of version six (also called Flash MX) a feature was introduced in the Flash Player to store information which had to preserved across different page loads locally on the users computer. Before that sites used a combination of javascript, cookies and actionscript to obtain the same effect. Flash Local Shared Objects have the same restrictions as cookies for forwarding (i.e. they’re only sent to flash movies which originate from the same server). Because this was a little known feature outside of the Flash developer community and the interface was hidden and because of the scaremongering many users started to remove or disable cookies, advertisers started to use it instead of cookies.
  • Applicability: on any platform which has at least version 6 of the Flash Player installed.
  • Customizability: you can go to the site of Adobe to completely disable or to manage the shared objects which are on your computer. There is also a Firefox extension, however it seems dated and not maintained any more, so probably the safest bet is to go with the official links provided above.
  • Risk of disabling it: sites which rely on it may break, however I didn’t found any sites until now which relied on it for other purposes than tracking, so currently it may be disabled without any problems. This may change in the future however.
• Referrer URLs – Referrer URLs is a piece of information sent by your browser when requesting an object from a web server. For example if you click a link at http://foo.com/link.htm which takes you to http://bar.com/target.htm, the bar.com webserver will receive as part of the request (if you didn’t disable it in your browser) the string http://foo.com/link.htm as the referrer. This can (and is) used by sites for statistical purposes (to see who links to them) and for security (however this is a pretty weak form of security since it relies on the client playing it straight and thus it can be spoofed. One thing which makes the privacy advocates suggest to turn this feature off is the fact that if you go to a page from a search engine (that is, you searched for bar.com on google and then clicked on one of the results), the target server can know the words you searched for (since it will be embedded in the referrer url). However, this information isn’t forwarded to the advertisers unless the use third party javascript to get it (which I’ll talk about later on). That is if you go: Google -> Google search results -> foo.com -> (automatically, because it is embedded in the page at foo.com) advertiser. The referrer transmitted at the last step (that is from foo.com to the advertiser) if foo.com (meaning that the only information that the advertiser gets is the fact that the ad was loaded from foo.com, not the way by which the user arrived to foo.com. I want to stress this because Steve Gibson got this wrong on episode 64 of the Security Now podcast. (I want to stress again that advertisers can get the referrer of the page which includes the advertisement by using third party javascript which I’ll talk about shortly).
  • Applicability: on almost every browser
  • Customizability: you can see a tutorial about enabling it here which should point you in the right direction.
  • Risk of disabling it: you shouldn’t encounter any problems because few sites use it for other purposes than statistics, but if you don’t mind, give them this piece of information, it can be used to create better content for you!
• Third party javascript – usually when a site collaborates with a given advertiser, it is asked to put a piece of HTML in every page where s/he want the ads to be displayed. This code is usually an IFRAME tag or a SCRIPT tag. In the later case we talk about third party scripts – javascript code which is provided by a third party and runs in the context of the current page. This code can do almost everything, including the following things: access the referrer of the current page (so even if it isn’t directly relied to the advertisement server, the script can forward it), get information about the browser capabilities (screen resolution, etc) and perform history digging (see the next point).
  • Applicability: on every browser which understands javascript.
  • Customizability: in Firefox you can use the NoScript extension. In Internet Explorer you can add the sites you want to block scripts from in the Restricted Sites Zone. An other solution would be to disable javascript entirely, but this will reduce the usability of many sites.
  • Risk of disabling it: mashups use heavily third party javascript (to embed Google Maps for example). Also some big sites host their script files on different servers than the content (to be able to optimize the servers for the specific types of files), so you can’t say generally that everything third party is bad.
• History digging – This is a really cool technique, reported first as far as I can tell by Jeremiah Grossman and was later tweaked to work with IE. It is based on the fact that visited links have different styles than non-visited links (this is usually observed as different colors). If you put a bunch of links on a page and then use javascript to inspect the styles applied to them by the browser, you can tell if the given sites are in the history of the browser.
  • Applicability: there is proof of concept code for Firefox and IE. It should work in any browser which has a standard conformant implementation of javascript and DOM.
  • Customizability: you can’t programatically disable just this feature. Your options are: (a) disabling javascript (b) cleaning your history before you visit sites you suspect are doing this. One important fact: if an advertiser embeds javascript on the site the ad is displayed on, it can use this technique to find out if you visited a given site. Fortunately there is a mitigating factor: in order for somebody to find out if you visited a given page s/he has to know the exact url of the page (that is this method can not be used to enumerate the entries of your history)
• Sign-in information – an often overlooked fact by people is that the big three identity providers (Google, Yahoo and MSN) also provide advertising. Because of this they can correlate tracking information obtained by any of the methods listed above with the personal information you provided at signup. Now I’m not saying that they do this, I’m just saying that they have the technical means to do it.
  • Applicability: if you are a user of any of these sites and browse sites – while you are logged on – which display advertisement from them, you are affected.
  • Customizability: log off before browsing to other sites and clear all the cookies from them. Before logging back in also clear the cookies from them placed there by the ads.
  • Risk of disabling it: the inconvenience of constantly having to clear cookies.

Now for the philosophical question: should you be worried? Should you go to great length to avoid this tracking, even at the cost of breaking useful features on the site? You should consider the following ideas (they are not absolute truths, but arguments which are used in this debate):

• Nothing is free and advertisement is an (arguably) quick and (mostly) painless way of payment for the content / service. So disabling advertisement can be thought of as a way of cheating to get what you desire without payment)
• Contextual ads can be useful. For example if I would like to buy a laptop and I see an ad for laptop, I will most probably click it. This is useful for both parties: for me because possibly I learn about an offer I didn’t know about and for the company who put out the ad, because I might buy something from then.
• Some people say: but this is not right! The user should be in control! If you want to buy laptops, search for them yourself! Of course no rational person (no offense to anybody) would buy something of significant value based on one ad (because usually it’s only showing one detail of the product – probably not mentioning the not-so-bright sides) but it may add value to your research. So, while you shouldn’t buy based on what they say on the teleshopping channel – err I mean ad – it may add value to your research while you are considering your options.
• The tinfoil hat people may say: I don’t want the government / Amazon / Google / whatever track my every movement! I have a right to privacy! – and they are right, they do have a right to privacy, however they must be willing to give up certain benefits or to make some additional steps. And before you object saying: why do I have to make extra efforts to get the same service everybody receives while keeping my information as private as possible? – just consider how things work in the real world – if you want to drive a car, you must get a license. It is your right to drive a car (if you are of legal age), however you still have to get a license. Because every analogy breaks down, lets consider the technical point of view: every technology can be used for good an bad (this is even more so if there is no clear distinction between good and bad). The only way of preventing 100% of the bad usages of a technology is to ban it all together. You may choose this, but be aware that you are not getting the benefits either. Now some of the technologies (like session cookies) can be emulated by other technologies (like appending the SID – the session identifier to every request as a GET parameter), however the given technology was introduced to make it easier to accomplish certain tasks without the complication and hassle the old method needed. Guess, what a rational website owner / creator would do: use the more complex, less reliable and more expensive technology for a very little percent of its visitors or go with the easier and more powerful technology?