Tag Archives: application security

Buyer beware: Don’t get more than you bargained for this Cyber Monday

Cyber Monday is just a few days away now, and no doubt this year will set new records for online spending. Online sales in the US alone are expected to reach $3 billion on Cyber Monday, November 30th, which will be one of the largest single days for online sales in history. Unfortunately, however, we’ve found that over a quarter of UK and US-based consumers will be shopping for bargains and making purchases without first checking to see if the website of the retailer they are buying from is secure.


A survey1 conducted by Opinion Matters on behalf of WhiteHat Security discovered this disturbing fact, as well as the fact that shoppers in the US are more likely to put themselves at risk than those in the UK, with more than a third of US-based respondents admitting that they wouldn’t check the website’s security before purchasing. This is particularly worrying given that more than half of shoppers are expecting to use their credit or debit card to purchase goods this Black Friday weekend.


The consumer survey also found that a third of UK and US-based shoppers are not sure, or definitely do not know how to identify if a website is secure.


Of course, the retailers themselves have a big part to play in website security. Researchers from our Threat Research Center (TRC) analyzed retail websites between July and September 20152 and found that they are more likely to exhibit serious vulnerabilities compared to other industries. The most commonly occurring critical vulnerability classes for the retail industry were:


  • Insufficient Transport Layer Protection (with 64% likelihood): When applications do not take measures to authenticate, encrypt, and protect sensitive network traffic, data such as payment card details and personal information can be left exposed and attackers may intercept and view the information.
  • Cross Site Scripting (with 57% likelihood): Attackers can use a vulnerable website as a vehicle to deliver malicious instructions to a victim’s browser. This can lead to further attacks such as keylogging, impersonating the user, phishing and identity theft.
  • Information Leakage (with 54% likelihood): Insecure applications may reveal sensitive data that can be used by an attacker to exploit the target web application, its hosting network, or its users.
  • Brute Force (with 38% likelihood): Most commonly targeting log-in credentials, brute force attacks can also be used to retrieve the session identifier of another user, enabling the attacker to retrieve personal information and perform actions on behalf of the user.
  • Cross Site Request Forgery (with 29% likelihood): Using social engineering (such as sending a link via email or chat), attackers can trick users into submitting a request, such as transferring funds or changing their email address or password.


In response to the survey’s findings, my colleague and WhiteHat founder, Jeremiah Grossman, said, “This research suggests that when it comes to website security awareness, not only is there still some way to go on the part of the consumer, but the retailers themselves could benefit from re-assessing their security measures, particularly when considering the volume and nature of customer information that will pass through their websites this Cyber Monday.”


WhiteHat is in the business of helping organizations in the retail and other sectors secure their applications and websites. But for consumers, Grossman offers up a few simple tricks that can help shoppers stay safe online over this holiday shopping season:


  • Look out for ‘HTTPS’ when browsing: HTTP – the letters that show up in front of the URL when browsing online – indicates that the web page is using a non-secure way of transmitting data. Data can be intercepted and read at any point between the computer and the website. HTTPS on the other hand means that all the data being transmitted is encrypted. Look out for the HTTPS coloured in either green or red and a lock icon.
  • Install a modern web browser and keep it up to date: Most people are already using one of the well known web browsers, but it is also very important that they are kept up to date with the latest security patches.
  • Be wary of public WiFi: While connecting to free WiFi networks seems like a good idea, it can be extremely dangerous as it has become relatively easy for attackers to set up WiFi hotspots to spy on traffic going back and forth between users and websites. Never trust a WiFi network and avoid banking, purchasing or sensitive transactions while connected to public WiFi.
  • Go direct to the website: There will be plenty of ‘big discount’ emails around over the next few days that will entice shoppers to websites for bargain purchases. Shoppers should make sure that they go direct to the site from their web browser, rather than clicking through the email.
  • Make your passwords hard to guess: Most people wouldn’t have the same key for their car, home, office etc., and for the same reason, it makes sense to have hard-to-guess, unique passwords for online accounts.
  • Install ad blocking extensions: Malicious software often infects computers through viewing or clicking on online advertisements, so it is not a bad idea to install an ad blocking extension that either allows users to surf the web without ads, or completely block the invisible trackers that ads use to build profiles of online habits.
  • Stick to the apps you trust: When making purchases on a mobile phone, shoppers are much better off sticking to apps from companies they know and trust, rather than relying on mobile browsers and email.


If you’re a retailer interested in learning more about the security posture of your applications and websites, sign up for a free website security risk assessment. And if you’re a consumer… well, buyer beware. Follow the tips provided here for a safer holiday shopping experience.



1The WhiteHat Security survey of 4,244 online shoppers in the UK and US was conducted between 13 November 2015 and 19 November 2015.


4WhiteHat Security threat researchers conducted likelihood analysis of critical vulnerabilities in retail websites using data collected between 1 July 2015 and 30 September 2015.




University Networks

The Atlantic Monthly just published a piece about the computer security challenges facing universities. Those challenges are serious:

“Universities are extremely attractive targets,” explained Richard Bejtlich, the Chief Security Strategist at FireEye, which acquired Mandiant, the firm that investigated the hacking incident at the [New York] Times. “The sort of information they have can be very valuable — including very rich personal information that criminal groups want, and R&D data related to either basic science or grant-related research of great interest to nation state groups. Then, on the infrastructure side they also provide some of the best platforms for attacking other parties—high bandwidth, great servers, some of the best computing infrastructure in the world and a corresponding lack of interest in security.”

The issue is framed in terms of “corporate lockdown” vs. “bring your own device,” with an emphasis on network security:

There are two schools of thought on computer security at institutions of higher education. One thought is that universities are lagging behind companies in their security efforts and need to embrace a more locked-down, corporate approach to security. The other thought holds that companies are, in fact, coming around to the academic institutions’ perspective on security—with employees bringing their own devices to work, and an increasing emphasis on monitoring network activity rather than enforcing security by trying to keep out the outside world.

There’s a nod to application security, and it’s actually a great example of setting policies to incentivize users to set stronger passwords (this is not easy!):

A company, for instance, may mandate a new security system or patch for everyone on its network, but a crucial element of implementing security measures in an academic setting is often providing users with options that will meet their needs, rather than forcing them to acquiesce to changes. For example, Parks said that at the University of Idaho, users are given the choice to set passwords that are at least 15 characters in length and, if they do so, their passwords last 400 days before expiring, whereas shorter passwords must be changed every 90 days (more than 70 percent of users have chosen to create passwords that are at least 15 characters, he added).

Getting hacked is about losing control of one’s data, and the worries in the last two passages have to do with things the university can’t directly control: the security of devices that users connect to the network, and the strength of passwords chosen by users. Things beyond one’s control are generally anxiety-provoking.

Taking a step back, the data that’s of interest to hackers is found in databases, which are frequently queried by web applications. Those web applications might have vulnerabilities, and a university’s application code is under the university’s control. The application code matters in practice. Over the summer, Team GhostShell dumped data stolen from a large number of universities. According to Symantec:

In keeping with its previous modus operandi, it is likely that the group compromised the databases by way of SQL injection attacks and poorly configured PHP scripts; however, this has not been confirmed. Previous data dumps from the 2012 hacks revealed that the team used SQLmap, a popular SQL injection tool used by hackers.

Preventing SQL injection is a solved problem, but bored teenagers exploit it on university websites:

The attack, which has implications for the integrity of USyd’s security infrastructure, compromised the personal details of approximately 5,000 students and did not come to the University’s attention until February 6.

The hacker, who goes by the online alias Abdilo, told Honi that the attack had yielded email addresses and ‘pass combo lists’, though he has no intention of using the information for malicious ends.

“99% of my targets are just shit i decide to mess with because of southpark or other tv shows,” he wrote.

As for Sydney’s breach on February 2, Abdilo claimed that he had very little trouble in accessing the information, rating the university’s database security with a “0” out of 10.

“I was taunting them for awhile, they finally figured it out,” he said.

That’s a nightmare, but solving SQL injection is a lot more straightforward than working on machine learning algorithms to improve intrusion detection systems. Less academic, if you will. The challenges in the Atlantic article are real, but effective measures aren’t always the most exciting. Fixing legacy applications that students use to look at their grades or schedule doctor’s appointments doesn’t have the drama of finding currently-invisible intruders. There is no incentive or process for the faculty to work on improving the software development life cycle when their priority is often research productivity or serving on administrative committees. In these instances, partnering with a third-party SaaS application security provider is the best solution for these urgent needs.

In a sense, it’s good news that some of the most urgently needed fixes are already within our abilities.

Developers and Security Tools

A recent study from NC State states that, “the two things that were most strongly associated with using security tools were peer influence and corporate culture. As a former developer, and as someone who has reviewed the source code of countless web applications, I can say these tools are almost impossible to use for the average developer. Security tools are invariably written for security experts and consultants. Tools produce a huge percentage of false alarms – if you are lucky, you will comb through 100 false alarms to find one legitimate issue.

The false assumption here is that running a tool will result in better security. Peer pressure to do security doesn’t quite make sense because most developers are not trained in security. And since the average tool produces a large number of false alarms, and since the pressure to ship new features as quickly as possible is so high, there will never be enough time, training or background for the average developer to effectively evaluate their own security.

The “evangelist” model the study mentions does seem to work well among some of the WhiteHat Security clients. Anecdotally, I know many organizations that will accept one volunteer per security group as a security “marshall” (something similar akin to a floor “fire marshall”). That volunteer receives special security training, but ultimately acts as a bridge between his or her individual development team and the security team.

Placing the burden of security entirely on the developers is unfair, as is making them choose between fixing vulnerabilities and shipping new code. One of the dirty secrets of technology is this: even though developers often are shouldered with the responsibility of security, risk and security are really business decisions. Security is also a process that goes far beyond the development process. Developers cannot be solely responsible for application security. Business analysts, architects, developers, quality assurance, security teams, and operations all play a critical role in managing technology risk. And above all, managers (including the C-level team) must provide direction, set levels or tolerable risk, and it is ultimately responsible for making the decision to ship new code or fix vulnerabilities. That is ultimately a business decision.

#HackerKast 17: UK Bans WhatsApp and iMessage, Instagram Privacy Issues, Cross Site Content Hijacking (XSCH), Amazon S3 Bitcoin Hack

Howdy Partners! Hope you all are in full swing in the new year and taking names. I know for a fact that a ton of you are busy since every hotel in Santa Clara, Calif., was sold out this month just as Robert and I were trying to visit the mothership.

Anywho… we started this week’s HackerKast chatting about how our blog post of the North Korean Web Browser got so much traffic that it DoS’d us. The ol’ Reddit hug of death got us and our poor IT department was thrilled with us.

The first news story we covered was the brilliant discussion going on across the pond in the UK about banning a ton of encrypted messaging services, including WhatsApp and iMessage. We all feel this is a silly reactionary measure to try to thwart terrorist communications but will have repercussions that will be wide-reaching. Knowing our audience, I’m probably preaching to the choir, but there are plenty of legitimate reasons for strong encryption protected messaging services. I think another side of my feelings were best summed up by a tweet:

Next, we brought up some Instagram news about a privacy problem they had over there. Turns out that if you ever had your Instagram profile set to public, no matter what your current privacy settings, your photos are accessible via direct URL. This is a thinly veiled illusion of privacy and further proves that if you don’t want a photo seen, you shouldn’t put it on the Internet at all.

Robert followed this up by mentioning briefly some new attack research that was published recently that was dubbed Cross Site Content Hijacking. We need another acronym like we need a hole in the head but this research could prove to be very interesting. The thing that perked our ears up about this type of vuln was that it might be possible to read arbitrary HTTP Headers across domain. This includes referring URLs which are widely used as a CSRF protection in many web applications including the Django framework. We haven’t dug deeply into this one but wanted to bring it up as a potentially interesting bit of research for you folks to chew on.

Some news about an Amazon S3 hack bubbled to the top this week which we’ve heard about before but is still super fun to talk about and – more importantly – to learn to protect yourself from. We all know our private keys are an important thing to keep private but with the ever-growing popularity of programmatically spinning up and down virtual instances in Amazon it is becoming easy to forget those private keys in your code. If you are using these keys in development and you accidentally leave them in your code when you push it up to a GitHub repo, those keys are now public. GitHub and Amazon do a good job of trolling the Internet keeping an eye out for this happening but it still happens, even to the best of us. A popular (mis)use case of this kind of hack is using your private key to spin up instances that start mining bitcoins for the attacker. This usually doesn’t get caught until the victim gets the big bill in the mail for the CPU time.

“Kid hacks into school’s website to shame them for making them go to school when the roads were covered in snow” has to be our favorite headline of the week. We’d love to include the screenshots from this website defacement but they are pretty NSFW. The kids hacking school stories are always a lot of fun because I think it resonates with a lot of us who have memories of being bored in school and playing with computers just wondering if you could switch your grades. Not that any of us did such a thing.

Notable stories this week that didn’t make the cut:
Iran oders 3 communication apps blocked (LINE, WhatsApp and Tango)
AT&T is going to start supporting webrtc
Silk Road Reloaded moving to I2p instead of Tor
Obama proposal: Hacked companies have 30 days to fess up

WhatsApp and iMessage could be banned under new surveillance plans
Iran orders 3 communication apps blocked
Your private Instagrams weren’t as private as you thought they were
Content hijacking proof-of-concept using Flash, PDF and Silverlight
Dev put AWS keys on Github. Then BAD THINGS happened
Angry Student Hacks County’s Website to Apologize for Snow Day

5 Days to Setting Up an Application Security Program

Congratulations! You now have the responsibility of ensuring your web applications are secure. This is the reality that modern day CISOs and security professionals address every day. You may have even lobbied for and championed this initiative because you are acutely aware of the risk that vulnerable web applications present to the business. Or as is often the case in reaction to a breach or an attack (aka a “security event”), web applications have now appeared on the radar of your senior management team. So, where to begin? Where’s the playbook?

To assist you in this endeavor, we have created an “Application Security Program Quick Start Guide.” WhiteHat has years of combined web application and security management experience which came in very handy for this undertaking. This guide is essentially a playbook that is both easy-to-consume yet prescriptive-enough that the reader is able to walk away with concrete action items to set in motion.

Web application testing is not a fledging security activity by any measure. That said, finding resources to help navigate the process of building a web application security program are scarce and often too high-level. In practice, there is no shortage of tools or services to perform web application testing, but testing alone is not a substitute for a comprehensive web application security program. To be successful, we should aim for a program that is more than simply testing sites and delivering results to stake holders. Those activities represent just two of the many inputs and outputs necessary to reduce the risk associated with web applications.

Today we are releasing this “Application Security Program Quick Start Guide” in the hopes that it will help CISOs in their ongoing work to ensure the security of their organization’s web applications and mission-critical information. In addition, we have donated the guide under a Creative Commons license to the OWASP community for everyone to use.

You can download the guide here: https://whitehatsec.com/whitepaper/2015/01/12/whitepaper_appsec_quickstartguide.html

The OWASP project page can be found here: https://www.owasp.org/index.php/OWASP_Application_Security_Program_Quick_Start_Guide_Project

We hope this initial draft serves to spur the collective insights of those willing to participate.

#HackerKast 7: Drupal Compromise, Tor + Bitcoin Decloaking, Verizon’s ‘Perma-Cookie,’ and Formula One Racing

This week Jeremiah Grossman, Robert Hansen and Matt Johansen discuss the latest around the recent compromise to Drupal which affects any Drupal 7 site that was not patched prior to Oct. 17. Also, Robert takes us to the Circuit of the Americas Track in Austin to talk a little about a Tor + Bitcoin can effectively decloak people and even allow users to steal all the user’s bitcoins. Also a topic of discussion this week: Verizon’s Unique Identifier Header, or UIDH (aka a ‘Perma-Cookie’) which can be read by any web server that you visit and used to build a profile of your internet habits.

Assume ‘Every Drupal 7 Site Was Compromised’ Unless Patched By Oct. 15

Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine

Bitcoin Over Tor Isn’t a Good Idea

SSL/TLS MITM vulnerability CVE-2014-0224

We are aware of the OpenSSL advisory posted at https://www.openssl.org/news/secadv_20140605.txt. OpenSSL is vulnerable to a ChangeCipherSpec (CCS) Injection Vulnerability.

An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers.

The attack can only be performed between a vulnerable client *and* a vulnerable server. Desktop Web Browser clients (i.e. Firefox, Chrome Internet Explorer) and most mobile browsers( i.e. Safari mobile, Firefox mobile) are not vulnerable, because they do not use OpenSSL. Chrome on Android does use OpenSSL, and may be vulnerable. All other OpenSSL clients are vulnerable in all versions of OpenSSL.

Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.

OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m.
OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.

WhiteHat is actively working on implementing a check for sites under service. We will update this blog with additional information as it is available.

Editor’s note:
June 6, 2014
WhiteHat has added testing to identify websites currently running affected versions of OpenSSL across all of our DAST service lines. These vulnerabilities will open as “Insufficient Transport Layer Protection” in the Sentinel interface. WhiteHat recommends that all assets including non-web application servers and sites that are currently not under service with WhiteHat be tested and patched.

If you have any questions regarding the the new CCS Injection SSL Vulnerability please email support@whitehatsec.com and a representative will be happy to assist.

Podcast: An Anthropologist’s Approach to Application Security

In this edition of the WhiteHat Security podcast, I talk with Walt Williams, Senior Security and Compliance Manager Lattice Engines. Hear how Walt went from Anthropologist to Security Engineer, his approach to building relationships with developers, and why his biggest security surprise involved broken windshields.

Want to do a podcast with us? Signup to become an “Unsung Hero”.

About our “Unsung Hero Program”
Every day app sec professionals tirelessly protect the Web, and we recognize that this is largely owed to a series of small victories. These represent untold stories. We want to help share your story. To learn more click here.

Heartbleed OpenSSL Vulnerability

Monday afternoon a flaw in the way OpenSSL handles the TLS heartbeat extension was revealed and nicknamed “The Heartbleed Bug.” According to the OpenSSL Security Advisory, Heartbleed reveals ‘a missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.’ The flaw creates an opening in SSL/TLS which an attacker could use to obtain private keys, usernames/passwords and content.

OpenSSL versions 1.0.1 through 1.0.1f as well as 1.0.2-beta1 are affected. The recommended fix is upgrade to 1.0.1g and to reissue certs for any sites that were using compromised OpenSSL versions.

WhiteHat has added testing to identify websites currently running affected versions. These vulnerabilities will open as “Insufficient Transport Layer Protection” in the Sentinel interface. These tests are currently being run across all of our clients’ applications. We expect to get full coverage of all applications under service within the next two days. WhiteHat also recommends that all assets including non-web application servers and sites that are currently not under service with WhiteHat be tested. Several tools have been made available to test for open issues. To access an online testing tool visit http://filippo.io/Heartbleed/. Another tool can be found on GitHub at https://github.com/titanous/heartbleeder and a new script can be obtained from http://seclists.org/nmap-dev/2014/q2/36

If you have any questions regarding the Heartbleed Bug please email support@whitehatsec.com and a representative will be happy to assist. Below you will find a link to the OpenSSL Security Advisory: https://www.openssl.org/news/secadv_20140407.txt Reference for Heartbeat extension https://tools.ietf.org/html/rfc6520

Aviator: Some Answered Questions

We publicly released Aviator on Monday, Oct 21. Since then we’ve received an avalanche of questions, suggestions, and feature requests regarding the browser. The level of positive feedback and support has been overwhelming. Lots of great ideas and comments that will help shape where we go from here. If you have something to share, a question or concern, please contact us at aviator@whitehatsec.com.

Now let’s address some of the most often heard questions so far:

Where’s the source code to Aviator?

WhiteHat Security is still in the very early stages of Aviator’s public release and we are gathering all feedback internally. We’ll be using this feedback to prioritize where our resources will be spent. Deciding whether or not to release the source code is part of these discussions.

Aviator unitizes open source software via Chromium, don’t you have to release the source?

WhiteHat Security respects and appreciates the open source software community. We’ve long supported various open source organizations and projects throughout our history. We also know how important OSS licenses are, so we diligently studied what was required for when Aviator would be publicly available.

Chromium, of which Aviator is derived, contains a wide variety of OSS licenses. As can be seen here using aviator://credits/ in Aviator or chrome://credits/ in Google Chrome. The portions of the code we modified in Aviator are all under BSD, or BSD-like licenses. As such, publishing our changes is, strictly speaking, not a licensing requirement. This is not to say we won’t in the future, just that we’re discussing it internally first. Doing so is a big decision that shouldn’t be taken lightly. Of course, when and/if we make a change to the GPL or similar licensed software in Chromium, we’ll happily publish the updates as required.

When is Aviator going to be available for Windows, Linux, iOS, Android, etc.?

Aviator was originally an internal project designed for WhiteHat Security employees. This served as a great environment to test our theories about how a truly secure and privacy-protecting browser should work. Since WhiteHat is primarily a Mac shop, we built it for OS X. Those outside of WhiteHat wanted to use the same browser that we did, so this week we made Aviator publicly available.

We are still in the very early days of making Aviator available to the public. The feedback so far has been very positive and requests for a Windows, Linux and even open source versions are pouring in, so we are definitely determining where to focus our resources on what should come next, but there is not definite timeframe yet of when other versions will be available.

How long has WhiteHat been working on Aviator?

Browser security has been a subject of personal and professional interest for both myself, and Robert “RSnake” Hansen (Director, Product Management) for years. Both of us have discussed the risks of browser security around the world. A big part of Aviator research was spent creating something to protect WhiteHat employees and the data they are responsible for. Outside of WhiteHat many people ask us what browser we use. Individually our answer has been, “mine.” Now we can be more specific: that browser is Aviator. A browser we feel confident in using not only for our own security and privacy, but one we may confidently recommend to family and friends when asked.

Browsers have pop up blockers to deal with ads. What is different about Aviator’s approach?

Popup blockers used to work wonders, but advertisers switched to sourcing in JavaScript and actually putting content on the page. They no longer have to physically create a new window because they can take over the entire page. Using Aviator, the user’s browser doesn’t even make the connection to an advertising networks’ servers, so obnoxious or potentially dangerous ads simply don’t load.

Why isn’t the Aviator application binary signed?

During the initial phases of development we considered releasing Aviator as a Beta through the Mac Store. Browsers attempt to take advantage of the fastest method of rendering they can. These APIs are sometimes unsupported by the OS and are called “private APIs”. Apple does not support these APIs because they may change and they don’t want to be held accountable for when things break. As a result, while they allow people to use their undocumented and highly speed private APIs, they don’t allow people to distribute applications that use private APIs. We can speculate the reason being that users are likely to think it’s Apple’s fault as opposed to the program when things break. So after about a month of wrestling with it, we decided that for now, we’d avoid using the Mac Store. In the shuffle we didn’t continue signing the binaries as we had been. It was simply an oversight.

Update: November 8, 2013:
Our dev team analyzed the overly-permissive chmod settings that Aviator 1.1 shipped with. We agreed it was overly permissive and have fixed the issue to be more in line with existing browsers to protect users on multi-user systems. Click to read more on our Aviator Browser 1.2 Beta release.

Why is Aviator’s application directory world-writable?

During the development process all of our developers were on dedicated computers, not shared computers. So this was an oversight brought on by the fact that there was no need to hide data from one another and therefore chmod permissions were too lax as source files were being copied and edited. This wouldn’t have been an issue if the permissions had been changed back to their less permissive state, but it was missed. We will get it fixed in an upcoming release.

Update: November 8, 2013:
Our dev team analyzed the overly-permissive chmod settings that Aviator 1.1 shipped with. We agreed it was overly permissive and have fixed the issue to be more in line with existing browsers to protect users on multi-user systems. Click to read more on our Aviator Browser 1.2 Beta release.

Does Aviator support Chrome extensions?

Yes, all Chrome extensions should function under Aviator. If an issue comes up, please report it to aviator@whitehatsec.com so we can investigate.

Wait a minute, first you say, “if you aren’t paying you are the product,” then you offer a free browser?
Fair point. Like we’ve said, Aviator started off as an internal project simply to protect WhiteHat employees and is not an official company “product.” Those outside the company asked if they could use the same browser that we do. Aviator is our answer to that. Since we’re not in the advertising and tracking business, how could we say no? At some point in the future we’ll figure out a way to generate revenue from Aviator, but in the mean time, we’re mostly interested in offering a browser that security and privacy-conscious people want to use.

Have you gotten and feedback from the major browser vendors about Aviator? If so, what has it been?

We have not received any official feedback from any of the major browser vendors, though there has been some feedback from various employees of those vendors shared informally over Twitter. Some feedback has been positive, others negative. In either case, we’re most interested in server the everyday consumer.

Keep the questions and feedback coming and we will continue to endeavor to improve Aviator in ways that will be beneficial to the security community and to the average consumer.