What have IPV4 addresses and submarine cables in common? They are indicators for the client-server structure of communications on the Internet. The IPV4 address space should be gone by now - replaced by IPV6. This hasn't happened yet despite enormous growth in mobile and IoT devices. The reason this has not happened yet is that mobile service providers use carrier grade NATs to map private addresses to public ones. This in turn forces C/S style communication. Is this bad? Well, from looking at the traffic patterns in the Internet it looks like C/S communication IS the dominant type of traffic on the Internet. This is largely due to few content providers dominating content and using private CDNs to ship the content to users. Clients initiate the communication and after that it is all within the providers CDN. Which leads us to the second indicator: submarine cables. They are nowadays owned by single content providers for their closed networks.
More and more the Internet is split into a few content silos with the public transit channels becoming less important.
Ihe Internet of the future a big private CDN? Geoff Houston is discussing this in The Death of Transit and Beyond and Alan Mauldin adds additional information on submarine cables etc. Looks like the Internet is getting restructured and privatized even more. A good explanation and overview in German from Monika Ermert, Heise.de
Does this mean that the discussion about net-neutrality and the whining by carriers about the imbalance between content and transit needs to be reconsidered? At the first glance it looks like net-neutrality favors the big content providers and endangers public transit and its infrastructure. But if we look at the winners of anti-net-neutrality laws, we will probably find some telcom giants like AT&T and not the many small and medium sized ISPs which feel the pressure from CDNs much more.What becomes clear is that the original self-government concept behind the Internet is gone and will be replaced more and more by regulatory acts. Depending on the current political direction some sides are going to win and others are going to lose. What is sure about this is: the general public, small company newcomers and peer-to-peer architectues will not win at all. More on US monopolies in media can be found in Tim Wu, the master switch.
There is quite some commotion in the social media. Facebook and Youtube are deleting massive amounts of extremist postings. Zuckerberg is promising better protection of user data and there are rumors about Facebook creating a paid version without ads. And it looks like Facebook will enter the dating app scene as well. At the same time many people publish harsh criticism of the current social media sphere, e.g. Mike Loukidis with "The second time as a farce". And there are some interesting ideas and sometimes even running systems for a decentralized - perhaps only federated - social network.
Before we speculate about a new and different social network - and a real chance for succeeding- we need to clarify how Facebook is used today. A short query in my course on current internet topics uncovered some major use cases: Surprisingly, the "original" Facebook effect: finding friends and being found by friends is still seen as a core feature, even though most friends have been found by now. Some students mentioned getting infos about events or using the timeline alike an entertainment channel on TV. The bad news for Zuckerberg is, that in this age group (20-30) most accounts are not used on a regular base. But most did not cancle the account though. Some Facebook users use pseudonyms, most use their real identity. Some are aware of companies checking facebook accounts during the job application process and many are unsure about the effects on reputation if you have a Facebook account or not.
So why is Facebook no longer in use with many people? The students mentioned that the timeline contains too many things which are simply of no interest to them. They realized that communication with many people is simply impossible due to time reasons and lack of interest. And the massive amount of "brand" news is a real nuisance. In other words: the radical and extreme engagement model of Facebook turns out to drive people away, just as Mike Loukides had written in his blog entry.
So is it time to start a Facebook competition and what would be the chances of doing this successfully? One idea could be to create a very simple user interface - basically a google-like look-and-feel for social network information. I could subscribe to this because when I tried to cancel my account after 5 years of inactivity, the amount of crap that Facebook presented to me at login was simply a turn-off and I went to google to search for "delete Facebook account". Another idea would be to combine the current Facebook universe consisting of FB, Instagram and Whatsapp into one new servide. Students guessed that they are still kept separate for reasons of resilience in case the main product FB goes south. Finally, a payment service integrated into the social network could be a killer feature. Who could start a FB competition? All agreed that it should not be Google as they have proven that they can't do it. Somebody like Netflix perhaps? Adding a social network to their streaming offer? Or a highly integrated chinese giant corporation?
The final question is: should this new social network be distributed or federated? Going through some papers (e.g. Mathias Beyer's idideas for a dsistributefd social network and the comments on y-combinator it looks like going distributed is not a very realistic proposition right now. It is too complicated and there are many basic questions open without a clear idea for a solution. Previous distributed solutions like Diaspora were simply unusable by non-CS-people and current systems seem to be playgrounds for extremist views due to moderation problems. And how do you moderate a distributed social network?
Due to the limitations of current blockchain technology with respect to scalability, speed and costs of transactions (both environmentally and transactional), off-chain approaches have a lot of appeal. They do not use the blockchain to secure every single transaction. Instead they rely on an initial money transfer via blockchain and then allow micro-transactions between participants. Those micro-transactions are routed through a network of credits between participants. They are supposed to be anonymous wrt value, sender and receiver.
Settling payments fast and private: efficient decentralized routing for path-based transactions by Roos et.al. describes various routing schemes. Unfortunately, the paper is a bit disorganized and hard to read. The whole business background is not mentioned at all and we had a hard time in our Journal Club to make sense out of it. A discussion of the paper in morning club did not help much. It would have been better to start with the Lightning Networkto understand the business side first.
Still, some valuble insights could be gained. Credit networks backed up by blockchains seem to follow the same deflationary principle: you can give only so much credit to somebody as you really have. No virtual credits like in todays banking system and no chance to increase the amount of money in the system. Routing can be done via central landmarks or through a coordinate system as an overlay. The most interesting aspect was receiver anonymity. It does not work like an onion network (tor). The trick is basically for the receiver to generate a long route in advance which includes her own address but does not end there. Observers cannot know whether the transfer stopped at a certain receiver or not.
Many other points are still in the dark: a credit usually does not mean that at any moment funds can flow back. The arbitration and conflict resolution is completely unclear to me. s
After discussing GraphQL both in current topics of the Internet and our master journal club, GraphQL got much clearer to me. While Rest Uri are non-hierarchical (i.e. they focus on one endpoint and allow some query parameters on it, GraphQL uses Json to model a hierarchical view into a data model, much like SQL does. It allows the client to specify joins of REST endpoint data in a query and the server will use so called resolvers to aggregate the data parts and send a response in Json back. Basically everything that GraphQL does can be done in REST too. But providing all the query options in advance would be not only tedious in REST: it would also require many more requests (the n+1 problem of requests: a collection of items given back from a REST endpoint will require n more requests to the endpoint of the returned elements of this collection. An example: a bookshop wants to offer you the books your friends have liked. It sends a query to the friends endpoint of a social network, with your ID as a query parameter. A collection of friends of yours comes back. Now for every friend another request is make for the books they liked. And then the answer can be presented to you. With GraphQL all this is just ONE request. And on top of this: ONLY the data really needed on the client side are selected for the response. The client can e.g. say to skip additional author information. This means that GraphQL is an optimization for certain types of queries. It also decouples front-end and back-end development a bit as it allows many query types and subtypes. The queries are defined in a schema and controlled by the server, but subsets of queries can be spontanously requested by clients and need no work on the server side.
The discussions unearthed a few distributed computing problems: Powerful single-request queries require fan-out architectures on the server side in addition to performance intensive parsing of a context-free language. But there are many performance tricks available for this type of requirement like intensive caching, query optimization and so on. The response to the client needs to be paged as well in case there are many data. The protocol probably allows paging hints on the client side or will include paging information in the response about additional data being available.
GraphQL is easy to understand and - due to some good literature led to a good discussion on the differences between REST, SQL and WebServices in general.
When you see how digitalisation changes work organization (like in the post below), it makes you wonder if this is only the result of e.g. an agile methodology being used. Or if there is something even below that socio-technical level. The book "Culture Code" gives a clear an simple answer by explaining three core rules for team culture:
Create a safe space! By doing so you encourage team members to take over responsibility and voice concerns and new ideas. Blameless post-mortems are key to that. Encouraging a failure culture, supporting struggling members and avoiding ego games and extreme competition, you help creating that space. Without it, members will hold back and run defensive strategies.
Show vulnerability! Show that you need help in a leading position. Show when you have no idea on what to do and you will encourage people to step up and help solving the problem. It motivates members to play an active role and much better results will show up.
Create purpose. That is probably the hardest one for many leaders. It requires charisma (something not easily learned but mostly given) and other abilities like touching somebodies heart and soul. It is best explained by the famoud quote from Antoine de Saint Exupery about building ships. If you want ships you should not teach your people about hammers, nails and planks. Instead, you should create the longing for the sea in them. In more earthly terms it means to share goals, keep your people informed, notice when they start getting anxious or think that goals are unreachable and in general follow the principle of "loosely coupled, tightly aligned" (Netflix). If your people do something stupid, ask yourself what you missed telling them. (Netflix)
The book explains the principles with stories from the military and corporations. Stories about very special people who can create excellent teams, sometimes mostly by listening to people. It is easy to read but gives you the explanation for spectacular failures of some methodologies. It is not the methodologies (scrum, extreme, Prince II etc) that fail, it is the social base that the groups are missing!
A few comments on the talks at our Interaction Day. First, there was little about UI/UX and lots about organizational changes due to the fast going developments in digitalization. The first talk brought back an alumnus who had only two years ago left our faculty and started work at stoll.von Garti, an Internet agency working on process automation topics in the industry. Much to his suprise our alumnus told us, he found himself not right in the development group but deeple involved in customer relations, concepts and architectures. The project involved optimizations through bluetooth beacons which make industrial devices much trackable through mobile phones etc. The corresponding mobile apps were developed according to user centered design principes and the overall process hat many agile elements. While optimization seems to rule in the IoT area, AR and VR provide ample opportunities for ground-breaking developments.
The second talk came from Siemens Karlsruhe - a 4000 heads strong location of the Siemens corporation. The talk centered on agile methodologies and architectures like cross functional teams, scrum, best of breed software languages and products, supporting tools and basically everything that helps to speed up development. It was very obvious that Siemens has read the papers on corporate culture of the Internet unicorns and carefully picked things that help without destroying everything. The speaker claimed full support by top management. Development groups have the autority to decide on technology and method and communication between cross functional teams is supposed to keep choices within reason. "bottom up intelligence" is clearly no stranger at Siemens Karlsruhe and they seem to be proof of successful transfer of agile culture to large corporations.
The presentation included a short video Digital Enterprise -implement now, Siemens at Hannover Fair 2018. I may be wrong but to me videos on digitalization tend to show people in a rather special way: mostly alone against machines, watching, observing, monitoring. There is no tight interaction shown. Frequently machines (robots) take center stage. I am not sure if this is the right way to show the future interaction between humans and machines. Humans are bad monitors. And why would you need humans to monitor if machines are much more reliable observers too? To me it looks like the optimization approach mentioned above automatically leads to humans becoming mostly superfluous. We need to reach for new goals to make the combination men-machines useful and necessary.
The final talk by a top manager from AEB - a company that runs about 30% of Germanies export/import data on their machines and software - centered even more on the mixture of emotions and agile methodology: "Scrum Yoga" is their concept of basing the methodology on Scrum without beeing too religious about the rules. "Principles are more important than rules" is their motto and this helps to introduce the methodology at customers who are not willing to a) learn scrum completely and b) hire a Scrum master for the project. AEB made a list of 5 topics which they found most important for project work: self-driven responsibility, time-boxing, customer centricity and the last two I have forgotten... The AEB speakter was very clear about the emotional side of work and emphasized, that knowing what drives people is key on supporting their development. AEB is also fairly new to agile methodology (5 years compared to 35 years of classic project management) and not everybody was initially keen on getting on the agile train at AEB.
What are the key lessons learned this afternoon? Digitalisation really seems to change everything, including the internal organization of work. Self-controlled and managed work is key. Hierarchies play a smaller role. People only stay when they find fulfillment in their work and that means that work has to be fun. If you hear about the changes necessary to be fast and digital, it makes you wonder when and how this wave will reach the universities. There seems to be an abyss between industry and academy in our days and it looks like academy has no clue on how to bridge this gap. But that is a topic for a different day.
There is a paragraph in Harari's "Homo Deus" that is almost visionary when you look at the current situation in Britain, Germany and other western countries (except the USA). ““Ordinary voters are beginning to sense that the democratic mechanism no longer empowers them. The world is changing all around, and they don’t understand how or why. Power is shifting away from them, but they are unsure where it has gone. In Britain voters imagine that power might have shifted to the EU, so they vote for Brexit. In the USA voters imagine that ‘the establishment’ monopolizes all the power, so they support anti-establishment candidates such as Bernie Sanders and Donald Trump. The sad truth is that nobody knows where all the power has gone.” ”And, a few lines later: ““Precisely because technology is now moving so fast, and parliaments and dictators alike are overwhelmed by data they cannot process quickly enough, present-day politicians are thinking on a far smaller scale than their predecessors a century ago. Consequently, in the early twenty-first century politics is bereft of grand visions. Government has become mere administration. It manages the country, but it no longer leads it.”― Yuval Noah Harari, Homo Deus: A Brief History of Tomorrow ”
Harari quickly adds, that not all visions have been good, and that a state that just needs administration is probably not in a bad shape. But it leaves a void. A void that is even more problematic as after 40 years of Neoliberalism and the triumph of human liberalism, the field of public participation and engagement has eroded. The idea of society as being fair und just and for everybody to live in comfort has disappeared and been replaced by market religion. Who are the culprits? The digital revolution with its massive influence on our behavior? Jakob Augstein has collected several opinions in the new book "Reclaim Autonomy" but if you read through those, they mostly blame the big 5 (Google, Facebook, Amazon etc.) for all the evil that fell on us. (I am going to comment some more on this book later). The refugees overwhelming the western states have become another negative vision and it has been claimed by the far right corner of the society (Filling the void left by the dying social democracy). I recently went to a talk by Harald Melcher on "the process of civilization" where he claimed, that we seem to have no positive visions left. Which visions are we currently left with? The "data religion" as described in Harari is a rather cold and techno-centric vision that leaves lots of people not knowledgeable enough in Cybernetics and Biotechnology behind, as he admits. And then there is only two others left: The dream of an Islamic world according to the IS, or "lets make America great again", which is an isolationist and backward looking vision.
Again: where did all the power go? It went into process. James Beniger's Control Revolution is now - supported by Big Data and Machine Intelligence - running the world like a clockwork. Except that some of those processes are on a track that is going to hit obstacles rather sooner than later. Obstacles like the climate change, the pension problem, automations effect on jobs, diesel exhaust gases etc. ( TTIP would have been the mother of all control revolutions: economy regulating itself with the help of some lawyers from New York and London). People notice those problems and -as they have a lot to lose in western societies - they get scared. People know that they are only passengers in the western representative democracy. And now they wonder if there is somebody left in the driver seat. Fear turns into rage easily and that is what we see.
How about driving by yourself? Well that's REALLY uncomfortable for all participants, but mostly for those in power as can be seen with the BREXIT. Or with the Trump election which surprised the political elite and Silicon Valley a lot. I don't think people are unwilling to accept change. They accepted the Energiewende and are paying for it. Just to see later on, how it got lost somewhere. The economic imperalism behind globalization, Europe, TTIP etc. is now causing its downfall als people are starting to lose trust in the systems. Will more direct democracy replace the losing power of representation? The economy and political parties will fight it to the end, as it is quite uncomfortable for "the process". It is so much easier to tell people, that things are without alternative ("alternativlos" - Merkels most favourite word). But how come we hear about alternatives like free public transit once the political establisment faces a serious crisis like right now in Germany? That leaves us with the hope that change is still possible! For the rest, I guess we will just have to wait and see what is going to happen in Asia. Could be that they are not only taking over economically but also with respect to future visions of society based on social credits.
I wanted to write a bit on security several times now but never really got around to do it. It started when Linus Thorvalds and the Google team that chases security problems had that little dispute on how to deal with security relevant bugs in the kernel. While the Google team implemented a hard kernel panic when they realized some exploitable bug, Thorvalds got mad and told them to fix the bugs instead of shutting down live systems. I guess both sides have some good arguments for their strategy. I am sure users hate kernel panics which in most cases would not have prevented a security exploit because the system wasn't under attack anyway. But what if the bug doesn't get fixed because nobody cares?
That scenario reminds me about something that happend when I was a young system programmer in the Unix kernel devision of Siemens. As usual in such kernel teams, young professionals take over responsibilities for drivers and other low level stuff and gradually move into more complex areas. One morning I had just started my workstation and ran a testprogram against one of my drivers, just to be rewarded with a nice kernel panic! As more and more developers slowly trickled into the office, you could hear astonished calls throughout the floor. Soon we realized that we ALL got those panics with our respective drivers! What had happened. As usual, a new kernel had been built over night and we installed it in the morning on our development machines. Something had to be wrong with the kernel built last night. We started to look at the error message which said something about interrupt levels not being cleared at return to user. Hm, sounded kind of strange. Finally, after some confusion, guessing and reboot, a mail from an experienced developer in the kernel team told us what was going on: He had detected one major reason for performance issues in the kernel: Many drivers have to block interrupts from the hardware while they are doing critical operations like updating shared structures (this was in the old days of monolithic kernels and shared threads between kernel and user area). After the critical section they unlock interrupts as quickly as possible because otherwise events from the hardware are not handled as fast as possible. The problem was very simple: The driver developers tended to forget the unlock operation. We all know that developers are unable to handle pairwise operations, because there are endless ways of bypassing the unlock statement. This is true for memory allocations, open/close style APIs and of course also for locking and unlocking interrupts. Some kind soul had made a little change in the kernel at exactly the moment, when a users call into the kernel would return to the user. If the interrupts were still blocked, the code would simply reset the mask and unlock everything. It may have even printed some warning in some logfile, but I never saw anything and most developers probably wouldn't have cared anyway.
After many futile attempts to make the colleagues aware of the performance consequences of forgetting the unlock call, he simply changed the code at return to the user into a call to panic! What can I say? It worked. On that day EVERY driver developer found SEVERAL places in his or her code, where the unlock call had been forgotten. The impact on kernel performance was measurable. Of course everybody was mad at the guy who changed the code to panic. But honestly - would things have improved otherwise? It would have been better to tell the colleagues in advance about what he was going to do. But changing the code to panic was definitely the right way to go.
Is this example the same as calling panic when a bug is detected, that might have a security consequence? Yes and no I guess. Yes, because it WILL cause the bug being fixed quickly. No, because unlike the first case, the kernel itself might be corrupted. And how would you deal with this? In the first year of my work as a kernel engineer I remember a course from Instruction Set (a British company doing IT-courses). I saw a call to panic in the kernel code and asked why the code did this? I remember saying that this could cause data loss for users and that there should be a better alternative. The instructor simply asked: Which one? Once a kernel discovers an inconsistency in its own data structures, it cannot trust anything within the kernel anymore. By continuing and trying to save user data e.g. it could even destroy more of those data. So the best decision is to stop working at all. (on a sideline: what if the kernel would run in an autonomous car? Can we just call panic? I guess not. So what kind of architecture is needed in this case?). I don't do kernel work anymore and I don't know how microkernels could handle those situations better. But I think if a cloud datacenter discovers that its zookeeper cluster is inconsistent, there is little that can be done except for a reboot of everything if a fallback to a previous, consistent state is not possible. It is like in the case of the lost Ariane rocket due to an exception not handled. It sounds really stupid to lose a 500 Mio Euro rocket because of such a thing. But once you start thinking hard about other options you realize that those are far and few.
So how should we handle bugs in the kernel that (might) have security consequences? Are they just bugs as Thorvalds claims? I tend to agree. A potential buffer overflow is a software bug first and for all. The fact that it can be used for a security exploit is secondary. Bad input validation that crashes or corrupts an application is a software bug and nothing else. Quickly pointing at potential hackers or even blame them for insecure systems just lets developers hide behind their buggy and bad code.
This brings us to another trigger for writing all this: the paper Adrian Coyler discussed today in the Morning Paper: Daniel Bernsteins 10 year old paper on his product qmail. Reading how Berstein created qmail without a security bug in many years makes you realize that secure software IS possible. And sadly, how little changed in software development with respect to security in all those years. One year after the Bernstein paper Roland Schmitz and myself published our second book, this time on secure systems. We discussed the Bernstein paper in our book and extracted his methods for bug-free software to be put in our toolbox for damage reducing systems. And Adrian Coyler mentions three things Bernstein said to not do: Don't blame insecure software on hackers. It is your software bugs that make the attacks possible. Not the other way around. Don't focus on attacks - focus on making your system robust, e.g. with watching out for integer overflows.
People are usually suprised when I claim that pen-testing is a very limited and unsustainable approach to secure software or systems. But pen-testing won't make your systems any safer except for the few bugs found an fixed. Nothing in the architecture has been changed and you are just waiting for the next security bug to be detected by hackers. As Bernstein said, we need to fix the foundations of our systems and the way we develop software, not focus on attacks.
Coyler was surprised that Bernstein accused the concept of least privilege to lull us into a false sense of security. Bernstein said, that minimizing privilige does not mean minimizing trusted code. And he is right of course. Trusted code is nothing else than "ambient authority" lying around, waiting to be exploited with attacks like "confused deputy". If those terms don't mean anything to you, read our book or go to erights.org for further information from the capability movement.
And with the last of Bernstein's no no's: speed over security, we get straight back to todays problems. Qmail carefully splits dataflows between users and lets those flows run with the respective users rights instead of root. There are certainly faster ways of doing things, but are the as safe? And a total focus on performance over security seems to be behind todays IT-nightmares with the names Meltdown and Spectre. The morning paper has discussed the main scientific papers and on highscalability.com the latest papers on Retpoline - Googles magic code rewrite technology that supposedly even cures Spectre-attacks (this is actually disputed) can be found. I won't go into the details here but one thing is clear: we could have known this long ago. Two years ago in my master seminar we looked at Intel Uefi and system management firmware attacks. The firmware used unprotected function pointers to call into the OS. A year later we learned about major problems in Intels remote management firmware. I do not know any fundamental cure against covert channels. It is true that the attacks mentioned combine an isolation failure caused by parallelization with a covert channel. The isolation failures itself would be inconsequential. But again, as no fundamental cure against covert channels is known (finally, all information processing has a physical dimension as well, which, given exact tools, can be traced and measured. This fits nicely to the revelation, that EVERYTHING on earth is uniqe and can be used for identification, as long as tools have the necessary granularity for their measurements. From how far can we read RFIDs? Your CPU/Network Connection etc. are all unique even without IDs, just because of their unique behavior.) optimizations for speed that weaken isolation (e.g. shared branch prediction) turn out to be deadly. Looks like hardware developers are not so much different from software developers. Bruce Schneier in his January cryptogram predicts 2018 to be the year of the processor bugs. Now that researchers really take a look at what is going on in our CPUs we can expect many more problems. Just compare the features of a 8088 with todays core-7 CPUs. When I started developing system software I frequently had to port realtime executives to new CPUs. Since we were only developing in C, few assembly code was needed for interrupts and context switches and a short look into the CPU handbook usually was enough to come up with the necessary code. I probably wouldn't understand half of a Intel handbook on core-7 CPUs. Hardware transactional memory, support for VMs and way below the surface the translation from CISC to RISC. Not to mention the magic chip designers use to keep the CPU cool by turning off units etc. I think Schneier is right, it will be an interesting year for everybody responsible for critical infrastructures.
A litte bit of guessing: I would pick complex features like hardware transactional memory to find race conditions and isolation breaking optimizations for performance. I remember a chapter in Jim Gray's famous book on transactions with the title "A shadow world" (or something close to it). To speed up parallel transactions you let every one work on its own copy of the world and at the end cancel those histories which can't become reality due to conflicts. This requires extensive state management and I suspect that there are many functional units involved which will show side-channel effects both for sensing and acting. A test scenario would be to run parallel HTM blocks in different processes and look for cross-process influence.
So what can we do for those infrastructures when our whole hardware/software stack is compromisable? Only the overall architecture of a critical infrastructure can bring damage reduction and resilience. No single IT component will do. Concentration and remote control will weaken our solutions. Decentralization and data flow over control flow will harden them. Many and sometimes even expensive or unconventional ideas will have to be used to ensure damage reduction. In my talk on our security day I gave an overview on the desperate situation in the industry and some ideas for such a system. Looks like the talk is still quite relevant.
Another Gamesday is coming up with a broad an interesting line-up of topics and speakers. We will start with a technical talk on rendering techniques by Clemens Kern, a long term game engine specialist and Alumnus. Next, Simon Haentsch will explain his way into the game industry, followed by Alina Dreesmann from Deck13. She will show us, that environmental storytelling removes the need for huge numbers of NPCs. Finally, Maximilian Krauss from our games institute will show you, how the serious parts of a serious game can indeed improve your game experience. Lessons learned from a current research projekt.
Agenda 14.15 Welcome, Prof. Walter Kriha 14.20 "Rendering pipelines in games: How to render many lights", M.Sc. Clemens Kern 15.25 "Mein Weg in die Gamesbranche", Simon Häntsch, Iron Beard Games, Stuttgart 16.30 "Environmental Storytelling - warum Welten für sich selbst sprechen sollten", Alina Dreesmann, Leveldesigner, DECK13 Interactive GmbH 17.05 "How 'the serious' can enrich your game experience", Maximilian Krauss, HdM Stuttgart 18.15 Wrap Up