You probably shouldn't be using the WhiteHat Aviator browser if you’re concerned about security and privacy.
I want to be clear that I’m very happy people can take Chromium and build something better on top of it. That’s a big part of why Chromium is open source—to encourage community contributions and third-party innovation. And I want to commend WhiteHat on releasing the source to their fork, because that allows more honest discussion and the potential for shared innovations. But I also feel compelled to stress that building a safe browser is a very hard thing to do, which is why Chrome Security has roughly 30 full-time members and Chrome Privacy has another dozen or so themselves—and none of us are ever short on work.
So, with that in mind I want to explain why I was so concerned after a fairly cursory inspection of the Aviator source code release. First, we found that the overwhelming majority of changes were superficial and branding related, but done so in a way that seriously complicates the process of tracking upstream security fixes. That's why Aviator is perennially at least two major releases behind Chrome, and ships with dozens of publicly disclosed vulnerabilities that are already fixed in the stable Chrome release. Had these branding changes been made more carefully, this simply wouldn't be a problem and Aviator would be able to pull upstream changes and benefit from the security work being done by the Chromium Project.
Unfortunately, the story gets worse when you get to the meat of the relatively small number of technical changes in Aviator. +Tavis Ormandy
already tweeted one <http://goo.gl/GY5G2Z
>, which is the most trivial RCE bug we found yesterday, but it's important to appreciate that wasn't an isolated issue. The added code doesn’t seem to have been written with a sufficient understanding of how Chrome works, or with adequate regard for security. Take this case <http://goo.gl/7wojNk
> where explicit debug breaks are disabled for seemingly no reason at all. In Chrome that call is expected to safely terminate sandboxed processes in a whole slew of situations where the process cannot safely recover, but in Aviator all of those cases have now been turned into potentially exploitable vulnerabilities.
After looking at the newly introduced features, it’s also very hard to understand why any of these changes were made so invasively, and at the cost of hindering compatibility with upstream. Because, so far I just don’t see Aviator adding anything that couldn’t be done much more safely and cleanly via the normal extensions APIs, since the bulk of Aviator’s enhancements are actually provided by the already popular Disconnect extension for Chrome <http://goo.gl/IxaUx8
>. And the rest of the changes appear to be covered by changing a handful of well-documented <http://goo.gl/eOi72K
> default settings. And I should note you can already find detailed reccomendations <http://goo.gl/Uw1Kom
> on configuring stock Chrome for the seriously privacy and security concerned user, which strike me as more effective in practice.
In the end, I really hope this criticism is taken constructively, and provides some useful context for people who want to enhance Chrome. I'm always impressed by the size and passion of the Chromium community, and blown away by the number of people who contribute to and build projects on top of our codebase. But at the same time it’s very important that care be taken in those efforts to preserve the safety of end-users, even more so when making such bold claims about security and privacy (particularly given that security is a necessary precondition for privacy). So, it's critical to get the basics right, like following secure coding practices, tracking stable branches for security fixes, and keeping local changes minimally invasive to simplify the maintenance burden. #chrome #security