Author Archives: Ton Zijlstra


Building an IoT Infrastructure for My City

Earlier this year a group of Internet of Things enthusiasts in a month or so launched an open communication infrastructure across the entire city of Amsterdam, enabling anyone to let their IoT devices communicate. Without the need for 4G, Wifi or BT connections, it uses LoRaWan, which allows low bandwith but long range traffic, at low energy usage levels. They call it The Things Network.

Currently The Things Network is running a Kickstarter campaign to bring LoRaWan devices into the hands of more people, and thus create IoT infrastructure in more cities. The gateways on offer cost about 20% of what similar devices cost, and this is a great opportunity to implement a solid city wide infrastructure at very low cost. With an old fraternity friend, Ian Kennedy, we are now looking to create such an infrastructure for my hometown Enschede.

The Things Network from Soda Content on Vimeo.

Enschede is a town of about 160.000 people, and covering the city will require 3 or 4 gateways, to which nodes and devices can connect to communicate. Both Ian and I ordered a gateway through the Kickstarter campaign, and are now looking to connect to more people locally with an interest in IoT. Ideally one or two others will also fund a gateway, ensuring city wide coverage. The coverage between the two of us is shown in the image at the top, and as you can see especially the southern suburbs still need coverage. We will likely also reach out to companies and the city government to see who else is interested in experimenting with this new infrastructure. As delivery of the devices is scheduled for late spring next year, still a long time away, we have plenty of time to get the ball rolling before that.

Interested in making Enschede IoT ready? Join the newly created mailing list Things Enschede (running on my own mail server), and/or help create the infrastructure by adding hardware through the TheThingsNetwork Kickstarter campaign. We will aim to organize a meet-up in November to get local conversations going.

If there are a few others willing to join us, we will certainly add Enschede to the growing list of cities in the The Things Network community. UPDATE: Others are indeed also active, and have been arranging gateways too. That ensures we will have enough hardware to get city wide coverage up and running. Meanwhile a local Enschede community page has been opened, but not yet filled.

Why False Dilemmas Must Be Killed to Program Self-driving Cars

MIT Technology Review: Why self driving cars must be programmed to kill
An article popped up multiple times in my Facebook-stream in the past days, titled “Why self driving cars must be programmed to kill.”, published in the MIT Technology Review. I think the “impossible ethical dilemma” the article says it posits is false. I think saying that it needs to be solved “before they can become widespread” is even more wrong as the problems will be in the transition much more than in the new normal.

Google’s self-driving car
photo Saad Faruque

Autonomous cars will not become mainstream because they know what is the ‘morally right’ thing to do in screwed-up situations. They will be mainstream because they will not allow those screwed-up situations to arise. Unlike us. That is the point of self-driving cars: not to be like us drivers, but to be unlike us.

In fact self-driving cars will not be autonomous at all in the literal sense. They will be networked-driving. They will be autonomous only relative to the passenger formerly known as driver, but in synchronisation and negotiation with everything else.

Let’s look at the false dilemma first
The premise of the article is that a car ends up heading towards a group of ten people in the road and no time to stop. It then has to choose: run over those 10 people, killing them. Or drive into the wall on the side, killing the driver. Or alternatively driving into the same wall on the side, killing a child or a granny standing there on the sidewalk.

The first question here is not what the car software should do to figure out ‘the right thing’, as the article says however. The first question is, how on earth did a self driving car end up in a situation where it was ‘too late to stop’ at all? The article lamely explains how such a situation came up: “One day, while you are driving along, an unfortunate set of events causes the car to head toward a crowd of 10 people crossing the road. It cannot stop in time.” The solution however is in that lead-up that is not described.

The two key elements here that cars need to solve, so the ethical choice above need not be made at all, are:
1) preventing ‘unfortunate sets of events’ to arise in the first place
2) preventing it is ever ‘too late to stop’ by erring on the side of caution

Autonomous cars will not go where there is no data

The last one is a good example of how self-driving cars already are different from human drivers. If a human has insufficient data he will keep going on (I assume there are likely no obstacles on my road until I see otherwise). If a car has insufficient data it will slow down or stop (It won’t move until data tells it there is no obstacle to moving). Autonomous cars will not go where there is no data.

The first one, preventing an ‘unfortunate set of events’ requires more attention therefore, as it contains some assumptions to unpack. But the short answer is: it’s not just the car.

The car is not the sole unit of sensing, nor the sole source of data
There seems to be an underlying assumption in these discussions that the car is the only unit with sensors. There is no reason why that would be the case when autonomous traffic is widespread, or even before. Everything will have sensors.

Sensors are cheap or getting cheap fast. All cars have them, all phones have them, buildings have them, and realistically every road sign, lamp post, piece of road surface, piece of clothing can have them too. If they don’t already.

A self-driving car will be able, and needs to be able, to take in data from external data sources, to get a better understanding of its environment. Those external data sources can be anything and are already growing up in parallel to the self-driving car, ready to be used.

Lamp posts in the inner city of Eindhoven (Living Lab Stratumseind, link in Dutch) already monitor noise levels, crowd movement, and detect altercations. They can change light levels and color to influence passers-by. These lamp posts already are registering the 10 people from the dilemma above and their overall behaviour, and are able to tell your car before you come around the corner, allowing a car to reduce speed anticipating they will suddenly cross the road if their behaviour indicates such a thing. So it will stop in time, or avoid needing to stop at all.

All main roads in the Netherlands already know the number of vehicles passing by in each lane and their speed at any given time, and all that data is published on-line in real time. Those sensors already now are able to tell you whether you should be slowing down because traffic in front of you is denser or slower than you, well before you see their tail lights. Parking spaces along roads in various cities already know if they are occupied or in the process of being vacated. Intelligent Transportation Systems (ITS) in general are blanketing the EU road system in sensors.

Data pheromones, just like ants, will keep us from bumping into each other

The cars themselves will also be communicating and sharing sensor data. Allowing your car to ‘smell’ unexpected crowds of pedestrians blocks away, and navigate around it, with ‘data pheromones’.

Tesla cars already compare notes amongst eachother, and “work as a network“. Your own car already takes in satellite data every journey. Your own navigation software already shares your car’s behaviour with every other user of that software, to help detect detours, traffic speed changes, route changes, roadblocks and traffic jams. Beyond sharing descriptive data, any other machine actor could just as easily share intentions (“I will turn left in 250 meters, and slow down for it starting in 90 meters / 5 seconds”), allowing others to pre-emptively respond.

The omnipresence of data sources will only increase. The road surface can tell if it is covered in oil, water or ice, and slippery, and let the world know. Traffic lights already can tell what speed of approach will allow you to get through fastest and could let your car know. Where a human driver would try to run an orange light, an autonomous car would stop if it knows it would not influence the overall speed of its journey or that stopping would allow a ‘green wave’ in subsequent lights.
Even the phones of those 10 pedestrians in the original dilemma are able to detect and signal sudden changes in speed and direction, and soon sensors in their clothing or shoes might too.

When the roadsurface, lamp posts, phones and clothing, every car, or every other vehicle (bike, skateboard, moped) around you are part of the eyes and ears of your car, all to better navigate and negotiate passage, there will be no surprises. Surprises happen when you have just one range-limited sensor: the eyes of the driver.

The autonomous car software will take advice from anything around it, except your and my brainstem

An autonomous car is not autonomous really, other than freed from the driver’s control. It is driving on tracks just like existing driverless metro trains, except these tracks are made of data. Where those tracks run is continuously shifting based on all traffic actors continuously negotiating passage, and the signalled actions and intentions of every other actor.

The car will not be the sole unit of decision making either
Another faulty assumption I think is to see the car as sole unit of decision making. Just as anything around the car can be providing data, anything can also be an actor itself, forcing a response from ‘my’ car as it sees its environment changing. Every other vehicle, and immobile objects too, will make decisions.

Road surfaces can go beyond merely detecting they are slippery because of ice, so that cars decide to slow down, by actively declaring itself closed for the coming 23 minutes and 42.5 seconds while a salt truck is on its way there. Road signs, taking data from lamp posts about increased pedestrian activity can signal to change the road to one-way traffic or close it off until the crowd has dispersed.

Traffic will ride on tracks. Tracks made of data. Traffic rules will be fluid, and traffic flow emergent.

Sensors are cheap, and adding algorithms to each of them to act on its own sensor data is not much more expensive. Where traffic rides on tracks of data, the rules of traffic can be datafied too. Fluid traffic rules will result, and autonomous cars will obey them (and even if they don’t all other actors will see that in the data streams and adapt accordingly).

Saying the self-driving car is not autonomous other than from the previously needed driver, is not the same however as saying someone else or something else is at the helm. There no longer is a helm to be at. There is just traffic flow, emerging from the negotiated decisions from each actor continuously optimizing its journey by endless series of ‘probe, sense, respond’.

Existing ongoing analog trends will also play a role
Already in many cities around the world various types of traffic are separated into different streams. Separate lanes, or even separate routes altogether. Where that separation is not possible other measures (like speed reduction in residential streets) are usually taken. With all those things also becoming reflected in data, it will be even easier to do. It will also be much easier to locally change the primacy of the car in traffic design on the data level than in physical reality.

False dilemmas shift attention away from getting solutions faster
So the solution to the article’s ‘impossible dilemma’ is to not just look at the system ‘car with sensors and software’ but at both the other similar systems (cars, pedestrians, bicycles) around it, and at the super system it operates in (the road, built up environment, road design, traffic design) as well. The car will stop in time because the lamp posts, grandma’s coat, the road surface and every other sensing object will collaborate with it to there being no urgency at all.

So no ethical dilemma’s then? On the contrary!
While choosing to run over granny or crash into a group of ten other people is a false dilemma, there are many other real ethical dilemma’s to solve.

The article in MIT Technology Review suggested the false dilemma needs to be solved as a precondition of autonomous cars becoming normal. I think the period before those cars are normal will be much more challenging. When only a handful of cars are rational actors because they are autonomous from drivers, they will be experienced as weird and unpredictable by you and me who still have only our eyes to go by.

We’ve got 99 ethical problems, but killing granny ain’t one.

When we do get to mainstream, when traffic has become highly datafied, including street signs, lamp posts, road surfaces etc., there are many ethical dilemma’s as to who gets to influence the algorithms and data streams a car takes as input. Already in the US cars are being remotely shut down if their owners don’t pay their car loans on time. Should that be allowed? Can local government declare an entire neighbourhood a no-go area for specific groups of, or all, cars by having the roads tell the data layer they are closed? Can your insurance company tell my car to not do something? Do we even need insurance? Will individual car ownership still make sense, and if not, who then owns fleets? Can a lamp post be allowed to discriminate who gets to drive down the street (residents only!), or signal the police if it profiles a car as burglars? Can cars even be used by burglars anymore, because the cars know where they’ve been, and the lamp posts know which cars were there?

And right now, can we see, check and change the software in our cars? Can we see what type of algorithmic influences have been programmed in? No, I can’t, nor can I for most other sensing devices around me. Don’t you need to know how your current car, drive-by-wire as it already is, makes autonomous decisions? Already your Volkswagen autonomously decides from sensor data if it is on a test track or out on the road, and changes behaviour accordingly. Already John Deere tractors is ready to sue farmers for checking and altering the software on their tractors, basically arguing your tractor isn’t yours, you’ve only rented a license to an operating system.

So the conclusion of the article I fully share: we need an ethics of algorithms. Just not for deciding when it’s ok to run over granny.

When Working IT Provides Smooth Service

Over the years the Dutch public transport RFID card system has been weird and dubious in various aspects. But apparently some things do work very nicely.

Last Friday we left for Milano for a few days to go to SOTN15, making a short stop in Amsterdam to visit the Van Gogh Museum’s Munch exhibit. Somewhere between the museum visit and dinner near Museum Square I lost my national railway travel card with photo id. Frustrating, and I imagined loosing a lot of time getting it blocked and replaced. I still had a random anonymous RFID public transport card in my wallet, and I used that to get to the airport.

There I looked online what to do to get a replacement. It turns out I could disable my lost card immediately online, and apply for a new id card.
More importantly I could also attach my rail travel subscription to the anonymous RFID public transport card I still had, by entering the card’s number online. I did that, and used it after the weekend to get back home from the aiport, while still enjoying the reduced fares I normally have.

When I got back home, my new RFID card with photo ID already had been delivered and was waiting on the doormat. All my subscriptions and automatic top-up are on it again (except for the bike rental subscription which I had to re-attach online myself, as the accompanying letter explained). The money on the lost card was reimbursed automatically.

A surprisingly smooth and painless experience that took me a few minutes at most.
I spent more time going through my pockets searching before conceding my card was gone, then on fixing the problem.

Largest government spending is also the least transparant

Tuesday will see the presentation of the new Dutch national budget, during the traditional opening of the parliamentary year, ‘Prince’s Day‘.

58% (153 out of 262 billion Euro) of the budget is allocated to social affairs (78 billion Euro), and healthcare (75 billion Euro). These two largest domains are also the two least transparant ones. For both domains little to none exists in terms of meaningful open data.

On the contrary both domains are notorious for their opaqueness. In the social domain a massive decentralization has transferred billions to lower levels of government, making the way they are spent invisible to both Parliament and the High Court of Audit. In healthcare insurers and hospitals are fighting the Minister tooth and nail over disclosing even basic numbers they are legally bound to make public, and freedom of information requests end up in court.

The budget shortfall for the next year comes in at some 12 billion Euro, or about 8% of our spending on social affairs and healthcare.

I bet increased transparency in both the social and healthcare domains can surface lots of potential savings, by exposing inefficiencies etc. Even if you shave of just a few percents of spending that way, it may actually fix the hole in the national budget completely.

Jennifer Granik on “The End of the Internet Dream”

An important talk by Jennifer Granick during the Black Hat 2015 conference in the USA “The End of the Internet Dream“. She talks about the things that threaten the internet as an open place, and turn it into an oppresive one.

To me this is all about agency, for which technology needs to be ‘smaller’ than me to enable me, not ‘done to me’. This means we need to have a right to tinker. One of the reasons open source hardware is hugely important the coming years, as increasingly manufactureres will turn their devices into walled gardens, or sue you if you play around with its firmware.

Read the transcript, or watch the video from 15:50 below.

Also see my recent posting “After 6 years in prison, how the internet has changed

Wuala Cloud Storage Closing Down

Wuala alpha
Wuala: From alpha in 2007, acquisition by LaCie in 2009, to being deadpooled 2015
(Image by Chris Messina, CC-BY-NC-SA)

Wuala, the Swiss cloud storage service, is closing down. You need to switch services by 30 September when Wuala will become read-only, and remove all your data by 15 November when Wuala will shut down. If you need to move and want an alternative that is end-to-end encrypted (and you should) then Wuala suggests another Switzerland based company, Tresorit.

Last year I briefly contemplated and tested Wuala when I wanted to get out of Dropbox (which is unencrypted and under US law). At the time I wrote

“Wuala, incorporated in Switzerland, is owned by LaCie (incorporated in France) which in turn is owned by Seagate (incorporated in Ireland). Their data centers are geo-redundant and in France, Switzerland and Germany. Although that looks good on paper Seagate HQ is in the US, placing Seagate under the Patriot Act, and thus Wuala ultimately too. Wuala for the desktop requires Java, which is a bad thing. Their encryption and syncing however are a plus, as is the ability to work in teams.”

Wuala was my first two steps away from Dropbox, as it provided client side encryption removing most of the key privacy concerns:

For now I have started using Wuala, as it is at least two steps up from Dropbox because of its encryption and their data centers in Switzerland, Germany and France. Their service is not ‘patriot act proof’ (and they know it, judging by their consistently vague and indirect answers in support fora), but the encryption helps address that. Of course there is no real way to check their encryption either.

My Wuala use lasted all of 1 week. Then I switched to OwnCloud through an Austrian provider, OwnCube, and a month later I started running my own VPS with OwnCloud on it, removing me from using third party services except for the server itself. (I must say OwnCloud does not support end-to-end encryption yet, and uses server side encryption. Hoping to see that change in the future.)

Re-arranging my email process

Last week I have made changes in the way I process email. Adapting it more towards ‘Getting Things Done’, which I had avoided doing for years, and making some changes in daily habits around it. Now that I made the change, I can’t quite understand what kept me from doing it, even though before I thought my needs would not be met with a new routine.

Resisting change
As I use Gmail and have the notion I really shouldn’t, I mentally postponed changing my routines until ‘after replacing Gmail’, assuming I would otherwise either increase the cost of leaving Gmail (by having routines more deeply connected to its functionalities), or I’d find a replacement that already contained a better flow by default, making designing change now a waste of time. I know, neither make much sense upon closer consideration. Likely the real reason I made the change now, is having come back from a long vacation, and not many obligations yet as most clients are still away themselves. That, and receiving an external trigger right at that moment.

The trigger
That trigger was getting a message from Martin Roell, that one of his colleagues, Rob van den Brand, is offering a free download of how to deal with email. I downloaded it ouf of curiosity to see if it contained anything new in terms of suggestions. At first glance it didn’t, it was the GTD style approach I already knew (using the 2 minute rule, sorting into piles to reply, read, do and other etc.). Then a few days later a follow-up arrived with a few behavioral tactics to help make the mechanism work. The first one was unsubscribe to a lot of stuff, which led me to review my automated filtering, which led to re-evaluating the original GTD method, which led to implementing it……

The old routine
Over the years I kept all my e-mail in my inbox, always. Piling, never filing (tagging I do). The original reason for that was that my first mobile e-mail app would not let me easily access and search archived mail, only what was in my inbox would be readily available. The first step of my mail process is usually on my mobile.

From the newly arrived mail, I would ‘star’ those I thought would need some sort of follow-up. Things that don’t interest me I would leave unread but not throw out. This would be my basic triage method. I also have various filtering rules that label incoming mail (apart from ‘starred’) according to what part of my professional activities they represent (my company, my fablab stuff etc.) Using Gmail’s multiple inbox feature, those stars and labels were presented on my laptop screen as separate lists next to the main inbox.

At some point during the day I would open my mail (Gmail’s web interface) on my laptop and:

  • mark all remaining unread mail as read
  • work through the starred items
  • look at/answer mail while working on a specific professional context (1 of the inboxes)

The problem with this was that a starred mail could still mean many things (migh be interesting, immediate action, little or lots of work, read, keep in mind etc.) I basically needed to reevaluate every single mail, every time I opened up the ‘starred’ list. Over time that list would grow with unprocessed items from the past, becoming a ineffective mental drag, except for the recently starred messages. Also some of the multiple inboxes had survived beyond their waned usefulness due to changing focus and activities, and I had difficulty putting them to new good use.

The new routine
My current mobile app (the place where I do my first mail triage) fully supports labeling messages and accessing archived mails. Functionality I wasn’t putting to good use. So that makes it possible to do more detailed and better triage on incoming mail. I now, following the GTD material I mentioned above:

  • use many more filtering rules to automatically process and label incoming mails, alerts, mailers etc.
  • have unsubscribed a wide range of mailers connected to long time ago interests
  • have moved some quarter million mail exchanges of the past years from the inbox to the archive
  • label the remaining few mails that still reach my inbox with 1_reply, 2_todo, 3_toread, 4_waiting and other assorted relevant labels (such as ‘bookkeeping’, ‘opendata’, ‘acquisition’ etc.) so they can be more easily found back when needed
  • create new filtering rules when a mail arrives that warrants a filter
  • empty the inbox by moving all labeled and remaining unlabeled mail into the archive

The original multiple inboxes I now show below new mail, in stead of to the right where I had them for the past years. The multiple inboxes now show the reply/todo/read/waiting labels. That looks like this:


Key take-aways and needs
Changing my mail process and method of triage turned out to be easy. It moved the decision what to do with an e-mail forward 1 step, and made it part of the triage. (Before I would only star a mail and then decide later). This makes my normal daily time slot for mail sufficient to actually deal with the contents of that mail.

Main ‘win’ is that my mail interface is much less noisy, both due to heavier automated filtering and removing processed messages from the inbox. Before I would see whatever was left over from ‘before’ and always have a full page of messages in front of me. That clutter is now 5 short lists, with only one of those lists needing attention at any given time. All other stuff from mailing lists are available under a label/tag, when I decide I want to catch up but never clog up the inbox.

My main demand, being able to do triage ‘on the go’, is still being met (and more automated than before). The reduced clutter also feels like it might be a benefit when I move out of Gmail.

The only thing to still do is to much better connect the list of mails labeled to-do to my actual task management tool (Things, by Cultured Code) and making sure they get the right follow-up that way. I could probably automate that, but haven’t figured out how to do that yet. This may mean that the to-do part of the mail flow will actually disappear from my gmail altogether.

Estonian E-Residency Granted

Ten days after I applied for e-residency in Estonia, I tonight received a message from the Estonian police and border guard that my e-residency has been granted. That is much quicker than I had expected. So now I will be waiting to hear when my Estonian ID card has arrived at the embassy in The Hague, so I can pick it up!

The e-mail saying e-residency has been granted

See my earlier posting “I applied for Estonian e-residency” for more info on why it is important, what it is, and how it works.

I Applied For Estonian E-Residency

E-government in Estonia
Estonia has build advanced electronic services for their citizens, and basically moved their entire administration into the cloud (which also makes it territory independent, along the lines of running your national administration as an operating system bootable from a USB stick.) Most of the services you need as a citizen are electronic now. At the core of this e-government service package is you electronic ID. This is what allows you to use those services, and also shows who else has been accessing data about you. Now that everything is digital, it also becomes possible to offer those services to non-citizens. This is what Estonia calls e-residency: an electronic resident having access to Estonian e-services.

You can be an E-resident in Estonia too!
Estonia is the first country in the world to offer ‘e-residency’, meaning you get an Estonian electronic ID card. This does not make you a citizen of Estonia, but it does allow you to use their advanced e-government services. Providing non-citizens e-residency is a bold new step. Now you and I can use Estonian e-services, if those are more convenient to us. This is amazing really, especially if, like Peter Bihr notes, your own government is not up to that level of service at all. Like Ben Hammersley puts it Estonia as “a nation is now competing with its neighbours on the basis of the quality of its user interface“.

Since the fall of 2014 anyone can apply for Estonian e-residency. Until April 2015 you had to visit the Estonian border police in Estonia itself to do that (and 1200 or so did!), but since then you can arrange everything through an Estonian Embassy or Consulate near you. Originally you had to visit twice. Once to apply, and once (after background checks) to pick up your ID card and login credentials. Since May it only takes 1 visit, the rest you do online!

I have applied to be an e-resident
I have been on a mailing list of the Estonian government since last fall to alert me to new developments. They already promised then that online application and 1 visit to embassy would be possible by December 2015 and “likely sooner”. As it was unlikely I would be visiting Estonia (although I enjoyed my 2013 visit to speak at TedXTallinn very much) in the meantime, I planned to wait for that online application. When the alert arrived in May I was busy traveling, and basically have been traveling until last weekend when we returned from a month in Italy.

But now, finally, last Monday, I went to the e-Estonia website to apply. I uploaded a scan of my passport, and a scan of a recent passport photo, and filled out some information (basically the info that is in the passport), I selected the Estonian Embassy in The Hague as where I want to pick up my ID, and I paid the 50,99 Euro processing fee through secure online credit card payment.
Currently they have a bit of a waiting list they said, because of lots of interest, so it may take a month to get processed. [UPDATE]: I received a message my application has been granted 10 days after submitting it. [UPDATE 2]: I received confirmation that my e-ID is ready for pick-up 3 weeks after submitting the request. Will pick it up in 2 weeks, when I visit The Hague.

Schermafbeelding 2015-08-03 om 12.46.49
Confirmation e-mail of e-residency application

So now what?
What can you do with Estonian e-residency? Four services are currently available to e-residents that aren’t citizens. Register a business, do secure online banking, administer a business, and digitally sign documents and contracts. If, unlike me, you’re not an European Union citizen, this also means e-residency allows you to easily enter the European common market. For me all four of those services are of interest.

You access all those services through Ervinal, the Estonian e-government dashboard. You can see below how that looks. If you are a citizen, or reside in Estonia, such a dashboard will show you all kinds of other things as well concerning education, pension, your car, healthcare etc.

Ervinal screenshot
Screenshot (mocked-up with my pic) of the Ervinal e-service dashboard

The X-bus as architecture
I’m professionally involved with the creation of National Data Infrastructures in various European countries. Several countries are creating such things, but they may have different starting points. In Denmark and the Netherlands internal efficiency and a layer of open data is the core, with geodata, businesses and persons being the key data sets. In the UK (which does not have a person register), the entire system is more focussed on semantics, and interfacing between government branches.

The Estonian system is e-government service and citizen oriented and that makes persons and electronic ID the very core of the entire set-up. They have an exchange bus called X-Road, where any other service (including private entities such as banks and telecom operators, or you if you are developing a web-app) can share data based on a person and electronic ID as key. Estonia established X-road in 2002, and there is a European project to make that available and interoperable in other EU countries as well. In 2013, X-Road processed 287 million queries in Estonia, or about 220 queries per Estonian citizen.

All data is decentralized, and the person concerned can see how the data is being shared and with whom (including a redress mechanism if you don’t agree). This is very different from e.g. the Netherlands, where my role as the citizen being described by the data is not defined at all, and the entire system is set up around internal processes about me, but not with me.

X-Road schematics, image taken from

Hack your e-residency!
The Estonian government is inviting you to co-develop the services that are available as an e-resident. In September a Garage 48 idea and hack session will take place, to “think outside borders” and put e-residency on the global map.

Planning for Impact with Open Data

On July 1st I gave a keynote at the OpenData.CH conference in Bern, Switzerland. I talked about using open data as a policy instrument, and looking at open data as a way to provide new agency to stakeholders around an issue, so they can create real impact. The conference organizers have published the video of the presentation, which you can see below, together with the slides I used.