Interview: Why Andrew Frost Moroz, Creator of Aloha Private Browser, Has Opened Its Core Code for the Community 

Aloha Private Browser was first launched in 2015, but only now has the team decided to go open source. I was curious to learn why: What exactly has the company opened for the community, the motivation behind this move and who might benefit from their open library. Here is my conversation with Aloha’s founder Andrew Frost Moroz. Enjoy, comment, share!  

Q: Let’s start with my burning question: Why now? Why have you waited so long to open your code? What happened?  

Andrew: We’ve been thinking about going open source since launching the first version of our browser in 2015. We believe that the internet of the future is a space where the fundamental human right to privacy is respected, where users enjoy the freedom to be private and where developers are empowered to create modern, fast and user-friendly private browsers.  And we believe that the collective power of like-minded engineers will make the internet safer and more privacy-conscious.  

One reason we are doing this now and not earlier is that we wanted to establish ourselves as an innovative team in this highly-competitive and complex web-browsing industry. Being a small company, it can be tough to make a name for yourself when competing against industry giants.  

Another reason we waited was that I felt that we should only go open source when we had a cutting-edge plug-and-play world-class product, which I believe we now have. Now when we see community requests, we can open source 30GB of complex code of Aloha Core, which represents years of world-class development. It is our contribution to the developer community, and to the future of the internet.  

A third reason was that we’ve been building a mobile browser, and it’s not easy to make a mobile app open source. The idea of open source is that the code is available for anyone to download, build an app and run it on their computer. But with a mobile app, it’s not that straightforward. A person wanting to run the code needs a developer’s account on Apple or Android and must be a professional who knows how to install the app on the phone. This means the number of potential users of that code is quite low.  

And finally, we also had to account for an important part of open source, the so-called signature verification. Each piece of open-sourced code has an encrypted key that proves it’s the actual code you want to install, created by a trusted team and ensuring the program does what it’s supposed to do without posing cybersecurity risks. When you take an open-source product for desktop and build an executable file, you can verify that the crypto key is correct.  

The problem with mobile apps is that their code is modified after being uploaded to the app store cloud. It’s often optimized, divided into parts, and run in parallel, etc. So, after being uploaded, it’s not the same code anymore and can’t be verified by the signature. We thought there weren’t many benefits in opening our mobile app code, as a general user wouldn’t be able to download, install and enjoy the product. This is especially true with our advanced product, which has a complex infrastructure and VPN functionality under the hood. We simply can’t share access to hundreds of our VPN servers.  

Q: Have you ever been asked how you can claim your product is private if it’s not open source?  

Andrew: Yes, some advanced users have asked us about that, and we’ve been thinking about how we can prove that we meet the highest data privacy standards we claim to stand for. We’ve opened access to some of our libraries, but the main thing we’ve done is undergo audits from industry experts. We actually have our code regularly checked by Leviathan Security Group as an independent third party. This is solid proof that our product meets the highest privacy standards, and that just as we tell everyone, we don’t collect, share, sell or monetize any user data in any way.   

There is another point of view that open source products provide opportunities for the bad guys. As we have a special developer team assigned to verify our product safety daily, we are sure that we will find and fix any security flaws faster than bad actors can exploit them. 

Q: What exactly have you open-sourced thus far, and whom do you expect would use it and what for?  

Andrew: Over time, we’ve built many new advanced features and eventually developed a desktop version of the Aloha browser. We realized we had created a unique cross platform product (MacOS, iOS, Android, Windows) that could benefit the developer community, making it worth going open source. We didn’t find any equivalent products in open source spheres with the same level of advancement and frequent updates.  

Aloha Core uses some open source elements such as rendering and JavaScript engines, but everything else is from our own programming and development. For the open source pieces, our team verifies these elements’ safety daily to ensure there are no trackers of any kind. Honestly, we spent years cleaning up the code. It might sound easy—just deleting some parts, right? But actually, some very smart people wrote that code initially, and many things were hidden in many places, so it was an extraordinary task to track all the little pieces, almost like a surgical operation, to remove unnecessary parts.  

The other part of our 30GB library is our in-house development. I would say it is pure browser software without unnecessary parts, which gives developers much more flexibility than using Chromium, for example.  

Q: You mentioned hidden pieces, what do you mean and where? Why do you think they are unnecessary?  

Andrew: My favorite example is a grammar and spell checker. It sounds harmless, right? In reality, each and every word you type in a browser is sent to the servers, and it’s unclear what happens next with that text. It could be your passport number, your mother’s maiden name or anything else. Then, telemetry data is always sent to browser developers. In the Aloha browser, we ask if a user is okay with that. Other browsers do it by default, and users have no clue about it. We’re talking about data showing how often a user visits each website, how many bookmarks they have, how many tabs are open, what URLs are there, their entire history, everything. So, with Aloha Core, a group of developers can build their own browser with a branded user interface and without all that nonsense that violates data privacy.  

Q: Do you expect teams of developers to use this code to build their own browsers? Andrew: Developing a browser is a complex project, so yes, this job is for teams, not individual developers. We’ve spent several years on this and will be happy to save all that time for teams that support high privacy standards. Of course, we hope the community will help us test our code and improve our product.  

By the way, this library can be used for building other products besides web browsers. For instance, many mobile apps actually use a webpage as a user interface. If you’re ordering something on Amazon via the company’s mobile app, you’re actually doing it via Amazon’s webpage. Right now, a company that owns that mobile app has only one option — to show it on Safari if the app is installed on an iPhone. Now, a company can use our Aloha Core code and build this functionality into their native mobile app with ease. That means there’s no need to send users to the website through the Safari browser.  

Q: Why did you think about going open source and contributing to the community from day one? Why is it so important to you personally?  

Andrew: I’m generally an honest person. I’m not greedy and have no intention of becoming a monopolist or even the number one company in the world. But I want to build the best product in the world and then let the market choose what they like better. Of course, I expect that people will use our code to build competitive products. But I think competition is motivating, it pushes us to do even better. Even without open source, our product inspired other developers in the past; some of our features were copied and implemented by big companies. We can’t file patents for everything we create. We just don’t have those resources. But we believe that if we work hard, put our sweat and blood into it, keep our users in mind and use our software ourselves, deliver value, we can build the best product in the world, and the market will appreciate it.  

We also expect community contributions to help us improve our product further. Right now, we have about 50 people on our team, and not all of them are engineers. And we have 30GB of code; that’s a lot! If you printed it out on paper, it would make a decent-sized physical library. So we would really appreciate the help of fellow developers who can understand the scale of what we’ve done and are skilled enough to help us improve the code. Nothing is better than building something amazing together with a community of like-minded people.  

Q: What’s next? Are you planning to continue contributing to the open source movement?  

Andrew: Yes, this is just the first step. We’re also working on a tool for developers—an AI assistant to help navigate the code. As I mentioned earlier, tracking all the functions through the open source code is challenging. We are working on a special tool that will point to each piece of code responsible for the functionality a developer is trying to find. For example, if a developer wants to prevent pop-up windows showing ads, our assistant would give a direct recommendation like: “Go to this place in the code and change this piece of code to this.” Or, maybe someone wants to display a golden font or anything else you can imagine doing in a browser. We anticipate that this can save us and other developers months of working hours. So, we’re developing this tool for ourselves and will be happy to share it with the developer community, and continue to contribute to the growth of the alternative browser market.