The Gordian knot
In order to have a secure browser, security issues have to be fixed in a certain time frame. This sounds logically, right? For us that’s only a few days after we get to know about them. Chrome fixes vulnerabilities with every release, so we are also forced to release in sync with the Chrome releases. But every change we make in the Chromium source code causes merge conflicts. When changes made by us (and which are Avira specific) and changes made by Chromium developers overlap our tools cannot combine them together. After about 150 changes we had one conflict per week. This meant spending hours untangling code.
The sword to slice through the knot: We will not introduce differences to the Chromium code.
Let’s see the browser more like a Linux distribution (Ubuntu, for example). We select the best tools. Combine them. Maintain them. Optimize them.
Open Source Extensions
There are awesome security extensions for browsers out there. Let’s just invest some man-years, copying their features. We can make closed source versions of those extensions which are almost as good as the original – but OURS!
… just kidding …
We decided to say ‘hello’ to the communities and explained our plans to them. We already started to contribute and will contribute even more (we struggled with the foundation for the browser longer than expected, so we are a bit behind the original time frame – but more about that in another post). The first extensions are integrated, more are upcoming and planned. Efficient engineering. A win-win situation.
Contributing to Chromium
Only code differences between our browser and Chromium cause issues. If we want a security feature and contribute the code to Chromium we do not have differences nor merge conflicts. We accidentally protect more people than we have to, but nobody is perfect. 
We already did contribute a stash of changes that allow simpler branding (see below). But the HTTPS-Everywhere guys alone have a wish list of 2-3 large Chromium code changes. Our next steps will be to extend the extension programming interface (API) because we want more information available in the extensions. For example right now the encryption details (used cypher suite, Certificates) cannot be seen from an extension. That means that something like Calomel cannot be written for Chrome so far.
Contributing to 3rd party code
Chromium contains more than 100 third party libraries. They can contain vulnerabilities, bugs and flaws. When we find something we fix it and send the patches upstream (= to the authors). We are currently experimenting with the best way to release as many fixes per week as possible. As soon as we have figured out a good solution, we will inform you via another blog post.
Our own extensions
Of course we already integrated ABS (Avira Browser Safety) and our Safe Search. This is a no brainer. So let’s just move on.
Our external tools
Right now we plan on integrating our AV scanner into the browser. We already scan with the WebGuard, but the future of the internet is encryption (more HTTPS, o/). Webguard is a proxy, and scanning encrypted traffic with a proxy causes lots of crypto-headache. Luckily the browser does decrypt the data (it has to) as soon as it gets there: Scanning the content of the decrypted data packages directly inside the browser solves said crypto-headaches.
As of now WebGuard is fine. But of course we already plan for the future. When the future is here we will be ready – with scanning abilities in the browser.
This above are only about 50 % of what we plan on doing. Stay tuned for two more and rather advanced tactics that we plan on using and which will be described in the next blog post!
TL;DR:
There is so much we can do to improve the browser. Without touching the core.
Halfway down the Rabbit Hole. Time for a break.
Thorsten Sick
The post Avira’s Secure Browser: Plans and Tactics (Part 1) appeared first on Avira Blog.