 And today, I want to talk about browser 3.0, how to build secure web 3 clients. And I would like to start with this quote, they are two ages of the internet before Mosaic and after. The combination of protocols with a browser which provided a great interface proved explosive. In 24 months, the web has gone from being unknown to absolutely ubiquitous. And I like this quote because I think it's important to remind ourselves that the internet is not so old and less than 25 years ago, no one was really talking about the latest web development framework trends. No one was sharing stuff on social media because the internet didn't really exist. And people were more concerned about infrastructure things and protocols and how to scale this thing. And only a very small group of people actually had the knowledge and the tools, the money, the resources in general, to access the internet. So it was very similar to what we have with Ethereum now. But then something happened. The browser was introduced and now people actually could access the internet and then mess adoption started. And we will probably see this once the scalability and protocol problems are solved, that there is some kind of mess adoption for Ethereum as well. And then some funny things can happen and I want to show you how this looks like. So we are in the year 1994, it's December 1994 and Netscape Navigator 1.0 is released. And suddenly it is easy to access the internet and then this happens. Everyone wants to go online. Everyone wants to experience this thing before we had TV shows that would make fun of the internet that would laugh about it and suddenly it is a thing. And someone noticed this and then someone is Microsoft. And when they saw what happened, they got really scared because they were really the dominant force, they were completely owning the home computer market. And this was a big shock for them. So in July 1995, they released Windows 95 and it came pre-installed with Internet Explorer as the default browser. And some of you might say, hey, that's good, that's some healthy competition. But it was pretty much illegal. And we call this browser was 1.0 and it's not called the browser disagreement or fight. No, it's called browser wars because a big corporation used all the energy and all available resources to destroy a potential threat. The internet was becoming a thing, browsers became too big. So they were going after developers on an individual basis. They tried to sue them individually. This ended with an antitrust law suit United States versus Microsoft. They got charged with illegal tying of Internet Explorer to the Windows operating system and they had to pay hundreds of millions. And this is not super interesting. The interesting part is really this. Someone tried to monopolize and gain platform power over something that is decentralized, the Internet. And this concept of platform power is something that I want to emphasize. It means pretty much that the browsers are not just the clients that represent the infrastructure, but clients actually have the power to dictate the underlying infrastructure and protocols. They create lock-in effects and they can be gatekeepers that control who should have access and what kind of access. And we see this even today when Google is willing to pay 12 billion dollars a year to Apple just to remain the default search in Safari browser. So browsers are still a very interesting and lucrative target for big corporations and they really want to own this space and control it as much as possible. But this is not what we want. We want our tools and clients to be open and free as much as possible. We want them to be an extension to the regular web, but they should have the full access to the Ethereum network and all the benefits that come with it, such as computational power, smart contracts, cryptographic security, self-sovereign identity, decentralized storage and crypto payments. And we can call this to the browser 3.0. Unfortunately, this tool doesn't exist yet and someone needs to build it. So let's build a browser. But before we are reinventing the wheel, we should just check how much work this would be. And there's Chromium, the open source project for Google Chrome. And this project has 20 million lines of code. It takes around 6,000 person years to build. The estimated costs are 320 million US dollars, 35 programming languages are used in this project. More than 50 engineers are working on it full-time. More than 60 gigabytes of RAM are highly recommended to build it. And it takes roughly 24 hours on my machine. So that is not an option for us. We don't have these resources. But there are certain frameworks that can help us with it. And one of them is Electron. So what is Electron? Electron already comes with Chromium pre-built, pre-bundled. It has Node.js integration to customize the browser behavior. And it also has native APIs so that it runs on all major operating systems. It looks really promising. It looks like a really good tool that we can use. And many, many applications are already using it. And it's becoming a really big thing. And we see this for classical and developer tools productivity, but also a lot of crypto applications that are already using Electron. And I want to focus on, before I go to this slide, I should say this is a security talk. This was the first part, and I really wanted to emphasize why we want to build this browser. But I think now it's becoming a little bit more technical. But if one of you in the audience just recognizes one of these icons here, or you may be using one of these products on a computer that also has your private keys or some funds on it, then I think the next part, which is more technical, could still be interesting for you. I want to focus on these Web3 clients, which can be considered a subset of the browser 3.0. So these are clients that have access to the Ethereum network, but they can also host apps, decentralized apps, and they provide an interface so that these apps can actually interact with the network. And the most prominent ones are probably MetaMask, Brave, then the Ethereum Mist, and the Parity Client. And this is the approach that these projects took. So MetaMask is really convenient and it's a great tool. It's a Chrome extension. Then Brave was built on Electron. Ethereum Mist built on Electron, and Parity had a UI that was built on Electron, and now they have a wallet that is built with Electron. Brave were probably the first that recognized that Electron is not the best tool to build these kinds of browser-like applications. And then they forked Electron to fix some of the security problems, and they called it Moone. And then they realized this will also not help, and now they're going completely away to something that is closer to Chromium. And the Ethereum Mist team also realized that Electron might not be the best choice, and we have an internal project called Tau, and I will talk a little bit more about this in a second, that tries to fix all these security problems. But before I talk more about Electron, why is not just every, if Electron is not such a great option, why is not everyone just building a Chrome extension? And I really wanted to motivate this with the first couple of slides and that we need some kind of diversity. And that platform power is a big problem. And besides this, being a browser plug-in has more limitations. Limited API access, not running in Chromium forks without extension API, such as Electron. It's perceived and, oh, typo, coupled to the Chrome, Firefox, or whatever the hosting application is. It has no platform ownership, which is probably the biggest problem because then this can happen. Someone decides for you that your extension should not exist anymore, should not be available anymore. And this happened. The Metamask extension was removed from the store for a couple of days, and there are more crypto extensions that got completely banned from the store. Or this happened, someone decides that all applications should not exist anymore. And this also happened. There was something called Chrome Apps, and they got pretty much killed within the last two years. All of them. Okay, now I want to focus a little bit more on electron security. And there are a couple of ways how to build electron applications. There's a good way where you actually build a user interface with web technologies, which is what you want, or you build your depth with web technologies, and then you need to make some extensions to the browser, stuff that the browser does not offer you, a regular browser. So you design an API for this, and then when you need more access to the operating system, you write the application logic that is running in a separate process, and you have some kind of messaging mechanism that is whitelisting certain messages between these two processes. That's good, but it's also harder to build. And you can also do this with electron. You can build the whole user interface code that is running in the browser. Then you don't really need an API, and you can just write your whole application code that is also running in the browser window. And that's, for most applications, a really bad idea. And this is possible because of a feature, one of the core features of Electron, which is called node integration. So node integration allows you to access all the Node.js APIs from within the browser window. You don't need the separation of these processes anymore. You can do really crazy stuff. You can access the file system just from a regular web page. This is possible, especially because the Electron project removed the sandbox from the browser, which is one of the core security mechanisms. So that's really bad. And it opens a really large attack surface for these applications. And we should be aware of this. There's our application code, but this is only at the top. Our application has its own dependencies to NPM modules. Then it's running in the Electron framework. And the Electron framework has dependencies to Chromium, Node.js, VIde, and some lower-level APIs. And we need to be aware of the fact that every single layer can be attacked and was attacked so far. So we saw on an infrastructure level, there was a DNS attack against my Ether wallet. Then for Electron, we've seen a bunch of node integration bypasses. So you can actually turn the node integration off for these browser windows, but then we've seen cases where an application that was running in the browser window could turn it on again, which completely defeats the purpose of it. And if this was not working, they would just create a new window that had node integration on, and they would load themselves into the new window. And then they get full access to the operating system, and this is the security nightmare. And then they have full access to all your keys and files and whatever you store on your computer. On the dependency level, we've seen NPM modules being hacked. So someone created an NPM module, and they did not really protect their account. Someone was able to hack into this account. They modified the module code, and then this module is a dependency of millions of other projects, and they can infect millions of other projects. On the application level, we see a bunch of cross-site scripting attacks, which is probably the most dominant threat there, especially DOM cross-site scripting for Electron apps. Another really big thing for us are updates that are security critical, and I want to show you why. So with Mist, for example, in version 10, we have a dependency to Electron 1.8. In version 11, we have a dependency to Electron 2. So I said it before, Electron has its own set of dependencies. So Electron 1.8, for example, has a dependency to Chromium 59, then Node 8, 8.2, and V8 5.9. And Electron 2 has a dependency to Chromium 61, Node 8.9, and V8 6.1. And the latest version is for Chromium 71, for Node it's 11 and for V8 it's 7. And you don't have to remember all these numbers, I will break it down for you. The latest version is 71. The version that is used as a dependency of our Electron dependency is 61. That's a 10 version difference. Chromium has a release cycle of six weeks, that's a 60-week difference in patches, security updates, bug fixes, more than a year outdated. And it's even worse because we get this. The responsible disclosure timeline for V8 bugs, for example, is not one year, it's a couple of weeks. So we have documented exploits such as this V8 integer overflow. And you can find it online. This is an attack that works in outdated browsers. It also works for every Electron app that is still on 1.8, for example. Another big problem, who is reinstalling their browser when they want to refresh a web page? I hope no one does this because this is what crazy people do. But this is our update model right now with all the Electron apps. So in order to push a very simple change to the user interface, we would have to go through the whole process of reinstalling all the binaries that come with it, which gives you a 60 megabyte update. You need to download a new installer and then run through the whole process of updating a new browser, basically, just for very small changes. So we saw all these problems and we wanted to fix them. And we did this with our internal project called Tau. So what is Tau? Tau is also Chromium, it's Node.js, it has native APIs. But we are doing a bunch of things in a different way. So for example, there is no Node.js integration anymore. We are also not using libchromium content that is used in Electron, but we're using CEF. And CEF is maintained by Spotify and they're doing a really great job in providing really recent updates for the Chromium V8 and Chromium NV8 dependencies for the browser. We also have the advantage that Chromium embedded framework allows us to enable a full sandbox. And for the backend process, we can use whatever we want. So we can update to the latest V8 version, which is version 7, and we can update to the latest Node.js, which is version 11. And then we get these nice benefits. So V8 version 7 was released two weeks ago and it comes with WebAssembly support for threads. And that's pretty cool if you think about all the stuff that we have on our roadmap for E-wasm, for example, that rely on newer features that are not available in all browsers yet. We also have these advantages because we get all the benefits, all the changes to Node.js, all these bug fixes and improvements to the crypto API, for example, and many of the crypto algorithms that we need to achieve our goals with Ethereum are getting implemented or already implemented in your Node versions. So that's a massive benefit as well. So who's using Tau? Pretty much no one is using this, except maybe our little proof of concept project. And that's a good thing because Electron is a one size fits all solution. And you have to think about it. They're going through the full bureaucracy, the full back porting. They need to coordinate with Microsoft, with GitHub, with Slack, and all the other applications that we just saw. When they want to make a breaking change, it will take forever just because they need to coordinate it very well. They cannot just break all these applications. And we have the benefit that we can actually, we can break things, we can move fast. So it's a really small project so far. I think it's extremely promising. It's not meant really for the mainstream, but I think it's good that we're bringing out this message now that it exists. And it already has prebuilt binaries. So you can actually test it out. The prebuilt binaries are working on Mac and Windows so far. They are known for Linux, but we will probably provide them within the next weeks. And this is how it looks like. You won't see a difference to a regular Chrome browser or Electron application. You will see this is our new missed UI React running in one of the tower windows. So it's a browser window. And we can control and customize it. And we can run application code. And it has all the updates that we need and all the benefits that we want. And we also introduced this new update mechanism to avoid these painful, long release cycles, where we actually split our application into multiple parts. So the user interface is updated separately. And then we have something that we call the shell or the browser window. And this becomes interchangeable. So we can switch between Electron or Tau. As long as we have an API that the user interface communicates with and our application logic communicates with, we can run updates pretty much every day or every week for all these parts. And this is what we call the App Shell model. And there will probably be a blog post following on our Medium blog. We also have a bunch of modules and reference implementations if you're interested to check it out. There is the MISTI React project that is working in Tau and in Electron, was just recently adopted by the Ethereum GitHub repository. And then there's Create React App Extensions, which turns every React app into an Electron Tau container, as you can call it. Then there's an updater that does hot updating for these containers for Electron or Tau apps. And then we have a reference implementation for the Electron Shell and the Tau Shell that can actually host one of these React apps for Electron or Tau. And that's it. And if you're interested in any of this, you can come talk to me or you can just reach out via my GitHub or my mail. Thanks. What are your thoughts about Node WebKit? My thoughts about Node WebKit, yeah. I think one of the cool benefits of Electron is the community. So I said it's a disadvantage. It can also be considered as an advantage because you actually have this large community. And we have the same for Ethereum. You see the benefits of many projects already using these technologies. You get already tools for building update mechanisms, signing applications, or creating installers. And I think the whole ecosystem for Electron is just better than for Node WebKit. But I think Node WebKit is a cool project. And it also goes in a very similar direction. So you said that Tau is kind of like in a beta sandbox development. And you're not really saying, hey, let's start using Tau. At what point should those other applications start using Tau and integrating that? Yeah, that's a good question. There was no real roadmap. There was never the idea that this could become something really big. And I think it was also not the intention to make it a competitor to Electron, for example. We started with a proof of concept. The proof of concept looked really promising. And now we're seeing all these additional benefits and possibilities how it could integrate with other Ethereum projects, such as Remix, or the whole E-wasm efforts swarm. And I think it looks really promising. And we will probably focus all of our energy to make it the perfect fit for these applications and not any other mainstream applications. They should probably try to use Electron and just put some pressure on them so that they fix their shit. I have a question about security. Have you performed any security audit on Tau? And second question, have you put Tau into the continuous integration fuzzing systems that have been built by Martin and Guido? The answer is no and no. So Tau was not going through a security audit. Mist, of course, was going through a very complete security audit. We learned a lot from these lessons and from this audit. And we tried to incorporate all these things that we learned into Tau. But it is not in the stage where we would perform a security audit on it. The other thing is, the other question was if we have integrated into any kind of continuous integration or continuous delivery mechanism. And the answer is no, because this was on one of the slides. I mentioned it really briefly. We are rolling out our own mechanism for this, pretty much, where we have these React containers. And we're also thinking about stuff like how to properly sign these containers and modules. Because this is something that we're really missing in the whole Node.js ecosystem. You can actually put checksum on stuff, but these modules are never really signed. And we have these advantages. We know how to do it. And we could potentially incorporate it in our own mechanism. OK, thank you. So desktop has an inbuilt client of some sort? How does it work? The principle would be the same as for mist. So we would try to interact with Go Ethereum, for example, or with parity with some external client that we would download and try to update through our update mechanism. There's, of course, a potential. We saw a lot of development for the Ethereum.js project. And there could be the option to try out these JavaScript libraries to make it more like a full client at some point. But so far, there are no plans to turn it into a light client, full client, whatever. OK, so you mentioned the update process of Tau versus Electron. Electron, obviously, is you got to download the whole app, even if there was a minor change on the app, 60 megabytes, whatnot. I quite didn't get the update process of Tau, as in, like, if I want to update some HTML or CSS or something along the lines, do you download a smaller copy of the app, or how does it work? So let's say the whole app is still 60 megabytes, right? And then you want to update smaller processes. How do you go about doing that? Yeah, so the user interface, this yellow box is packaged separately. And then we have a frame for this, which is the browser frame that includes the update mechanism. And it will actually check for newer versions of this UI. It's pretty much like a hot updating mechanism for Electron apps. Only that you don't have to press F5, but someone else will do it for you, and they will check our GitHub releases page for new updates. And we also provide all the tools to publish these updates. They include checksums. They include the versioning, a channel, if it's better release. We can even make stage rollouts. So we can say something like 10% should update now. And then the shell will update these new packages, these containers, and run them.