Connect with us

Security

Google backtracks on Chrome modifications that would have crippled ad blockers

Published

on


Image: Google // Composition: ZDNet

A study analyzing the performance of Chrome ad blocker extensions published on Friday has proven wrong claims made by Google developers last month, when a controversy broke out surrounding their decision to modify the Chrome browser in such a way that would have eventually killed off ad blockers and many other extensions.

The study, carried out by the team behind the Ghostery ad blocker, found that ad blockers had sub-millisecond impact on Chrome’s network requests that could hardly be called a performance hit.

Hours after the Ghostery team published its study and benchmark results, the Chrome team backtracked on their planned modifications.

At the root of Ghostery’s benchmark into ad blocker performance stands Manifest V3, a new standard for developing Chrome extensions that Google announced last October.

The long-winded document contained many new rules about what Chrome functions and APIs an extension should use. One of the modifications was for extensions that needed to intercept and work with network requests. Google wanted extension developers to use the new DeclarativeNetRequest API instead of the older webRequest API.

This new API came with limitations that put a muzzle on the number of network requests an extension could access. It took some time before ad blocker developers caught on to what this meant, but when they did, all hell broke loose, with both extension developers and regular users accusing the browser maker of trying to kill third-party ad blockers for the detriment of Chrome’s new built-in ad blocker (which wouldn’t be impacted).

Chrome engineers justified the change by citing the performance impact of not having a maximum value for the number of network requests an extension could access.

But the Ghostery team disagreed with this assessment.

“This work [referring to the study] was motivated by one of the claims formulated in the Manifest V3 proposal of the Chromium project: ‘the extension then performs arbitrary (and potentially very slow) JavaScript’, talking about content-blockers’ ability to process all network requests,” said Cliqz, the company behind the Ghostery ad blocker.

“From the measurements, we do not think this claim holds, as all popular content-blockers are already very efficient and should not incur any noticeable slow-down for users,” they added.

Their study –which analyzed the network performance of ad blockers such as uBlock Origin, Adblock Plus, Brave, DuckDuckGo and Cliqz’z Ghostery– found sub-millisecond median decision times per request, showing quite the opposite of what the Chrome team claimed.

Ghostery benchmark results

Image: Cliqz // Composition: ZDNet

Following the publication of this study, Google engineers made it official on a Google Groups posting hours later, announcing a relaxation of the Manifest V3 changes that would have impacted ad blockers.

“Another clarification is that the webRequest API is not going to be fully removed as part of Manifest V3,” said Chrome engineer Devlin Cronin [emphasis his].

“The extensions ecosystem on Chrome is vibrant and varied, and enables myriad use cases that would otherwise be impossible,” Cronin added. “We are committed to preserving that ecosystem and ensuring that users can continue to customize the Chrome browser to meet their needs. This includes continuing to support extensions, including content blockers, developer tools, accessibility features, and many others. It is not, nor has it ever been, our goal to prevent or break content blocking.”

Chrome’s decision to ship the ad-blocker-breaking features was doomed from the start. Regular users have grown attached to their ad blockers, and for obvious reasons. Ad blockers may come with some sort of performance impact, but they also have benefits, which haven’t gone unnoticed by end users.

A May 2018 study from the same Ghostery team found that pages tend to load up to twice as fast when using an ad blocker.

Another study released this week by software engineer Patrick Hulce showed that advertising code accounts for the largest chunk of the JavaScript execution tasks performed by a browser –giving users a good reason to block them.

Hulce study results

Image: Patrick Hulce

A DebugBear study from December 2018 also showed that ad blockers don’t impact Chrome performance as much as people think, with other extensions bringing a bigger hit to CPU consumption, page download size, and user experience.

DebugBear study results

Image: DebugBear

More browser coverage:

Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Security

Managing Vulnerabilities in a Cloud Native World

Published

on

This free 1-hour webinar from GigaOm Research brings together experts in Cloud Native Vulnerability Management, featuring analyst Iben Rodriguez and special guest from Palo Alto Networks, John Morello. The discussion will focus on optimizing cloud security posture and integration with enterprise tool sets.

We will review platforms delivering Security Posture Management and Workload Protection for Microservice based and Hybrid Cloud Workloads.

Registrants will learn how new customers can benefit from Prisma Cloud to better secure their complex multi-cloud environments. Existing customers will learn about new features they can take advantage of and how to optimize their limited resources.

Register now to join GigaOm and Palo Alto Networks for this free expert webinar.

The post Managing Vulnerabilities in a Cloud Native World appeared first on Gigaom.

Continue Reading

Security

Security Tools Help Bring Dev and Security Teams Together

Published

on

Software development teams are increasingly focused on identifying and mitigating any issues as quickly and completely as possible. This relates not only to software quality but also software security. Different organizations are at different levels when it comes to having their development teams and security teams working in concert, but the simple fact remains that there are far more developers out there than security engineers.

Those factors are leading organizations to consider security tooling and automation to proactively discover and resolve any software security issues throughout the development process. In the recent report, “GigaOm Radar for Developer Security Tools,” Shea Stewart examines a roundup of security tools aimed at software development teams.

Stewart identified three critical criteria to bear in mind when evaluating developer security tools. These include:

  • Vendors providing tools to improve application security can and should also enhance an organization’s overall security posture.
  • The prevailing “shift-left” mindset doesn’t necessarily mean the responsibility for reducing risk should shift to development, but instead focusing on security earlier in the process and continuing to do so throughout the development process will reduce risk and the need for extensive rework.
  • Security throughout the entire software development lifecycle (SDLC) is critical for any organization focused on reducing risk.

Figure 1. How Cybersecurity Applies Across Each Stage of the Software Development Lifecycle *Note: This report focuses only on the Developer Security Tooling area

Individual vendors have made varying levels of progress and innovation toward enhancing developer security. Following several acquisitions, Red Hat, Palo Alto Networks, and Rapid7 have all added tooling for developer security to their platforms. Stewart sees a couple of the smaller vendors like JFrog and Sonatype as continuing to innovate to remain ahead of the market.

Vendors delving into this category and moving deeper into “DevSecOps” all seem to be taking different approaches to their enhanced security tooling. While they are involving security in every aspect of the development process, some tend to be moving more quickly to match the pace of the SDLC. Others are trying to shore up existing platforms by adding functionality through acquisition. Both infrastructure and software developers are now sharing toolsets and processes, so these development security tools must account for the requirements of both groups.

While none of the 12 vendors evaluated in this report can provide comprehensive security throughout the entire SDLC, they all have their particular strengths and areas of focus. It is therefore incumbent upon the organization to fully and accurately assess its SDLC, involve the development and security teams, and match the unique requirements with the functionality provided by these tools. Even if it involves using more than one at different points throughout the process, focus on striking a balance between stringent security and simplifying the development process.

Read more: Key Criteria for Evaluating Developer Security Tools, and the Gigaom Radar for Developer Security Tool Companies.

The post Security Tools Help Bring Dev and Security Teams Together appeared first on Gigaom.

Continue Reading

Security

Key Criteria for Evaluating User and Entity Behavior Analytics (UEBA)

Published

on

Cybersecurity is a multidisciplinary practice that not only grows in complexity annually but evolves nearly as quickly. A survey of the security landscape today would reveal concerns ranging from the classic compromised servers to the relatively new DevSecOps practices aimed at securing the rapid deployment of new code and infrastructure. However, some things remain constant no matter how much change is introduced. While technology evolves and complexity varies, there is almost always a human component in
risks presented to an organization.

User Behavior Analysis (UBA) was designed to analyze the actions of users in an organization and attempt to identify normal and abnormal behaviors. From this analysis, malicious or risky behaviors can be detected. UBA solutions identify events that are not detectable using other methods because, unlike classic security tools (an IDS or SIEM for example), UBA does not simply pattern match or apply rule sets to data to identify security events. Instead, it looks for any and all deviations from baseline user activity.

As technology advanced and evolved, and the scope of what is connected to the network grew, the need to analyze entities other than users emerged. In response, entity analysis has been added to UBA to create UEBA or User and Entity Behavior Analysis. The strategy remains the same, but the scope of analysis has expanded to include entities involving things like daemons, processes, infrastructure, and so on.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

The post Key Criteria for Evaluating User and Entity Behavior Analytics (UEBA) appeared first on Gigaom.

Continue Reading

Trending