Winfried Tilanus

The Dutch government wanted an obligatory standard for chat interoperability in healthcare. I chaired the standardisation workgroup drafting that standard and have learned an awful lot about interoperable chats and about the pitfalls of mixing up policy making and standardisation.

Now the European Commission wants an obligatory standard for chat interoperability, this time because of the ‘Digital Service Act’. Lets have a look what to expect when writing that standard!

Sending a text message back and forth is pretty easy to standardise, but there is much more to chat, like avatars, sending pictures, stickers and emoji, message acknowledgment, ‘is typing’ messages, file transfer, end to end encryption and so on. Also some more interesting questions like: should it only be interoperable between some big organisations? Should only the s2s data streams be interoperable or also the c2s traffic? Lots of choices to make, I will draft an agenda for it!

In 2016 a group of innovators from healthcare, mental healthcare, social work and design teamed up to create a roadmap to a future-proof (health)care system. An important part of this healthcare system is an open source ecosystem of digital health applications that can cooperate in an integrated way. Right from the start, privacy has been an important part of the project: agency is at the core of the innovation project and agency is among the central values within privacy. So one of the central questions of the project was: “How to translate the principle of agency into design choices for data privacy within an ecosystem of digital health applications.” We will tell how this question was answered by looking back at the process and at the choices made about the user interaction and technology.

During this project we were confronted with three separate perspectives on privacy: a theoretical perspective that is generally focused on the philosophical meaning of privacy, secondly, a technological perspective driven by the suppliers of digital products and lastly a user interaction perspective, driven by the end user’s experience of privacy. The conflicting perspectives were holding back the progress of the project. Therefore we had to find a way to mediate between these separate perspectives. An important part of this mediation process was finding common values and translating these to overarching principles that are comprehensible to the different perspectives and stakeholders. Next these newfound principles were validated with end-users, representing the interaction perspective. For this purpose we used gamification and mock-ups to make the more abstract principles tangible and testable. Finally the general principles were translated to clear design guidelines for the technological perspective. This presentation will show how we combined a theoretical view on privacy with the users perspective and how we translated these into guidelines for user interaction and into a technical architecture. And you will leave with some practical tips when conducting comparable projects!

At the ‘SamenBeter’ project we firmly believe a good product is a product that improves how people work. So we start with designing the change we want before we even start thinking about a product. How that looks in practice? Come and see, but be prepared for a fast ride!

Is it possible to design a radical change in the healthcare system? Why is the first product we build for that an authorization standard? Why are we talking about the ‘personality of a system’? How come the people designing it ended up in community centres, playing a game about privacy with the visitors? What is that ‘developer journey’ we are talking about? why are we making such a big fuss about a license nobody seems to read?

The ‘SamenBeter’ project has a moderate goal: to change healthcare, all of it. And because we are fuelled with design thinking, we are making deliberate design choices about everything. About what we want to change in healthcare, about the process of getting there, about the role of technology, about the values the technology should adhere, about the way we should develop the technology, about the way the technology will be adapted and about how the community should be developed.

In this talk I will showcase the SamenBeter project as example of how design is about much more then user interfaces. It is about designing processes, user interactions and designing the adaptation of the product itself. And last but not least: why did we take the effort to design everything and not just a product? Yes, it is too much to fit in one talk, so fasten your seatbelts!

The eXtensibility of XMPP makes it extremely powerful. But it is easy to get lost in the supermarket of extensions. In this talk I will guide you though the extensions: how to read the labels? How to cook some common recipes? I will also show some exotic but nice ingredients. And last but not least: we will be having some protocol-fun!

The eXtensible Messaging and Presence Protocol, XMPP, has extensibility at its core. It is because of the extensibility that there is a vivid XMPP ecosystem: it is easy to adapt XMPP to new developments and to new use cases. The XMPP Standards Foundation maintains a list of extensions to XMPP. In this talk I will dive into this list of extensions: what kind of extensions are there? What statuses can an extension have? What extensions to use in some common use cases? And I will touch some exotic extensions for use cases you may never have thought about. Oh, and what is the story about these ‘humorous’ extensions, can a protocol be humorous?

End-to-end encryption is often regarded as the holy grail of security. But when you start implementing it soon becomes a security hell. Does it really protect against the threats it should protect against? And watch out for the pitfalls when implementing it: almost everybody fails there!

Lets start with the conclusion of this talk: after twenty years of designing and analyzing high security instant messaging systems, I came to the conclusion that end-to-end encryption (e2ee) in instant messaging is snake-oil. It creates a false sense of security.

First of all the threat model underneath e2ee has fundamental flaws, it doesn’t deliver protection against the threats commonly named to justify it. And if that isn’t enough, there a lot of issues that make a proper implementation very hard to get right. To name a few: key verification, one-to-many messages, store and forward and archiving.

But lets not end this talk all in black. Though we aren’t there yet, there are some developments that may solve these issues. I will name those too.

The stability of a webchat is dependent on numerous factors, ranging from quality of code and browser compatibility, to the stability of the infrastructure and the way it handles network instabilities. To make a sensible comparison between webchats or to measure changes in stability with a new version of a webchat, there needs to be some kind of standardized testing. In this talk I will show how I have set up an automated testing environment that automatically simulates numerous potential problems, including network instability.

Using a real world example, I will discuss in this talk: -Potential sources of instability in webchats -Selecting what tests are relevant -Setting up automated testing of webchats -Testing the behaviour of the webchat on unstable networks -Results and lessons learned

The code used for the testing is available on GitHub: [https://github.com/winfried/WTF] (Webchat Testing Framework)

A guide to getting started with Jabber/XMPP technologies in Python.

With XMPP you can build a webchat in a breeze, so nothing can go wrong, right?

The HelpIM chat software is about 10 years old now. We have rewritten it three times and with each rewrite we managed to make some major screw-ups. Recurring issues are: "how to reliably deliver the chat over the web", "how to route the messages within the server" and "how to authenticate over both HTTP and XMPP". With this talk I will save you from making the same screw-ups as we did.