it’s more than eight years ago that i started spielwiese.

so far, spielwiese was mostly a black and white, lowercase english experience. until now. using nikola‘s multilingual capabilities, i decided to try translating parts of spielwiese to züritüütsch, a swiss german dialect spoken in the canton of zürich, in which i’ve now spent more than eight years of my life.

since züritüütsch isn’t my native language and i’m still far from understanding and speaking it perfectly (though understanding is much better than speaking), i’ll surely make mistakes, though i hope most will be caught by my wife before setting them live :)

this is yet another experiment, and i’ll hope some of you will like it.

after already revamping math and musikwiese earlier this month, it’s time to do spielwiese as well. and here we go! spielwiese now adjusts to all window widths, including mobile phones. and the gallery looks good again, too. (i had to screw with it when adjusting spielwiese for mobile phones the first time.)

the only things missing are a proper popup gallery for mobile phones, and as in the other blogs: comments. so sorry, there’s no way to add a comment at the moment, except by writing me an email.

over the last weeks, i’ve been starting to convert my blogs to nikola, a static blog generator named after nikola tesla. so far, i’ve finished my math blog and musikwiese. i also got rid of the fixed width layout. spielwiese itself will take a bit more work, mostly because of the wordpress plugins i wrote and heavily rely on throughout this blog.

to convert my blogs, i had to add some changes to nikola. most of the core changes are now contained in nikola itself or are close to be integrated (except xhtml support). i also worked a lot on improving its wordpess import, which so far wasn’t very helpful from my point of view. for that, i created a wordpress page compiler for nikola which essentially does the same to posts as wordpress’ formatter does. that part is still not completely done, and since it is a pure plugin, i haven’t released it yet. (that will happen later, hopefully still this year.)

the main disadvantage of the whole conversion process is currently that there’s no more possibility to add comments. all comments written so far are preserved, but currently there’s no support for adding new ones. i’ll try to figure out a good way to do that later. the “standard way” to do that, i.e. using something like disqus, is not acceptable for me, and even though there are free alternatives for self-hosting, i don’t like to rely on javascript for such things. for the moment, you have to send me an email if you want to add a comment to musikwiese or my math blog.

from today on, i’m enforcing https for (almost) all my web pages. i’ve added an automatic redirect which redirects all http:// pages to their corresponding https:// pages.

despite the tons of problems ssl/tls have – essentially, everything less than TLS 1.2 is unsafe, but only very few browsers actually support TLS 1.2 even though it has already been standarized in 2008 –, it is better than using no encryption at all.

and yes, i know that “just” having a self-signed certificate is only partially helpful. but i don’t have a better solution at the moment, as i don’t want to dump tons of money into CAs which i don’t really trust anyway. (maybe i’ll change my mind eventually. but not right now.) so for the moment, you have to accept my self-signed certificate (whose sha-1 fingerprint is 69:02:33:1D:F7:E3:9C:DA:D2:7D:9E:1D:4A:C6:40:99:A3:F8:B2:58, and whose md5 fingerprint is E5:DA:7D:4E:11:34:20:BD:7C:9E:3B:CD:E1:C9:6A:1B. you can compare them in firefox, for example, by clicking the padlock and then clicking “more information…” and then “view certificate”, and in chromium/chrome by clicking the padlock and then “certificate information”).

as you might have noticed, all videos embedded from youtube or vimeo got replaced by a disclaimer, stating that i do not want to bear the legal risks of including them anymore. including something you didn’t create yourself is kind of russian roulette. if someone decides to send you a abmahnung, trouble begins. and usually, money goes. lots of money. even if what you do is legal, you’ll have to invest quite some money to make your point. i don’t really want to do this for these videos, so i changed my plugin to let it spit out disclaimers with links instead of embedding* the video. i’m sorry for this, in particular this essentially ruins musikwiese.

*the videos weren’t embedded directly for some time anyway, see here, but i guess that wouldn’t really make difference…

today, i updated my gallery code. it now features a “pop-up version”: if you click a photo, it will be shown with a black background, and as soon as you click anywhere, you’ll return where you just were in the blog. you can still use something like firefox’ double click to open the photo in a new window, and the “fullscreen” viewer includes a link to the image file (and instructions on how to get rid of the fullscreen view as well as a copyright notice). if you don’t like the new viewer, you can explicitly disable it by using the new settings menu in the sidebar. there, you can now also more prominently toggle whether you want to see the thumbnails always in colors or not. finally, changing the thumbnails now also works without javascript enabled.
i’d be happy about a bit of feedback, in particular if the new gallery fullscreen viewer works in your browser. i so far tested it with firefox, konqueror and chromium, so it should also work with safari and chrome, but i’m not so sure about the internet explorer… in case it doesn’t work (and if you’re using the internet explorer, also please in case it works) tell me your browser and its version number so i can investigate a bit… (in case you’re using an old internet explorer, you should better change to a newer version or a different browser, as it is very broken anyway.)

many websites leak information. for example, most websites including a facebook like button make your browser tell facebook “hey, i’m visiting this page”. some for google and their +1 button, and for most other of these fancy little “web 2.0 buttons” you can find nowadays at many places of the web. or they make your browser feed google analytics with your data, or any other web tracking service. and usually, you don’t notice any of this, as it appears hidden in the background.
in this post, i want to shed a bit more light on these things and their (possible) consequences, and tell a bit on how to avoid these problems both as a user and as a webmaster. in the beginning of spielwiese, i already wrote a little bit about this here, and i also mentioned the problem while writing about social networks. you might want to look at the first post if you don’t really know what is happening if you access a webpage with your browser.
in the examples below, i’m assuming that standard javascript and cookie settings are used.

what’s going on?

assume that some website you are visiting includes the (standard) facebook like button (via facebook.com). as soon as you access that page, its html code will contain

<iframe src=”http://www.facebook.com/plugins/like.php?href=…” scrolling=”no” frameborder=”0″ style=”border:none; width:450px; height:80px”></iframe>

your browser automatically accesses http://www.facebook.com/plugins/like.php?href=… to retrieve the content from that url and essentially puts it into the place of the iframe. moreover, if you’re a facebook user, and you are logged in, your browser will have cookies for *.facebook.com (containing your user id), which will be sent automatically with this http request. so at this point, without any javascript interaction, facebook already knows whether you are logged on, and who you are if that is the case. note that facebook could also set a facebook.com cookie when none is already set, to be able to further track you. it seems like that is not the case, but if they would do, you probably won’t notice at all. now the html page sent by http://www.facebook.com/plugins/like.php?href=… includes several javascripts, which your browser will automatically execute, and which could sent more information like your screen resolution. facebook isn’t doing that, as far as i know, but they could with only very few people noticing, if at all.
another resource are web trackers, which try to gather statistical data for the webmaster who included them, but might also use this information for other things. these work similar to the like button: the user has to somehow include them. maybe as a 1x1 transparent pixel, or as a java script, or both. the pixel will ensure that basic data is sent even in case javascript is disabled or not available, as long as images are loaded. the java script will sent additional info making identification of the visitor easier, and with both accesses to the web server of the web tracker, cookies can be retrieved or set, allowing the web tracker to identify you along different sessions. they probably don’t know who you are, but they can distinguish you from your friends, even if you share your internet connection (and the same ip address!) with them and your computers are essentially identically configured.
but there also many other sources of leaking. for example, if a youtube video is included in the web page you’re accessing. in that case, your browser will ask youtube.com for the flash player, and that retrieve a image from ytimg.com and, when you click the play button, will stream and play the video from other youtube servers. again, a lot of things can be leaked. if the flash plugin is disabled, this won’t happen, but most people have that one installed and active as otherwise, many sites will not work properly.

how to prevent your browser from leaking.

the radical solution is to disable javascript, disable cookies and disable all plugins like the flash plugin. but that still doesn’t solve the problem that basic http access data (browser id string, referrer, your ip address) is sent to certain included sites, for example if they are included using iframes or as images (maybe even transparent of size 1x1 so you won’t notice). so without add-ons, standard browsers can always be made to leak something.
for firefox, there are several helpful addons. two very helpful ones are the following:

• noscript. this addon allows to say from which sites javascripts are allowed to run and from which not. unfortunately, this does not depend on the source site, so if you allow the facebook javascripts to work (which you need if you access facebook itself), they are also allowed to run if another site includes the like button.
• requestpolicy. this addon allows to block access from sites to other sites, for all kind of requests (loading images, scripts, even loads made by the flash plugin). as the blocking is by default depening on both source and destination of the access, this block access to facebook.com from any other site but facebook.com, hence making it impossible for facebook to track you except if you allow a site to (temporarily or always from now on) load content from facebook.com.

note that both plugins require a lot of user interaction. most websites won’t work properly, and too many will look very ugly in case you don’t allow certain scripts to run or certain data to be fetched from different servers. it is annoying to find out which things you have to active without giving too much access, and can be very frustrating. but after some time, you’ll have the sites you’re using most set up properly, and most things you do in the web run without any more interaction. visits to new sites, though, are still adventurous.

how to prevent your page from making leak.

first, a few words why you should try not to leak. the first is trust: the visitors of your page trust you. in particular, they usually don’t want that you send their information to not perfectly trustable other sites. and then, there are users who block such things, like me. if i access your page and you rely, say, on google analytics to track and count your users, you won’t be able to see me. i’ll be missing in your statistics, even though i accessed your page. (and since i’m advanced enough to use addons to see where my data is supposed to be sent, i know how much you care about my data, and how much i can trust you.) so i do appreciate if sites do not leak information.
there are two basic strategies to avoid leaking:

• include external things only when the user needs them. for example, you could use javascript yourself to display a decoy version of the facebook like button or the google+ +1 button (stored on your server!), and as soon as the user clicks on it, your script loads the real button and the associated javascripts and forwards your click to them. or you just use a decoy version of the button (again, stored on your server!) and just link it, for example to a facebook url which will then allow the facebook user to share your page. for example, instead of the like button described above, you could do something like this:
  

  <a href=’http://www.facebook.com/sharer.php?u=http://url.of/your/site&t=Title of your site’ target=’_blank’ title=’Share!’><img alt=’Share!’ src=’images/facebook.gif’ /></a>

  here, images/facebook.gif should obviously be a image on your server.

• act as a proxy. if you want to show information, like how many people like your page, show some faces who like it, show some statistics (how many users are online right now etc.), the usual solution is to include some javascript/iframe from the content provider (facebook, your web tracker, …), so the user’s browser will access the data directly from that provider. with the drawback that the provider knows that the user asked. (which is necessary for web trackers to work, but not for showing the numer of people who like a page.) there are also things which indicate your online status on skype, icq, or other services, which you can include in your page and which make the user’s browser access some other site. for most instances, one can avoid this problem by adding some kind of proxy: instead of making the user retrieve some (automatically generated) image, you link to a script on your page which retrieves the image from the provider’s server and forward it to the user. then the provider just sees that your server is asking for the picture, while the user still sees the information on the picture without giving information to the provider.

note that both strategies give you (more or less) extra work. especially setting up a proxy script on your server is very non-trivial, if you cannot just use something publicly available. and more importantly, if you do not have good enough access to the server – for example if you have a blogspot blog, or a wordpress blog running on wordpress.com – you are severely limited in what you can do. also note that you can combine the strategies. for example, if you include many youtube videos, and you use a javascript to only start the flash player when the user clicks on it, you could use the proxy strategy to let your server automatically retrieve the picture from ytimg.com which is shown until the user clicks. [edit: this post describes how this can be done. both spielwiese and musikwiese now use this technique.] note that it is also a good idea to check your own site for leaking, sometimes you’ll get surprises as certain plugins for wordpress for example include javascripts from random places, sometimes completely unnecessarily. for that, you can use firefox with noscript and requestpolicy installed (if you don’t like the addons, disable them but install them anyway, to be able to enable them from time to time to test your own site) and browse your site. in the firefox status bar, you’ll see a flag for requestpolicy; if it is red, then requestpolicy blocks something. click the flag to see what is blocked, and to allow (or block) certain destinations. you can also use this (as well as noscript) to test which (external) javascripts are needed for your page to be usable.
you have to decide for yourself how much data you make your visitors leak. and remember, most visitors appreciate that you don’t spread their data unnecessarily. and some visitors can even check what you’re doing, and know how much information you (try to) make them leak.

as once announced, i worked on spielwiese‘s gallery system. it is now featured by a c++ backend which generates the galleries as well as the thumbnails (if they aren’t already there), both in grayscale and color! so far, the galleries are shown as before (with some exceptions, mostly in the beginning of the blog though), but on every page you can find a clickable text in the footer, on the very bottom of the page, called “change colors!”: this toggles the thumbnails between grayscale and colors! unfortunately, this currently does not remembers the value (by setting a cookie), so if you reload the page everything will be grayscale again. but the most important part, namely the backend, is there! and maybe it will remember the state before the end of this day :)

i programmed a bit to create a mechanism which feeds the photos to the user without giving direct access to the files; now, all photos are stored outside the range of the web server, and retrieved by a php script. this brings me one step closer to my goal of making parts of this blog really private. before, photos appearing in hidden posts were somewhat public in case you knew their url. now, you can only access these photos if you are logged in and have the rights to see the corresponding post. the current authentication solution is kind of a hack, but it works. if you just use the blog, you will note no difference – except that photos in old posts which your feed reader did not update are broken. i’m sorry for that. google reader, for instance, should update at least the more current posts sooner or later.

spielwiese moved to a new server today. it’s way faster now, as you might have already noticed. unfortunately, the ad rotator plugin which i used to display the random lyrics stopped working, probably it doesn’t like the php version running here. maybe i’ll replace it at some point…