Have Google just blocked the blockers?

18th April 2019 by Thomas Léost | Data

Following the exponential growth of those regularly using the internet, we saw a huge increase in people and firms monetising their web-properties.

Even from the early days of increases in web-usage, when regular internet users comprised of a broader section of society than just the *cough* nerds *cough*, there was a rapid rise in the size of advertising reach and therefore revenue available.

What started off as being a few small unobtrusive adverts dotted around a site quickly became the only thing you could see when visiting a website.

Now, advertisers specifically present people online with much more targeted advertising and bespoke messaging than they can through traditional media (thanks to the huge volume of valuable data they can collect from us). However,  unlike traditional media, we have an increasing level of control over what adverts we are exposed to.

Some clever people put together a way to block these adverts in the form of ad blockers.

The way the majority of these ad blockers work is that they will use a browser’s API (Application Programming Interface) / SDK (Software Development Kit) to intercept the traffic being sent to the browser. This means that any scripts (files) being sent to your computer from the server will be checked by the AdBlocker against known advert providers.

However, in some cases an ad blocker may not block all the adverts on a page as its database of known providers may not include a complete, up-to-date list of specific providers.

Updates from Google

Google recently requested changes to Chromium – their open-source browser project, which supplies much of the code used by Chrome.  Google put together a document to outline the requested changes.

They claim the main motivations for these changes are to improve the user experience as well as the security and privacy for the end user.

There are a number of capabilities, practices, and APIs that extensions use that we want to migrate away from due to their negative impact on the user experience... Users should have increased control over their extensions. A user should be able to determine what information is available to an extension, and be able to control that privilege.

However, would this be Google’s only motivation?

Not many people know but Google’s main revenue stream is adverts, with a reported $15,000,000,000 (15 billion) in ad revenue on external sites alone in 2015.

Therefore, the rise of ad blockers is likely to have had a negative impact on Google’s revenue, so it’s no surprise that they would like ways of making it harder for users to block the adverts that generate them revenue.

The main change that they have requested that would affect certain ad blockers is a change to the webRequest API.

As mentioned previously, this allows ad-blocking extensions to intercept traffic and manipulate it, and in most cases block it.

webRequest, the old API, that allowed extensions to intercept and block traffic will no longer be able to do so under the proposed changes. The blocking traffic functionality will now be part of the declarativeNetRequest API, which works differently to webRequest in one key area.

With webRequest the extension could do the blocking, whereas with declarativeNetRequest only Chromium will be allowed to do the blocking. Overall that doesn’t sound too bad, however, with declarativeNetRequest there is a limit to how many URLs can be blocked as Chromium imposes a limit of 30,000 rules. This will cause problems with extensions that previously had an external database with all these rules.

Thus, instead of the above flow where Chrome receives the request, asks the extension, and then eventually gets the result, the flow is that the extension tells Chrome how to handle a request and Chrome can handle it synchronously.

This links back to one of Google’s goals for these requests – to improve the users’ experience by making pages load faster.

With the prospects for these extensions looking bleak, it’s not surprising that browsers with built-in ad blockers have begun to emerge.

For example, Brave is a Chromium-based browser with an inbuilt ad & analytics blocker. As this browser is built on the same core as Chrome it has been praised as a viable alternative to Chrome, compared to the likes of Firefox which is notoriously slow for the majority of users.

It is certainly an interesting time, as the constant evolution of technology that influences how we use the internet shows no sign of slowing. This comes against a backdrop of declining print media sales and alternative revenue models being sought by publishers, with advertisers looking for even more ways of collecting data about users to create cost-effective advertising.

The battle between the users wanting to retain control of their personal information and browse without intrusion against wealthy tech giants needing to appease shareholders by increasing revenue from advertising rages on. The next tactical moves are likely to be fascinating, certainly to *cough* nerds *cough* like us.


Share this post

Related Content

Facebook’s Silent Email Switch

This week, Facebook were yet again criticised for making a change to the platform without informing its users. So what is the problem? Is there a problem, or have...

BIMA Digital Day 2017


Sony hires investigators in search of hackers

Sony has hired private investigators in a search for the hackers that performed the security breach on the database containing Playstation users’ personal information. Sony state that an additional...