Secure Messaging for Everyone with Wire

Alan, where did the idea for Wire come from?

Wire, as you know, we’re a secure messaging tool for everyone, and the idea for Wire came five years ago when us founders of Wire met together with Janus Friis, co-founder of Skype. We had an idea there to build a new Skype, and we were thinking like “Okay, if you are building Skype ten years after, how would that Skype look like?” There we identified three gaps. One was related to privacy, one was related to user experience, and the third one was related to security of all of the existing messaging solutions. As you can guess, all four of us founders were related to Skype one way or another.

[04:39] That’s interesting. I mean, obviously we’re conducting this call via Skype, and I think in my history of podcasting I could probably say there’s only maybe a dozen - if that; if that, and I’ve done probably five or six hundred shows across my podcast career, where they’ve done via Skype, and it’s interesting to kind of talk to somebody that’s played such a critical role in Skype for one, but then also this desire five years ago to wanna do something better. What’s wrong with Skype? Not so much Skype as a product, but what’s wrong with maybe the type of platform, the type of thing it is, the thing it’s trying to do to make Wire be something that needs to exist.

Actually, besides this privacy part, since Skype is a part of a bigger corporation - their business model may be different than what is our business model… Another part that I personally didn’t like was that Skype, which from the very early days had impressive end-to-end encryption done in a peer-to-peer way, as it changed over the years, that encryption has been removed from it. So this is basically the main complaint on Skype. Other than that, it’s fair to say that Skype is still an amazing tool that does its job very well.

Another possibly big disadvantage is the fact that Skype has quite a bit of a baggage being present on the market and being one of the leaders on the market for now nearly 15 years. So a number of things that are holding them back relate to some backwards compatibility etc. So we were lucky there that we could start from scratch, identify those gaps and go for it.

You mentioned that one of your previous companies - and for the listeners, this isn’t Alan’s first rodeo, this is maybe your third or fourth technology business; you had many successes in the industry… Camino Networks (I believe it was called) was bought by Skype I think back when Skype was part of eBay. When you go back and start thinking about it, Skype has a long-storied history as a software product and team, and like you said, it has a larger corporation it’s a part of now; it’s had different phases in its life… What was Camino Networks and why was it bought by Skype? Tell us that story a little bit.

You’re definitely prepared quite well for this podcast, since Camino was sold to Skype roughly ten years ago, and Camino was developing speech coding and sound processing technology that was tailored for voice-over-IP networks, so that it could sustain lossy networks and jittery networks.

[08:11] This was a piece of technology that Skype was missing, because Skype was licensing that software from another company that was called Global IP Solutions, which ended up afterwards acquired by Google. Global IP Solutions is a company where I was one of the first engineers and started working with Skype basically in 2003. I used to joke that I know Skype when it was still called Skyper.

I never knew it was called that.

It’s interesting to look at the history of Camino Networks, then acquired by Skype, then Skype acquired by – there was like several different chains in there for it to ultimately be now owned by Microsoft… And whenever you have an idea, a business, an idea, a technology goes through so many hands; the mission, to some degree, must get lost, or its original mission or its original intent somehow gets disambiguated. Somehow it’s blurry, it’s not clear to maybe the current status, and maybe that’s why Wire has end-to-end encryption.

Maybe help me and the listeners understand - when you’re talking (as we are now) via Skype, what’s happening? Are we at risk of our conversation being overheard by someone else? Is that what’s happening? You said the encryption has gone away over the years… What exactly is happening with communication on something like Skype?

Risk of a conversation being overheard is realistically small, unless you are someone of a particular interest or of a particular high net value. That information could be sold to someone. However, there is also more aspects to it, such as metadata related to this call. So it is something that is of concern to businesses if for instance – let’s say a small pizza shop… If it is using a tool like Skype or WhatsApp and if their customers are contacting them via that tool, all of that metadata related to who was contacting them, when they were contacting them etc. is at the disposal of those large corporations such as Microsoft, WhatsApp, Google etc, and that information then can be sold directly to their competitors.

Let’s say there comes a new pizza shop that is in that area, and they can have easy access to all of the customers, offer them a little bit better value proposition or a little bit cheaper price than what the original one is offering, and overtake their customers. And they can do it in a perfectly legitimate way, because this is something that the terms and conditions when you are using those tools is specified that nothing prevents those big corporations from taking it.

[11:55] In a similar way for people that are using it just from a pure consumer side. It can be used for a profiling on our side, and you’ve seen also the cases where people are getting suggestions to be connected to other people that they shouldn’t be connected, and it can also create a number of scenarios that are quite awkward and are also potentially dangerous.

For maybe some of the listeners too that are even like “Why are you guys talking about Skype so much? I don’t even use Skype anymore. I’m not a podcaster, I don’t have that many conversations…” Jerod, what’s your opinion? Do you think there’s a lot of people unlike us – like, we record this show and our shows across Skype… Is there a massive user count for Skype? Are we boring people with the conversation around Skype, you think?

I think there’s a massive user count for Skype because of what Alan said, which is how long it’s been around…

Right, the 15(ish) years.

One of the reasons why we use Skype for podcasting is because of the call quality relative to others, and it has a lot of technology in there around making sure that network glitches don’t cause as many problems as they do; there still are issues. But the other thing is most people have a Skype account; that doesn’t mean they’re using Skype, but it’s just been around. It’s like the AOL Messenger, most people have an AIM account somewhere…

Okay…

So that is a barrier that we usually do not have. Sometimes we do. Alan had to install Skype and probably had to dig up his old username in order to make this call with us. So there is a network effect there, but it’s not like the cool kid on the block; people aren’t excited about Skype or using it because they want to, it’s just because that’s what’s always been there and it’s been good, and there hasn’t been much innovation and competition in that marketplace until recently, and there’s a lot now.

Gosh, I was looking at your website there, Alan, and you guys have a nice matrix, kind of a feature matrix with other offerings; there’s Skype for business, Microsoft Teams, Slack, WhatsApp, there’s Facebook Messenger, there’s Telegram, there’s Signal… There’s a lot of people who are trying to make waves in the chat and voice and video space. The reasons why we invited you on the show, one of the major things is that Wire is completely open source… So we’re not talking with Facebook Messenger today because they’re not open source, and we think open source is cool, especially when it comes to privacy. In these times of encryption, we think open source is important. So why are you guys open source? Tell us about the decision to do that.

The main reason why we went open source is when you have a piece of a software, especially one which is a communication tool, and security with privacy is in its core, I see there of utmost importance to be fully transparent about what you’re doing with your software. This is something that we owe to our users and we owe to our customers.

I usually say to all of my colleagues, friends that are not much in the security area, when they are buying security-related products, whenever they hear that something is military-grade encryption or military-grade security, and if it is not an open source, stay away from it.

[15:59] This is something that I think is also gonna become a norm for most solutions that are gonna be coming out on the market. When looking at things from a company’s perspective, what is really cool is once we open sourced, we started getting calls from a number of largest world corporations, from the automotive industry, some of them in the banking sector, some of them in pharma, which hadn’t contacted us before we were open source. So it was a big proof that being transparent is already paying off quite nicely, and it’s gonna be paying off even more in the times to come. So this is the reasoning when looking from a company’s perspective.

When looking from an individual’s perspective, it is also something that pretty much all of our team members see as employment benefit, and they love that they are working with the open source they love, that they can show to their friends and family what they are working with. They are very proud of it, and also personally for me this is a big thing, because I’ve been involved in open source now basically for 21 years, starting with Slackware back in ’96, then through iLBC Codec, and a number of other initiatives.

It also helped us a lot to recruit some of the top talent which told us that for them this was a decision-making point, that we were open source compared to some other options that they had in front of them.

Well, to a certain degree, Alan, you’re preaching to the choir, because we see the value in doing it, we think it’s overwhelming to keep it closed source, but was there internally - you’re CEO and co-founder; as you mentioned, you have some other founders and some other people who are in leadership at Wire, maybe you even have a board of directors, I’m not sure how the company is all laid out… But did you have to pitch this? Was there an advocacy internally? Was there a debate whether or not to do it, or was it a no-brainer for everybody involved?

Excellent question. Of course, you are on to something, since also among our investors there wasn’t unanimous decision and sympathy towards open source. There were also some concerns from one part of them that haven’t been working with open source before, and there was also a bit of skepticism how the market is gonna respond to it, but they were still very supportive, and after really good argumentation was presented for open source, we all decided together to go for it, and ever since they were extremely pleased with the results of going open source, and I’m also glad that we expanded a network among investors that are now strong supporters for open source.

It’s interesting in hindsight to look at the way that open source has been a benefit, and this may not be something that seems very clear to everybody listening or to those who are newer to the idea of open sourcing everything (so to speak) is that you’ve been able to attract and acquire customers, or at least entertain the idea of them using Wire, that wasn’t prior to open source; you’ve been able to attract talent, and now it seems you’ve certainly won over the co-founders and investors in Wire to say “Open source is the way.”

[20:09] That’s a hard thing for some people to really get, and I think even for us, Jerod. Our CMS is open source, and when we were first thinking about building that technology… A thing I think we often hear is “That’s awesome that you did that, but you’ve given away your everything, essentially”, and I don’t see it as that. I see it as like Alan is saying here - there’s full transparency, we have nothing to hide, and all it does is get us all the benefits. Alan, is that how you see open source? You said before in the pre-call how big you are on open source; is that a part of the reason why you’re so big on open source?

Absolutely. At my previous job I was fortunate enough that I could a codec that is called iLBC from a business idea around it to make it also first as a part of a freeware, open source it… Thanks to that experience, we’ve seen how it helped to enable something what was massive afterwards. If you look a little bit back, some 15-20 years ago you needed to spend quite a bit of money to license speech coding technology that was working reasonably well on internet. Companies like Skype, they didn’t have at that time the possibility to use some of those codecs that were free or that were licensed then from Global IP Solutions [unintelligible 00:21:57.07] that was not prohibiting them to grow from the start, I don’t think we would have had today free calls practically everywhere - on mobile phones, on desktop, video calls etc. This helped in a great manner quite a bit of innovation that was happening afterwards in the field of internet communications, messaging space, voice-over-IP etc.

In the same way I see things happening in security and also open sourcing some of the critical components there, inspiring a number of other developers out there, inspiring also a number of other companies to create good solutions, secure solutions, and ultimately then at some point in time hopefully gaining the same adoption rate as we gained on the speech coding side with WebRTC being open sourced from Google at some point in time. And as you may know, most of the code that was open sourced at the very beginning for WebRTC was again Global IP Solutions code that Google acquired.

I’m glad you said that, because I wanted to make sure that we, if not gone deep here, because maybe now is not the right time, but mentioned that iLBC is Internet Low Bitrate Codec, which ultimate became WebRTC. It was initially released - this is all based on Wikipedia, so this is free information; we’ll link it in the show notes - in 2004, written in C, and used a 3-Clause BSD license… But is now owned by Google and was ultimately turned into WebRTC.

[24:01] So all this work that you’re saying that helped you have faith and believe in open source was this initial codec, which became WebRTC. For those listening, that’s a massive amount of history and a huge lesson for Alan to learn around this thing. That’s just so crazy to hear that backstory… And today we have WebRTC; it’s just amazing how that thing there for you is what gives you faith and started your faith in open source, and what has ultimately helped you build Wire.

Absolutely. That’s been an incredible journey, and I’m really proud that iLBC became a seed for what afterwards turned into something really spectactular, used by billions of people. Also, at the time, back in 2001 when I was taking iLBC to ITF to standardize it, people thought that I’m crazy, that ITF would never take it, but I was fortunate as well to have some of the visionaries there at ITF that accepted it. Then after that we took codec to another standardization community [unintelligible 00:25:22.18] It got also accepted there, and it wouldn’t be accepted there if it wasn’t free and if it wasn’t open source.

From that point onwards, it set the standards for any kind of speech coding technology and video coding technology that wanted a high adoption rate.

That’s amazing.

For the sake of conversation, let me play the bear for a minute with you, Alan, because as you said, internally it was not unanimous, so no doubt you had interesting conversations with your colleagues and leadership at Wire around this. One of the major points brought up by people who were skeptical of open sourcing - I think it’s a legitimate skepticism with regard to rip-offs. Rip-offs happen, and the more successful you are, the more they can happen.

In fact, just recently I was reading about a cryptocoin wallet called Coinomi, which I think is an Android-only thing now, and I was just reading about their history a little bit (these things interest me) and they were open source, I think it was GPL-ed even, and their Android application was all open source, on GitHub, and they were doing it all in the open… Which makes a lot of sense for a crypto wallet as well, because talk about you wanted to know what the coin is doing… Similar to an encryption type of a secure chat, you wanna know what’s going on under the hood, so it made sense for them to be open source. Well, what happened was other people who were being very capitalistic, decided they were going to just take that code, rename it, rebrand it, and put it on the Android Store.

This is not an isolated incident, we see this happening over and over. The Coinomi folks stopped open sourcing, they decided it wasn’t worth it for them anymore; I believe that repo is still on GitHub, but it hasn’t been updated in a few years, and they’ve marked it as inactive, so they’ve continued to develop the codebase closed, because they had these problems.

Was this a potential reason not to open source discussed at Wire? Because surely, if everything you do is in the open, somebody could just take all of your code and all that you’re doing and rebrand it and compete with you.

[27:49] Definitely something that has been brought up by our investors as a concern and definitely a valid concern, and as you’ve seen the case that you described - we have also a couple more unfortunate cases like that; really awful stuff has happened with the open source, and I’m glad that those are only exceptions, and I hope as well that there are good, legal ways - and I know that there are - how to protect those companies that have been ripped off in this way. The legal system should protect them, and I’m pretty sure that the community and opinion-makers are not gonna be positive about those solutions that completely ripped it off. So it’s also important that the opinion-makers and the ones that are strong influencers towards the customers of such solutions, that they make sure that people stay away from solutions that are basically classic rip-offs.

It is a hard way, and we know that there are gonna be the cases when such things are gonna be happening, but on every negative case, I trust we have another ten positive cases. We need to continue pushing in the same direction and we need also to help those ones that got hurt during this effort.

Alan, Wire has a lot of competition, which is great - there’s lots of companies and individuals trying to provide solutions in the chat and video and voice space, and we need that. There are many alternatives - there’s even many open source alternatives. In fact, Telegram and Signal are both open source, somewhat interestingly… Or at least it’s interesting to me.

Adam actually found Signal, and said “Hey, we should do a show on Signal”, and I had already invited you on, and I said “Well, we’re doing a show on Wire”, and it was just kind of like almost simultaneous discovery; I only beat him by maybe a day. So we thought about having the Signal team on, because they’re doing a very similar thing.

I’m curious what sets Wire apart from the competition, even amongst those who are security-focused and open source as well. What’s the Wire secret sauce?

When you look at the current landscape, on one side you have applications that are secure, using end-to-end encryption, such as Signal or WhatsApp, but Telegram I would also have some reserve, because their default mode is not end-to-end encrypted. According to different sources, most of the conversations on Telegram are not really end-to-end encrypted.

But nevertheless, when we look at the applications such as Signal, WhatsApp, they are general-purpose applications that are easy to use and that are secure. They are not applications that are meant to be used for businesses. You don’t have their possibility to add someone to the group or take someone out of the group, administrate that, you don’t have the group calls and the number of screen sharing and the number of other functions that you would expect in a business environment. So this is one side of the landscape.

Then you have the other side of the landscape with business tools such as Slack, Microsoft Teams or Facebook Workplace, which are tools that are not really secure, that are not really using end-to-end encryption, and also in addition, those are tools that are not easy to be used by people that are not in the IT world and that are not tech-savvy. Wire is really there addressing this sweet spot so that it can be used by consumers. So with Wire, you can have a consumer profile and then you can have your business profile, in the same way that for instance you would do it with your email client. Whether it’s Apple Mail or Outlook, you can have one account there, which is your private account, and then you have the other account, which is your business account, and you can nicely keep those apart if you want.

This is basically unique with Wire, that you can use it both for business and for your private use, and that is super secure, and it is super simple to be used. It is, as we say, like a general purpose application, and as you know, in the past there have been a number of really super secure tools like PGP Email, but they were really cumbersome to be used, and companies and people that really needed to use it or that depended on it, they were usually falling back to solutions that were easier to use but were not necessarily secure.

[36:23] One point that you emphasize on the website which maybe I need more explanation because I’m not very familiar with - and perhaps other people as well - is that you’re Europe-based, and so there’s European privacy laws in place. Can you explain why that’s relevant and important when you’re picking a tool like this?

European laws from a privacy point of view are more protective of the consumers and more protective for businesses. There is a really high threshold that needs to be passed in order to get any kind of very confidential information, especially when compared to U.S. or some other jurisdictions.

And also, I guess part of that too is being Switzerland-based. Why is it specific to mention Switzerland? I know that it’s pretty well-known for like having a Swiss bank; you hear that in the movies, and it’s this thing like “Oh, you can’t get in here”, it’s this neutrality kind of thing. Is that part of the tail end to Jerod’s question to you?

Up to a certain extent, but really what it is there why we’ve chosen Switzerland for our jurisdiction was that at that time privacy laws were even more favorable that European Union laws, and now Swiss and EU privacy laws are on pair. Over time, European laws as well emerged further and are protecting consumers and businesses in the same way as Swiss ones do.

Another reason why we went for Switzerland was that there is a favorable regime with respect to keeping your intellectual property.

I guess one thing we can probably dive into a little bit further is what you really mean by “secure”, and mainly for breaking it down for everyone to really understand that… Because on your matrix that we mentioned in the previous section it says “Secure = Everything’s secured with end-to-end encryption.” People may say that quite a bit; maybe it means one thing for someone else but it means another thing for you, but you’ve got an entire page dedicated to describing what you mean by “secured with end-to-end encryption and protected by European privacy laws”, which you’ve described as more robust and more comprehensive.

Can we kind of walk through some of the information shared at Wire.com/security. You’ve got “End-to-end encrypted”, “Independently audited”, “Multi-device messaging.” These are pretty interesting things I think that people don’t really break down unless they have to break them down. So to say that new encryption keys are used for each message, so if one is compromised, a key has minimal impact; or how you can use several devices… Can you start breaking down some of the end-to-end encryption details that you all employ?

[39:54] So basically you already hit all the most important aspects of this being really secure. With the end-to-end encryption you are rising a threshold for those that want to exploit your platform extremely high. For instance, if three of us have multiple chats and also some group chats in various combinations, in order for someone to know everything that we are talking, they would need to break into all of our devices; exploiting the Wire network would not give them anything, because the Wire network keeps all of this information encrypted, and not only that if someone would like to exploit this data from the outside, but also if we have someone inside Wire that would like to take advantage of their position being an employee at Wire, they cannot take that advantage, because all of the data that we have is pretty much useless.

What is really important here is that you are putting this barrier for exploit very high. Imagine if you are a bank with millions of customers, or if you are a legal office also with thousands of customers, in order to get data that currently being obtained with exploits that are happening, that you’ve seen recently with Deloitte or KPMG, or even Slack some time ago, you have all of those users’ information at your hand once you get into their cloud. So of course, when someone from the outside wants to take advantage of a specific platform, they’re likely to go for that one where it’s way easier to get into it.

Using an equivalent, like if your home is protected with a video surveillance, it has doors that are the most sophisticated ones, using all of those anti-burglar features, if your home is also being surveilled by security, and then there is someone else’s home that is not being surveilled by security and doesn’t have video camera surveillance, it has just simple doors that are easy to break in. If the value of stuff that would be found in two of those homes is similar, of course burglars are gonna go where it’s way easier and there is way less risk to get it.

Similarly, if you have customers that have very sensitive data, that their businesses depend on, or that even their lives may depend on, they are not left at the mercy of our employees in our company, because even if they were the ones with bad intentions, they wouldn’t be able to extract much from the data that we hold there. So this is also the difference in our approach towards the data of our customers. For instance, some of the companies take it and they say data is the new oil; for us, the data that our customers have could be seen more as nuclear waste.

[44:15] That’s an interesting perspective.

Exactly, and we know that we need to handle it with care and we handle it the care that our architecture and everything is addressing it.

So data as oil with regards to - let’s just take customer chats, chat messages text… It’s bad for me as a customer if you’re using that oil to power revenue through some other mechanism, but it’s powerful for me if you’re feeding back into my user experience, if you’re improving the product with my data which I’ve put into the system. One of your rivals, a centralized business rival is Slack, which is dominating the small business and startup and really the developers sphere with regards to just usage. The joke now is you have too many Slacks; everybody invites you into their Slack, and you don’t wanna join another Slack because you already have 18 Slacks. By the way, Changelog Slack, check us out… Changelog.com/community. So we have one. And ease of use, and some of the features provided by centralization are really nice.

So we have this age-old compromise between security and ease of use, or security and rich feature set. With Wire you say it’s easy to use, it has a rich feature set, and it has security; there’s no compromises - I’m taking that right off your Features page, it says “No compromises.” Surely, there’s some compromises. There has to be – you’re giving up something, right? Are there things that Slack can do that you just can’t do with Wire, because of the architecture of the centralized data stores?

Some of the features which Slack is developing are easier developed if you don’t need to think about end-to-end encryption, but I’m pretty much sure that they are quite aware of all of the potential hazards that hacking into Slack would cause to their users, and I’m also pretty sure that they are working on end-to-end encryption in the same way as, for instance, big food and grocery supermarkets like Safeway in the U.S. - they have a normal food section and then they have a healthy food section. And as awareness about hazards of security exploits is rising, everyone is gonna have their own “healthy food section”, whether it’s Microsoft or Slack or anyone else. So this is one of my predictions for the next couple of years for the market of business communications. Their first goal is to move business users away from email, because also email is the weakest link in the chain. For sensitive corporate information, people should never use email.

When compared further with Slack, I seriously doubt that it can improve quite much user experience data that you get by digging any company’s chats and information which is a chat. I would be very keen on seeing really some of those use cases and see how it is really improving productivity or user experience.

[48:02] The interesting thing here is that we have seen in Twitter and Facebook, we’ve seen some rogue employees do some things that has been detrimental to their brand, to some degree - and large degrees. Doing things on their way out, their last day of work… So in your case with Wire, the fact that the encryption is happening elsewhere, not so much that if you take over Wire’s network that you don’t have access to all the keys in the kingdom. You have maybe a limited access, or something where you can’t really go into the individualized clients and things like that. So you’re in a position where that seems to be a foundational DNA of how you move forward with developing product. Can you describe – I think you touched a little bit on it where you said Slack could do something, but then you could also do it as well, if you thought about it from a certain perspective. Can you kind of walk us through what that looks like, to have that as a foundational DNA of new feature development, to operate in a way that remains with the integrity of keeping things secure?

Yeah, excellent question and also a very difficult question, so I hope I’ll be able to explain it in simple words. Basically, what is happening with the end-to-end encryption, we have a cloud communication model fundamentally changing. So for instance, some of the core functionality that relies on a cloud, let’s say like a search in a Slack - search is happening in the cloud. For us, search cannot happen in the cloud on the content of the conversations simply because everything is encrypted and we have no clue if a certain message that passed through our cloud is, for instance, a call that I’m making to you, if it is a text message, if it is just acknowledgement of the message that you sent to me and you’re getting back delivery receipt, or if it is a file that was sent, or a screen that is being shared… For all those messages you have no clue really what is happening there. So search cannot be done in the core.

Also, a number of other functions, such as a sync across different devices depend heavily on endpoints. So you have a hybrid logic there. Most of the intelligence is moved towards the endpoints, but there is still some intelligence that is in the cloud. We’ve seen this in the past in communication networks - for instance, you had intelligent network in telecoms where all of the intelligence was in the cloud. Then with the rise of Skype we had the peer-to-peer fully distributed model where all of the intelligence moved back to the endpoints or to the peer of the network. No pendulum is again swinging to a cloud; everything was moved to the cloud, all the intelligence is in the cloud, and now pendulum is swinging again and going more towards the endpoints, and we have this hybrid model. With this in mind, as I mentioned, any feature that you are developing, it needs to be developed in a quite different way than if you do not encrypt the data. So it has some overhead, it has tougher test automation etc, but we are committed to it and we know that this is the right way forward.

[52:14] Do you believe that the consumers will come with you on the way forward? Because a disturbing trend that I see - and heck, I even see it in myself sometimes - even knowing all the implications and the problems with privacy is we all want it until it’s inconvenient, and even the smallest inconvenience, we just throw it out the window. Not even inconvenient – or we have a shiny feature that is dangled in front of us, and we say “Oh, that’s really cool!”, especially now, applying a lot of the machine learning to our historical data, and the neat things that you can do with that, positioning yourself very much as the secure way to message… As you said, the pendulum has swung back and forth, but won’t you see it potentially swinging away from you as consumers continue to sometimes frustratingly choose convenience/features over privacy?

You have a fantastic point there, and we are quite much aware of it. I also like to see it from a couple of perspectives. One is related to awareness, and this sociological or anthropological view on it is quite important. There needs to be more awareness of all of the issues that are happening with abuse of our privacy.

I also like to compare awareness and the knowledge of a hazard to the passive smoking some 20-30 years ago when I was a kid, to all of the hazards of exploits of our privacy today. In the times to come we’ll see, I’m pretty sure, also some of the massive lawsuits over this happening if this doesn’t start changing…

The basic problem there is who is watching the watchmen? We know that companies like Facebook and Google heavily depend on products that are free to consumers, and we know that it is not free, because the consumer is the product…. And how can they increase their valuation, because all of them are publicly traded companies? They are already serving one billion of people that have 98% of the wealth, so the only way to heavily increase their profitability is by exploiting our privacy further.

Also, with these profiles that are made of us based on our usage of their services - what those profiles are gonna be used for, and then also there is definitely a room with other serial models to influence other people’s profiles, because you know, my profile is also created by a pattern of usage with my other friends, co-workers etc. Other sites also can play with my profile easily and mess it up heavily. So those are the things that we’ll be seeing in the future that can impact our life in a great manner, and unfortunately there is no good way to make sure that those massive abuses do not happen.

Alan, we can’t help but notice… We’re looking at your design and we’re looking at the way that you present business, which is quite impressive. One thing that I’m impressed by is the domain. You’re talking to a developer audience; we nerd out about the littlest things, and domains and domain hacks – you’ve got wire.com. Four letters, easy to spell, the exact name of your business… How did you go about getting that? It had to be expensive?

It is expensive, though five years ago when we acquired it, it was visibly less expensive than what it is today. As you can imagine, at that time we had in the same way as we have now, big plans, a big idea, a big mission, and we needed also a big name, so from the very beginning we’ve been very careful about brand-building, about the architecture of the system that we have built, choices that we took there… The back-end, for instance, is completely written in Haskell, able to scale in the hundreds of millions of users, and a number of things that were done from the very beginning were done in a very solid way.

[01:00:24.10] Yeah, that leads into what we wanted to talk to you about a little bit with the technology choices around the different things. When we say that Wire is open source - a lot of times businesses will just open source their clients or their client libraries, but there’s tons of open source stuff, so check that out in the show notes. They have the server, they have components, they have all the different individual clients, and just looking at it a little bit… Like you said, the server side is written in Haskell, there’s protocol libraries that are written in Rust, you have C libraries, the iOS app is Objective-C and Swift, the Android app is Java, so you’re using native languages for their platforms. There’s a desktop app which is an Electron thing, which wraps the web app, which is a React thing… So you’re very much picking the technologies that fit into the particular platforms, and not going for a cross-platform solution or even a React native or something like that, and it seems like that plays into your desire for this big play… Like, you took the time, you bought the domain, you spent all that money, you’re designing it for this big idea…

Let’s start off talking about your native iOS and Android apps, and… Are we right when we say that the reason you’re using the native languages is because you care so much about the native experience that you’ll pay the time and the labor to get that done? Who makes those decisions, and are we sensing what we think we are?

Really well spotted from your side… For instance, on the mobile client’s side, with the Android and iOS, we broke their architecture in a two-tier model, where functionality related to UI is written in Java on the Android side and Objective-C on the UI side, and now more and more of the code there done in Swift… While the second part we call Sync Engine, which does pretty much all of the hard lifting work on the client side - all of the communication towards back-end, the parts related to synchronizing state across multiple devices, and also doing the parts related to encryption, parts also related to speech coding, video coding… This Sync Engine layer is written in what we found the best to suit also all this logic and the business logic for a specific platform, so on the Android side we picked Scala, and on the iOS side we picked Swift.

I’m quite proud that we were one of the first applications in the App Store that had been deployed with quite much of a codebase in Swift, and that’s also a lot thanks to one of our team members that used to work with Apple for a number of years. So we’ve been always pushing their boundary and picking up solutions that are giving the best native experience, and you see there with this native experience also comes battery life. On that side it is really important to preserve the battery life as much as possible, and this is also where this native experience is helping us.

[01:04:24.17] However, we are not there fully, as you would say religious, so certain parts we still do cross-platform. As you’ve noticed [unintelligible 01:04:32.19] which is basically dealing with the core encryption stuff - that one is written in Rust, and it nicely runs cross-platform. Or for instance this code that you spotted that is written in C, it is related to audio/video libraries, and that one also is quite nicely optimized and is running across different mobile platforms. So we’ve been there quite pragmatic and we took quite a careful thought about the choices that we were making, and basically all of the choices have been done by my team and me together, and there are always healthy discussions when we have those architecture discussions; they are always fun and they are always more challenging.

This is so polyglot, it makes me curious how you found and hired your team, and how many of them came from your previous companies… Because you hear a lot of times “We’re a Java shop”, “We’re a Ruby shop”, “We do Node”, but Wire has to be in so many different places that you just have all these different technologies which are diverse, and some of them very niche… I mean, Haskell - there aren’t too many people who would kick off a business with a Haskell server. So tell us about your team and where they come from; who are these people?

Those are people that are really also, besides being top-notch coders or technicians, also intrinsically good and fun people to work with. A number of them from our previous startups. That startup that was sold to Skype once, then it became part of Microsoft - it wasn’t anymore fun for those guys to be part of a massive, big corporation, and then while presenting them our mission, a number of them joined from the very early beginning. Also, a number of early Skype employees joined us, and also a number of employees from my previous startup, Telio, which was a voice-over-IP operator in Europe… So with a number of team members I’ve been working or my other colleagues have been working for 5, 10, even 15, and in one case even 20 years.

That was the early team, core team, and then when you have a bunch of clever, talented people that are fun people, then you also attract a number of other great guys. So from the very beginning we needed really a fantastic back-end that scales a lot, and as you know, Skype didn’t have much of a back-end… So since we placed our team in Berlin and since we had a fantastic mission and since we already had a bunch of cool people on board, we managed to get a number of guys that made Soundcloud’s back-end.

[01:08:05.13] A part of that back-end had been written in Haskell, and those are guys that were coding Haskell in their spare time, and while joining Wire, they could do their fun work also during the work hours, so it was very easy to recruit a number of those guys.

Then, as you attract those people, then you attract also a number of other talented engineers that are working around the world with Rust or with Haskell, and Berlin is a really fun place to live in; it is kind of a melting pot, and people are coming from all over the world to live there, and in our team that is in Berlin - around 50 people - we have 25 different nations there, which is just showing you this fortune that we have… Different backgrounds, different cultures - it really creates a fantastic environment to work in.

Speaking of developers, it appears that you’re also reaching out to developers beyond your company borders with an end-to-end integration API. Can you tell us what this is about and how you hope developers will use it?

Thank you very much for bringing that one up. This is something where we’ll be focusing quite a lot from the beginning of next year. The current API that we have together with the documentation which we have is still in its early stage, so there I beg for a bit of patience and forgiveness from the developers that jump on it right away. I hope as well they’re gonna be rewarded heavily for that one, being among the early ones.

What is quite unique about this API is that it’s basically an extending end-to-end encryption platform, and this is the first one that we know of doing all of the integrations in the highest possible secure way.

So that’s currently in beta; there’s code examples, but you’re saying this is kind of in rapid changing phase, or active development.

Exactly. There please stay tuned. During the first quarter of the year we’ll make it also available - the API in a number of more programming languages, as well as documentation, which is pretty scarce… But it will be at the level where it should be.

One thing that I’m struck by - we mentioned it with the domain, and the design, and the emphasis on the native clients… Everything that you’re doing seems very intentional, so one question we often ask guests on this show is what kind of open source project are they? Because open source is not one-size-fits-all, and especially with businesses with open source products, often they’re different in their DNA, even though the code is all viewable and the license may be very favorable and all that… But is Wire open source like “You can view our source and you can clone our source”, or is it open source like “We want everybody to be working on this together as a community?” How does it look from the outside? What do you expect?

[01:11:50.03] So in the first phase it was more about being transparent, because in order to attract a number of users to develop on top of your code and around your code, you need to provide them necessary attention, and also the attention which they deserve in order to create great value for you, and also in the same way to create it for them. And as we are moving further, this is where our focus is going to be. Also, a bit of exclusive information is that for some parts of the code we are likely to go with a less restrictive license than GPL v3, but I’ll be really glad to talk about it more hopefully in the next year, when we talk again.

I’m kind of curious too, to Jerod’s point - when you’re open source, it’s not one-size-fits-all, and in a lot of cases you’ve kind of come up in a different scenario where you have deep roots in what we talked about earlier, which was the internet protocol, the Internet Low Bitrate Codec (iLBC), kind of getting your grassroots into open source there, kind of seeing a big win, garnering a community, ultimately turning into WebRTC… And in this case it’s slightly different, because it seems like it’s – sometimes you describe it as open core or open source and you build a business around the open source you develop… Is your hope maybe from coming on a show like this where you speak to a pretty diverse audience of developers, and highly likely that they really care about open source, because they’re listening to The Changelog - is your hope that 1) you’ll get a lot of new users, a lot of new eyeballs on what you’re working on, but also potentially developing a community around it? Because that’s the one piece I see missing, and as Jerod said, you’re very intentional and very clear with your speech and with who you are; the community aspect is the one that seems to be missing.

Excellent point. This is the part that I’m personally quite excited about, and also where a number of our investors are excited about, and also my colleagues. Compared to some of the other secure solutions providers, at Wire we also believe in a federated approach. What you see in vicinity is that some more verticals that are emerging need also to deploy end-to-end encryption, such as automotive, especially with the driverless cars, connected home, digital health etc.

Our vision there is that the messaging platform will be interoperating with all those, and there in a similar way as we had previously at WebRTC, we see that there is gonna be a big need for a secure protocol solution that will be connecting those different islands, and further fostering innovation as we are gonna be crossing those different verticals. As you’ve noticed and as you’ve seen, we always love to think big and to think some years ahead of us, and this is something where we are quite committed and excited about this federated approach, again, also taking parts of our intellectual property to standardization, and then by enabling the whole world around us, create also more business for us and also bring more value to our shareholders.

[01:16:23.28] There nothing happens without good community support, and we’ll make sure that we address community around us in a right way, and also to attract a wide community and give them a really exciting platform to work on.

You might get a chance to do that in a deeper scale. I’m reading further into Wire.com/security, which we referenced a couple of times earlier in the show, which we also will link up in the show notes… But down in your Transparency area you mention that you’re open source, that you’re GPL version 3 licensed, but then you also mention in that same sentence or in that same paragraph a self-hosted server option, which I imagine is intended for someone to install themselves onto their cloud, as they see fit. This is coming in 2018… Can you kind of maybe tee up this horizon, this future that you’re building towards?

Yes, also an excellent point, and a point that I’m quite excited to talk about. This federated approach is something where we see massive value and where we see big opportunity, not only for Wire but also for a number of other companies. We really don’t believe in one ring to rule them all, and we do not think that people are gonna be using one solution, whether it is from Facebook, or Google, or Microsoft or Apple for all those verticals - for consumer messaging, for business messaging, for large enterprise messaging, for messaging towards the automotive, with a connected home etc.

As you’ve seen with our back-end, it is quite nicely written code; it’s roughly like 30,000 lines of Haskell code, and it should be possible to port it also on lower footprint devices, or servers. So there I’m really excited about the potential that this is bringing into the future and about all of the innovation that can happen around it.

Very good. Any closing thoughts for those listening? Any ways to get involved, any inroads? Obviously, you’ve got a Medium blog people could be reading, you’ve got a couple different things people can go check out in terms of your codebase; that is at github.com/WireApp. We’ll link that up in the show notes, of course. Any other places where we can send people to to kind of catch up further on what you’re up to?

Our Twitter account is definitely one of the places where you can stay up to date with all of the news that are happening around Wire, and the other ones that you mentioned are the ones that are really good for a starting point, and as well please stay tuned related to an API platform that we’ll be deploying in 2018. There especially we value all the feedback related to Wire application privacy policy, terms and conditions, features that are missing, and especially about the things that are not working well and that can be improved. The Twitter there is a perfect channel to pass it back to us.

[01:20:28.14] Excellent. That’s actually a nice Twitter handle, too - twitter.com/wire.

You did it all.

Aside from GitHub - you’ve got WireApp on GitHub, but that’s okay. You can’t have Wire everywhere… Or maybe you can. We’ll see.

We missed it by a little bit on GitHub.

There you go. Alan, thank you so much for sharing your time with us and walking us through some of the history to the earlier protocols, the earlier conversation around Skype - that’s always enlightening to kind of peel back the layers to a tool we’ve used for years, and rely upon… And I have to say, during this conversation, Wire seems pretty awesome and I can’t wait for maybe some features that are focused towards podcasters, that can make our jobs a little easier and secure.

Alan, thank you so much for your time, I appreciate it.

Thank you very much for having me on your podcast, and I would be delighted to hear a bit more on the requirements also to make Wire your tool of choice for a podcast.

Will do, for sure. We’ll share all of our dreams, and we will hope you make them true.

Thank you so much!