Did Google withhold malware protection details from partners?

Did Google withhold malware protection details from partners?

Summary: Google's Safe Browsing API is a core security feature of Chrome that Google shares with Firefox and Safari. Now, a security research firm that specializes in measuring the effectiveness of these filters says its most recent data suggest Google is not playing fair with its partners.

SHARE:

Update: Reaction from Google (Feb 7 ).

Update 2: Response from NSS Labs (Feb 7).

Every leading web browser incorporates technology designed to detect and block malicious downloads.

With Internet Explorer, Microsoft uses a feature called Application Reputation. Chrome, Firefox, and Safari use Google’s Safe Browsing API to check URLs against a constantly updated list of known phishing and malware sites. But a security research firm that specializes in measuring the effectiveness of these filters says its most recent data suggest Google is not playing fair with its partners.

NSS Labs, which has performed testing under contract for Microsoft in the past, says its most recent round of testing was “unsponsored” and “produced as part of NSS Labs’ independent testing information services [with] no vendor funding.”

The firm laid out its results in a 12-page paper, provocatively titled, Did Google pull a fast one on Firefox and Safari? 

“Since the adoption of Safe Browsing API v2 and the elimination of proprietary solutions,” the report’s authors write, “both [Firefox and Safari] have demonstrated a reduction in effectiveness at blocking traditional malware downloads [compared to Chrome].”

One data point in particular jumped out at the researchers:

The latest round of testing occurred from November 21, 2011 to January 5, 2012, during which NSS researchers observed what appears to be a significant change when compared with historical results. Chrome’s protection rate steadily climbed to just over 50% before suddenly falling back to 20%. Over the same time period (Nov 21, 2011 – December 21, 2011), Firefox and Safari’s block rate remained at 2%, and then inexplicably jumped to 7% on the same day Chrome’s protection fell precipitously (December 22nd).

This is what the test data looked like in graphic form:

NSS Labs noted the apparent coincidence that Google and Mozilla announced that they had renewed a lucrative search agreement on December 20, 2011:

On December 21-22, 2011  NSS Labs observed a reorientation of protection whereby proprietary protection offered by Chrome dropped dramatically while shared Safe Browsing protection within Chrome, Firefox and Safari increased. While these events may not be related, the timing raises questions.

The more serious allegation is that Google is withholding key parts of the Safe Browsing API from its supposed partners:

NSS Labs determined that Safe Browsing API v2 includes undocumented functionality that has been integrated into Chrome, but not Firefox or Safari. This undocumented functionality provides reputation services for executable files, or as Google describes it “malicious downloads”.

[…]

Chrome uses an undocumented API call to block malware once download begins. This API is not utilized by Firefox or Safari, apparently due to lack of documentation and a proprietary format.

[…]

Despite claims to the contrary, Google has developed proprietary functionality via Safe Browsing to block malicious downloads. This functionality is not available to the other Safe Browsing API v2 browsers (Firefox and Safari).

The latest round of research confirms that Microsoft’s App Rep technology is significantly more effective than the alternatives. I’ve written here about the reasons (see IE9 versus Chrome: which one blocks malware better?). Based on NSS Labs’ findings, Google appears to be trying to build a reputation engine of its own.

What’s not so clear is why Google isn’t sharing that technology with its partners.

Update: Via e-mail, a Google spokesperson denied these charges: "As before, this analysis from NSS Labs is inaccurate. Google has not withheld malware protection from the Safe Browsing API." Google criticized NSS Labs for not making its full data and research methodoology available for others to reproduce, and they suggest that it's possible the researchers were picking up a client-side download protection feature that Google has been testing. The company also argues that other browser vendors could simply examine the Chrome source code if they want to see how the experimental features have been implemented.

In the Talkback section below, Google Chrome Senior Product Manager Ian Fette adds this comment:

We have offered the new Safe Browsing features to Mozilla in the past, so to say that we are holding back this functionality is inaccurate. From our conversations, our understanding is that Mozilla is still waiting for more data from Google about the effectiveness of our new technology, and is considering those benefits against the limited circumstances in which their users would send URLs to Google for scanning (this only happens if a page looks sufficiently suspicious or an executable download is not whitelisted).

This new protection, which is designed to detect new phishing pages as well as malicious downloads, was highlighted recently on our Chromium Blog in more detail: http://blog.chromium.org/2012/01/all-about-safe-browsing.html.

We believe this is a reasonable solution for Chrome users, and Microsoft takes a similar approach in Internet Explorer that involves sending URLs to Microsoft. The offer remains for Mozilla to have access to our new APIs for Firefox should they decide that it's in the best interests of their users.

Update 2: NSS Labs responds.

1. The methodology is the same as we have used over the past few years and is publicly available. The additional analysis goes in depth to show exactly which API calls are occurring with Chrome vs. other browsers.

2. The client-side download protection blog post that they reference is from January 31, 2012 - after our test was concluded.  The download protection was announced by Google in April 2011.

3. That Google suggests other vendors have to scour Chrome source code to determine the functionality of the new features rather than provide documentation is unhelpful and "strange". It appears as though Google's new services are designed to transmit a user's browsing history data back to Google, and other browser vendors are unwilling to leap in without evaluating thoroughly the merits of that approach 

4. NSS is making the tools used in this test available to allow other researchers to reproduce our findings.

Thanks for those additional remarks.

Topics: Browser, Apple, Google, Malware, Operating Systems, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

19 comments
Log in or register to join the discussion
  • test

    test
    Dietrich T. Schmitz *Your
    • With Windows there is no guarantee you won't get infected...

      @Dietrich T. Schmitz * Your Linux Advocate

      Google Engineers say so. Citation:

      h-t-t-p://dev.chromium.org/developers/design-documents/sandbox

      Other Caveats:
      [i]
      The operating system might have bugs. Of interest are bugs in the Windows API that allow the bypass of the regular security checks. If such a bug exists, malware will be able to bypass the sandbox restrictions and broker policy and possibly compromise the computer.

      [b]Under Windows, there is no practical way to prevent code in the sandbox from calling a system service.[/b]

      In addition, third party software, particularly anti-malware solutions, can create new attack vectors. The most troublesome are applications that inject dlls in order to enable some (usually unwanted) capability. These dlls will also get injected in the sandbox process. In the best case they will malfunction, and in the worst case can create backdoors to other processes or to the file system itself, enabling specially crafted malware to escape the sandbox. [/i]

      It is worth mentioning this because nobody else is talking about it.

      The issue is that Google Engineers have identified an inherent Windows operating system limitation and have posted 'clearly' their Caveats on-line.

      As a sidebar, I will mention that, while you set up Internet Explorer on a pedestal and put Google in a 'bad light' here, there are other 'safer alternatives' for addressing the subject of 'malware protection'.

      Namely, Linux offers such protection in the form of Linux Security Modules (LSM).

      For example, Ubuntu Linux running AppArmor LSM with Firefox in its sandbox guarantees that no malware vector can escalate and further, [b]LSM does police the kernel! There is [u]zero percent chance[/u] of any malware infection using LSM sandboxed Firefox[/b]

      That makes Linux the safer choice.

      I stake my reputation on it.
      Dietrich T. Schmitz *Your
      • RE: Did Google withhold malware protection details from partners?

        @Dietrich T. Schmitz * Your Linux Advocate

        What does this rant have to do with the article? I'm glad Linux works for you, but for the rest of the planet, the limitations of Linux far outweigh any advantages.
        bigjon-x64
        • Third Party Developers Bolster Windows Apps

          @jon.bjerke@...

          because as the Engineers at Google point out, there is a defect which can't be solved, so they write their own sandbox software to mitigate risk which should be the responsibility of the O/S.

          Linux offers LSM so developers don't have to write security modules themselves.

          Get it? OK..........
          Dietrich T. Schmitz *Your
      • RE: Did Google withhold malware protection details from partners?

        @Dietrich T. Schmitz * Your Linux Advocate
        Article is outdated as it references Microsoft Windows 2000. LOL, you and Google can't your facts straight.
        Loverock Davidson-
        • The Windows API isn't changed

          @Loverock Davidson- <br><br>WINNT kernel is part of all Windows versions<br> <a href="http://en.wikipedia.org/wiki/Windows_NT" target="_blank" rel="nofollow">http://en.wikipedia.org/wiki/Windows_NT</a> <br><br>[b][i] "Windows NT is a family of operating systems produced by Microsoft, the first version of which was released in July 1993. It was a powerful high-level-language-based, processor-independent, multiprocessing, multiuser operating system with features comparable to Unix. It was intended to complement consumer versions of Windows that were based on MS-DOS. NT was the first fully 32-bit version of Windows, whereas its consumer-oriented counterparts, Windows 3.1x and Windows 9x, were 16-bit/32-bit hybrids. Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Home Server, Windows Server 2008, and Windows 7 are effectively Windows NT, although they are not branded using that name."[/i][/b]
          Dietrich T. Schmitz *Your
      • RE: Did Google withhold malware protection details from partners?

        @Dietrich T. Schmitz * Your Linux Advocate - Still banging on the same old drum?

        AppArmor secures paths, not files. You can say, for example that you don't want a given app to be able to reach a file/link at the path /etc/shadow.

        But if I was able to create a separate link to your password file, then it's entirely unprotected by AA. Great. Awesome system.

        AA is a reasonably pragmatic security feature that can be optionally applied to apps running on your machine. It is NOT, however, a ubiquitously available and universally applied security feature protecting all Linux apps and services. in fact, the fact that its NOT universally applied (nor applicable since many apps crash or their utility confined if restricted to a sandbox) means simply that the user doesn't necessarily know whether or not a given app is sandboxed or not.

        Expecting general users to understand the implications and configuration process (which itself is pretty unfriendly) is, frankly, arrogant.

        FWIW, it's possible to lock-down MOST of Windows by preventing users from accessing certain files on the HDD, by restricting apps' rights to access system features (e.g. via CLR manifests and, in Win8, metro app's "asks") and even running processes within sandboxes with minimal rights (as IE8+ does).

        As I and others have asked you to do in the past, please read the Wikipedia page on IE protected mode (and/or do a little research to educate yourself more thoroughly): http://en.wikipedia.org/wiki/Internet_Explorer_Protected_Mode
        bitcrazed
      • RE: Did Google withhold malware protection details from partners?

        @Dietrich T. Schmitz * Your Linux Advocate [b]"WINNT kernel is part of all Windows versions"[/b]

        And the WinNT kernel and OS has undergone some very important and signficant improvements over the years. In fact, Win8's kernel & OS continues the tradition and has some very important changes to improve the security and reliability of the OS and the apps that run on it.
        bitcrazed
  • RE: Did Google withhold malware protection details from partners?

    Google always plays dirty and this should not come as a surprise to anyone. Time for Firefox to change to a different API that has no ties to Google.
    Loverock Davidson-
  • How odd

    Is Bott taking a break from banging on about the evils of Apple? Surely he can't have run out of material. That'd show a decided lack of creativity on his part.

    Also, Dietrich, responding to Davidson is like banging your head against a brick wall, it might (but no guarantee there) feel better when you stop.

    Anyhow, I wonder, if Bott can explain why what Google (presuming what he babbled about was even remotely attached to reality) does is any worse than what any other browser and/or OS provider does. Or does he expect Apple/Microsoft/whoever else to give up their "secrets" too?

    It would appear here (if Schmitz and a scary Australian of my acquaintance are correct) that Google have (to a point) shared stuff, but haven't got as far as wanting to or trying to ram it down their partners' throats, which appears to be what Bott wants.

    However, given that Google probably don't have as much inside information on how their partners' systems work they're not exactly in a position to insist that their solution could or should be embedded in those products. Not that that would have been considered (with more consideration than last nights kebabs) by Bott.
    ego.sum.stig
    • RE: Did Google withhold malware protection details from partners?

      @ego.sum.stig@...

      So, using your logic, Google isn't doing anything different to what Apple / Microsoft / whoever. Since you evidently class Apple / Microsoft / whoever as evil, you accept that Google, ergo, is evil.

      Right?
      bitcrazed
  • We did not withhold protection from Mozilla as article claims

    We have offered the new Safe Browsing features to Mozilla in the past, so to say that we are holding back this functionality is inaccurate. From our conversations, our understanding is that Mozilla is still waiting for more data from Google about the effectiveness of our new technology, and is considering those benefits against the limited circumstances in which their users would send URLs to Google for scanning (this only happens if a page looks sufficiently suspicious or an executable download is not whitelisted). This new protection, which is designed to detect new phishing pages as well as malicious downloads, was highlighted recently on our Chromium Blog in more detail: http://blog.chromium.org/2012/01/all-about-safe-browsing.html. We believe this is a reasonable solution for Chrome users, and Microsoft takes a similar approach in Internet Explorer that involves sending URLs to Microsoft. The offer remains for Mozilla to have access to our new APIs for Firefox should they decide that it's in the best interests of their users.
    ifette
  • The API's are available to them......

    How they write the software to utilize those API's, are not up to Google, but up to the developers of Firefox and Safari.
    linux for me
  • RE: Did Google withhold malware protection details from partners?

    Did Google withhold malware protection details from partners?
    No
    daikon
  • RE: Did Google withhold malware protection details from partners?

    Did Google withhold malware protection details from partners?
    No
    daikon
  • RE: Did Google withhold malware protection details from partners?

    It appears the answer is no.

    Perhaps the author should have asked for Mozilla, Safari, and Google before printing the article. This is what journalist use to call research. What the author seem to have done here is taken a piece of research slap a provacative headline and release it on the net without any research or asking question to respected parties. Sloppy journalism.
    Knowles2
  • Still overplaying LSM

    @DTS The grsecurity dev has very clearly stated the risk posed by LSM in the form of exported kernel symbols (see the grsecurity web site). And has also created the enlightenment framework (look it up) that targets the exported kernel symbols to highlight the risk. Apparently, some malware miscreants have already incorporated this code into their Linux exploits. What???s really funny is that the enlightenment framework disables the LSM, AppArmor or SELinux, and makes it appear to the user or sysadmin that everything is hunky dory. Just like some Windows malware does with AV software.

    Fact is that sandboxing does indeed raise the bar for the malware miscreants. However, sandboxing, whether provided by the OS or a 3rd party, is not insurmountable. In addition, most Linux distros do not enable sandboxing for the default web browser. Instead, the user must take discrete steps to enable web browser sandboxing, assuming that the user is even aware that the option exists. Microsoft sandboxes IE by default on Windows Vista/7 using OS hooks. Apple sandboxes Safari by default on Mac OS X Lion using OS hooks. Google sandboxes Chrome by default on Windows XP/Vista/7, Mac OS X and desktop Linux (Debian, Ubuntu, Fedora and SuSE) using OS hooks to a large extent on all of the OSs.

    And desktop Linux, with or without a sandboxed web browser, is *safer* than Windows. This safety is provided by well-managed software repositories, good default security settings and a 1-2% market share. The malware miscreants simply are not interested in a desktop OS with 1-2% market share. They???re barely interested in Mac OS X with its 7% market share.

    Finally, just curious. How would you go about creating LSM-based application sandboxes for the Opera web browser, Evolution email client and your favorite media player (used for streaming) on your Linux desktop? How would you go about modifying the default AppArmor profile for Firefox on your Linux desktop? I ask because only openSuSE/SLED (with AppArmor) and Mandriva (with Tomoyo) provide the desktop user with GUI tools for creating/modifying LSM-based application sandboxes.

    Back on topic. All this nonsense about who wins web site blacklisting contests is funny. It???s much better to disable dangerous browser settings like JavaScript, IFRAMES, the Java plug-in and the Flash plug-in on one???s web browser by default. Then whitelist those web sites that are visited with any frequency. This is a default deny policy applied to dangerous web browser settings. Blacklisting web sites is reactive and the malware miscreants are always one or two steps ahead. Whitelisting web sites (if one does not whitelist everything) is proactive because one usually trusts a relatively small number of web sites. All other web sites are untrusted.
    Rabid Howler Monkey
  • On an unrelated note...

    Apple and Google work hand-in-hand?<br>Double-Click on their Apple site, Google's Safe-browsing API, and Google's search when you install the browser as default, what else?<br>What is this? Microsoft's MSNBC site also has Double-Click?
    megamanx
  • RE: Did Google withhold malware protection details from partners?

    No google can do it alone why they want to do it with partners
    jerald76