Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Proposed Changes To Chrome Will Effectively Kill Off Ad Blockers
Quote:Here's what the Ghostery ad blocking company said in a statement, as per Gizmodo this week:

“This would basically mean that Google is destroying ad blocking and privacy protection as we know it. They pretend to do this for the sake of privacy and browser performance; however, in reality, users would be left with only very limited ways to prevent third parties from intercepting their surfing behavior or to get rid of unwanted content.”
Losing tools like these would be a huge blow to online privacy. Countless trackers monitor browsing activity so it can be sold to the highest bidder. Most of these trackers are invisible, and there's no way to stop most of them from working unless you use some form of automated ad blocking tool. If uBO's download figures are any indicator, millions of people are doing just that.
You can probably see where this is going. Google is the exception to the rule because it makes the browser people use to view the websites on which its ads are displayed. Well, actually, it's even better than that. Google also makes the browser engine and a search tool many people use to navigate the web, as well as many of the destinations those people are searching for and the ad network used on most ad-supported sites. No other company has that much apparent power over the web.
All hope wouldn't be lost if these changes hit Google Chrome. People could switch to browsers like Firefox, Safari or Brave to continue using ad blockers. There are also hardware solutions like the Pi-hole for people who don't mind tinkering a bit and want even greater control over the information they share.

Google might not move forward with the proposed change to Chromium. But even considering this shift demonstrates the potential risks of giving one company so much influence over the web.
Quote:Thus far, feedback from actual extension developers has been unilaterally negative. The hard-coded limit on blocked or redirected URLs has been criticized by almost everyone in the Google Chromium development thread. Anti-phishing and anti-malware extension developers are also concerned because the new rules require that extension data be stored in plaintext, whereas some security-related extensions store information in hashed form.
Google’s claim that these changes will improve security and performance have been met with a gimlet eye overall. Several developers have pointed out that the performance impact of running uBlock or other ad blockers on websites is so large, any performance gains Google gets from adopting a faster API will be completely subsumed by the sharp limits on the amount of content those extensions are actually able to block. Speeding up page loads by 20 percent may not mean much if you’re loading 3-5x more data relative to using an ad blocker. Security extension authors have also argued that the security risk to breaking their own products is larger than the sum total of the improvements Google is hoping to gain.

For now, Manifest V3 remains a draft document. If Google decides to implement the current version of the standard, Firefox may see a sudden uptick in adoption. It’s now the only major cross-platform browser in active development that isn’t based on Chromium.
Quote:You can read about the limits and specifics of Ghostery’s tests on its own site, where the company discusses its metrics, why it tested the ways that it did, and what the implications are of these results. But what the benchmarks show in aggregate is that the network filtering engines these extensions use are efficient and continuously improving. This was seen as undercutting the rationale for the changes that Google was proposing, and the company backed down not long after Ghostery published its report.

Devlin Cronin of Google posted a message in Google Groups discussing the team’s new plan. Two major new features not initially included in the Manifest V3 document are dynamic rule support and a higher maximum ruleset size for block lists. Previously, Google had stated that only static rules and a maximum list size of 30K would be permissible, and both constraints were seen as major issues.

Google hasn’t stated yet what the new limit on rule lists will be — the company is still taking feedback on its proposed changes — but has pledged to continue working with the extension community to ensure that these issues are dealt with. There are hints at what the company’s original thinking may have been with the proposed changes in the first place. In his response, Cronin points out that the performance considerations for websites are often different on low-end hardware than on higher-end machines. Google may have been considering some of its proposed alterations to Chrome based on the performance characteristics of Chromebooks using ARM or low-end Intel hardware with limited amounts of RAM. Then again, as extension authors rather loudly pointed out, the performance impact of Google’s proposed Manifest V3 changes would have likely been larger than any slowdown caused by the add-ons themselves.
Quote:The discussion about what kind of rules the extension community needs versus what Google wants to enable has been ongoing, and Google has published a major response to a prepared document summarizing the extension communities’ concerns that raises new fears about what the company is planning to do. You can read the company’s full response here, but one particular sentence is causing frustration:

“Chrome is deprecating the blocking capabilities of the webRequest API in Manifest V3, not the entire webRequest API (though blocking will still be available to enterprise deployments).”

As far as the total number of available rules, the numbers are still extremely low. The maximum number of static rules is still 30K, the maximum number of dynamic rules is 5K. Regarding this continuing restriction, Google states:

“We are planning to raise these values but we won’t have updated numbers until we can run performance tests to find a good upper bound that will work across all supported devices.”
It is unclear how big of an issue this will become. Google has continued to adjust its original Manifest document and could theoretically set new limits for static and dynamic rule counts that allow most adblockers to function normally. At the same time, however, the company has not made those changes yet, and the topic clearly isn’t as settled as we thought it was in February. There’s still a chance that Google intends to cripple the function of adblockers in Chrome, while offering a pittance of support that won’t allow extensions to perform the same level of blocking they do today unless you’re an enterprise user. Even if extension developers can find new ways to work around these restrictions, they may not be capable of duplicating all functionality.

Users who do not wish to download these ‘improvements’ when Google eventually releases them can stop Chrome from updating by refusing to allow Google Update to run as a service, but this will also lock out security updates. Alternatively, there’s Firefox.
Quote:Google is charging ahead despite the controversy, however, and took to its security blog to explain why it thinks the changes are necessary for the protection of users, and to also quell concerns about the change potentially neutering ad blockers in Chrome.
This has already resulted in the rate of malicious extension installations going down by 89% since 2018, but Google feels it needs to do more. Its solution has been to change how APIs relating to extensions work. Previously, extensions such as ad blockers would be able to request all information about a network request - which would include possibly sensitive information - from the browser in order to perform their specific functions.

With the change, Google will be replacing the Web Request API with the Declarative Net Request API, which allows extension makers to have granular control over exactly the information they need from the browser, without receiving information that is sensitive or otherwise irrelevant to their function. The blog uses the following simple schematic to explain the difference:
Google concludes the post by admitting the change has been controversial, especially with regard to ad blockers, but reiterates that the change would not necessarily neuter ad blockers. Developers would simply need to change how their extensions work using the new API in order to provide the same functionality.
Quote:Ad blockers could theoretically be updated to support the new Declarative Net Request API rather than relying on the existing Web Request API. Google's pitched that switch as a benefit for developers and users alike. The new API supports more rules, limits the data provided to extensions and is supposed to enable more dynamic blocking than its predecessor. It's certainly being portrayed as an improvement.

But the switch could leave Chrome users without strong ad-blocking options as developers attempt to move to the new API. That switch also incurs real costs for those developers, some of whom don't monetize their extensions, and could limit their ability to introduce new features instead. Wired reported that some devs are also worried that switching to the new API would give Google even more control.

Google explained in a separate blog post why it's not simply offering both APIs:
This almost feels like watching a fox point out all the ways a coyote's tried to steal a farmer's livestock. There's no doubt that malicious extension developers exist, and the driving force behind Silicon Valley's surveillance economy certainly knows how technology can be exploited to profit off the collection of personal information, but the hypocrisy is just a little unsettling.

We suspect this back-and-forth won't end until Manifest V3 is finalized and integrated in Chrome. In the meantime, Mozilla's been working to improve Firefox's privacy features, and a trio of browsers that rely on Chromium have announced their intent to continue supporting the Web Request API despite relying on the same base as Chrome.

Forum Jump:

Users browsing this thread: 1 Guest(s)