Google’s Proposed Chrome Changes Would Cripple Ad Blockers, Other Extensions

This site may earn affiliate commissions from the links on this page. Terms of use.

Google has proposed a series of changes to Chrome that, if adopted in their current form, could cripple how ad blocking works within Chromium-based browsers. The impact of the changes wouldn’t be limited to ad blocking — other projects like NoScript and a wide range of other extensions would, according to their authors, also be impacted.

Google’s proposed changes, detailed in its Manifest V3 document, would make significant changes to how extensions fundamentally work within Chrome. Extensions, for example, will no longer be permitted to load code from remote servers or to automatically apply to all sites (users will have an option to choose to run extensions on specific sites or on every site). But the biggest problems appear to be with Google’s plans to deprecate or limit the use of its webRequest API. As Ars Technica details, webRequest allows extensions to evaluate each network request that the extension is intended to monitor and to make decisions about what happens to it. Requests can be modified in-flight to change how the browser behaves in a wide variety of scenarios. Ad blockers, script blockers, and a number of various privacy-oriented extensions rely on this capability.

Google wants to replace webRequest with a new API, declarativeNetRequest. Using the old webRequest API requires that the browser ask the extension how content should be handled. The new API instead requires that the extension declare to the browser what it can do and how it does it. The problem is, the new API has a fraction of the capability of the old one. Extensions are also currently hard-limited to a constraint of 30,000 items to be filtered. As Ars notes, the current version of uBlock Origin ships with 90,000 filters by default and supports up to 500,000.

uBlock-Screenshot

The advanced functionality of extensions like uBlock isn’t possible under the new rules.

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.

While there have been reports that AdBlock Plus will have an easier time functioning under these rules than extensions like uBlock Origin, one of the authors of that extension argues that even ABP will be harmed, noting that the declarativeNetRequest API “only covers the same limited subset of filter capabilities implemented in Adblock Plus that it does in uBlock Origin.” Instead of being able to implement powerful, custom rulesets, he argues that extensions would now be limited to “providing filter rules.” This would fundamentally limit the ability of extension developers to respond quickly to website efforts to bypass their work. Security extension developers also raised these concerns, noting that the new API disallows updating content-blocking lists in real time. This alone makes it impossible for security extensions to provide fast updates.

Google’s responses, thus far, have been fairly limited. The company has been stressing that the webRequest API will be sticking around in some capacity since declarativeNetRequest can’t handle everything. It’s still evaluating the contexts in which webRequest will be allowed to function, however.

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.

Now Read:

Ex-Microsoft Intern: Google Deliberately Crippled Edge Browser

This site may earn affiliate commissions from the links on this page. Terms of use.

Allowing any one company too much control over the internet and the long-term development of web standards has always been a bad idea. It didn’t work well in the late 1990s and early 2000s when Microsoft’s Internet Explorer was the de facto standard, and it isn’t likely to be a particularly great outcome in 2018, either, now that Chromium has emerged as the single dominant player in browsing. According to a former Edge intern/developer, Microsoft has given up on its own EdgeHTML engine because it couldn’t keep up with the ways Google kept breaking major websites to disadvantage it.

In a post at Hacker News, JoshuaJB (identified via Neowin as Joshua Bakita), in response to a post theorizing that Google could exploit its dominance by integrating preferential support to boost Google app performance at the expense of other platforms or products, writes:

This is already happening. I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn’t keep up. For example, they recently added a hidden empty div over YouTube videos that causes our hardware acceleration fast-path to bail (should now be fixed in Win10 Oct update). Prior to that, our fairly state-of-the-art video acceleration put us well ahead of Chrome on video playback time on battery, but almost the instant they broke things on YouTube, they started advertising Chrome’s dominance over Edge on video-watching battery life. What makes it so sad, is that their claimed dominance was not due to ingenious optimization work by Chrome, but due to a failure of YouTube. On the whole, they only made the web slower.

Now while I’m not sure I’m convinced that YouTube was changed intentionally to slow Edge, many of my co-workers are quite convinced — and they’re the ones who looked into it personally. To add to this all, when we asked, YouTube turned down our request to remove the hidden empty div and did not elaborate further.

And this is only one case.

The irony of defending Edge and Microsoft after years of decrying the way Redmond has shoved everyone towards using Edge at every opportunity is not lost on me. Neither is the irony of defending Microsoft in general. The company’s hostility towards open source development and its fondness for monopoly may have faded somewhat in recent years, but they’ve scarcely been forgotten.

stupid-ad-2

What we needed was a happy medium between “One browser rules the Earth” and “Your browser is malware.” Image by Thurrot.com

But I don’t need to stick up for the way Microsoft pushed people to use Edge to see the danger in giving any single company too much control over standards and practices. We don’t know if the story above is actually true — as of this writing, it hasn’t been independently confirmed. But it’s not hard to believe, and we’ve seen historical examples of how this kind of monopoly can work against companies that attempt to create alternatives. IE6 dominated the internet to such a degree that websites were often programmed to perform well in Internet Explorer, even when this broke standards or failed to conform to best practices. Competing browsers that attempted to implement standards correctly would then fail to work with IE6 pages.

Ars Technica gives another example of how Google has designed sites like YouTube to favor its own approach, to the detriment of other browsers.

As another example, YouTube uses a feature called HTML imports to load scripts. HTML imports haven’t been widely adopted, either by developers or browsers alike, and ECMAScript modules are expected to serve the same role. But they’re available in Chrome and used by YouTube. For Firefox and Edge, YouTube sends a JavaScript implementation of HTML imports which carries significant performance overheads. The result? YouTube pages that load in a second in Chrome take many seconds to load in other browsers.

The fact that Chromium is open source won’t ultimately matter much if one company still represents the overwhelming force behind its development and the associated development of future web standards. In mobile, Apple still has some sway, thanks to Safari on the iPhone. But Mozilla Firefox, with its 9 percent market share, is now the only bulwark against Chrome’s total domination of the desktop browser market.

Now Read:

Why I’m dumping Google Chrome

DumpChrome

I’ve been a Google Chrome user for so many years, I can’t remember when I switched. It’s been my favorite browser for a long time — I remember being blown away by how fast it was compared with Firefox, and while Mozilla has improved its browser significantly since 2008, Chrome still feels faster in many cases. I’m going to miss Chrome — but I’m no longer willing to tolerate the way Google handles the update process. It’s incredibly user-hostile and it’s based on a myth of infallibility.

Up until January 2014, I never gave a thought to Chrome’s frequent auto-updates. Then I got hit with version 32.0.1700, and my experience went straight to hell. Chrome began crashing upwards of 20x a day, typically without the option to recover the previous session. In some cases, I’d initiate recovery and the browser would crash before finishing the process. I tried all of the troubleshooting techniques I could find online and a few standard solutions, like disabling GPU acceleration. Nothing worked.

That’s when I discovered that Google monitors the Internet and forbids anyone from offering old versions of Chrome to download. File aggregation sites like OldVersion.com and FileHippo don’t archive Chrome. FileHippo has a notice that states Google’s policies disallow the site from offering downloads. I found a few downloads for the early version of Chrome, but all I wanted to do was step back to version 31 — and at the time, I couldn’t find it anywhere. In the end, I downloaded a beta version of Chromium.

AutoUpdate

After my experience with Chrome 32, I wanted to make certain I wasn’t caught by surprise again. Unfortunately, Chrome’s auto-update policy is deliberately difficult to use. Originally, you could disable Chrome’s Auto-Update via registry values. Google felt this was insecure, however, and mandated that you have to be able to edit group policies in Windows in order to make these changes. By default, that restricts auto-update control only to Windows 7 or Windows 8 Professional. Luckily, I have Windows 7 Pro, so I disabled the update process and went on my way.

Google Auto-Updates anyway

Last August, I logged into my system and found that Chrome had been updated. It turns out that Google had made changes to its own update process. It was no longer sufficient to set the “Auto-Update Check Period Override” to 0, as it had been. Now, the company’s help pages contained the following: “Warning: To prevent abuse of this policy, if a device is not joined to an Active Directory domain, and if this policy has been set to 0 or to a value greater than 77 hours, this setting will not be honored and replaced by 77 hours after August 2014. If you are affected by this, and still want to disable Chrome updates (NOT RECOMMENDED), you may do so by using ‘Update policy override’ as described.”

In other words, Google was still able to reach into my machine and forcibly update my software. I made the appropriate additional changes described above and again went about my business. It turns out, Google really hates it when you do that. I began to see pop-ups, at least once a day, telling me that I needed to update Google Chrome manually. Google services like Gmail or Google Drive would embed a yellow banner (shown below) when I attempted to use them. The banner would pop up every single time I used a Google service, and apparently can’t be dismissed or blocked.

chrome_not_supported

Then, last week, I stopped getting the errors. I checked my Google version and discovered I’m now running 44.0.2403.89. My policy settings haven’t changed. The only way to set them is by manually editing gpedit.msc, and that’s not a command you enter accidentally. My Downloads folder indicates that I haven’t downloaded Chrome’s installer for more than a year. Somehow, and entirely not by choice, I’m running a new browser version.

I’m aware, of course, that the trend in software is to force users to install security updates by default, and if Google had only made security patches mandatory, I’d have little issue with the company. My problem with Chrome isn’t that Google pushed out a broken software version that crashed 20x a day on my primary system — my problem is that Google has made it virtually impossible to actually choose not to update your browser. You can’t opt out. You can’t install an older version. You can’t shut Auto Update off unless you own the professional version of the Windows OS (though there are hacks to allow gpedit.msc to run on other versions of Windows). Even once you’ve jumped through the hoops required to shut off Auto Update, Google retains the ability to turn it right back on. Windows 10 at least allows users to uninstall updates if they cause a problem. In Google’s world, every version is better than the last for everyone, period, without exception.

I still like Chrome, but I’m no longer willing to put up with Google’s lockdown and willingness to override its own update policies. Back to Firefox for me.

Update: Multiple readers have questioned how I knew my problem in January 2014 was caused by a Chrome update. I didn’t just troubleshoot my browser installation — I manually deleted all associated files and reinstalled from scratch, ran stress tests and evaluations on all of my hardware including both RAM and CPU, switched from an Nvidia to an AMD GPU, confirmed that the browser would crash with just one tab and one window open (meaning not a memory leak issue), manually monitored Chrome’s memory use through Process Explorer, and tried the standard troubleshooting techniques like removing all plugins and disabling GPU acceleration. None of it worked. I didn’t include all this in the initial story because the point was to focus on the inability to disable auto-updates, not the scenario that led me to do so in the first place, but since folks have been asking, there it is.

Why I’m dumping Google Chrome

I’ve been a Google Chrome user for so many years, I can’t remember when I switched. It’s been my favorite browser for a long time — I remember being blown away by how fast it was compared with Firefox, and while Mozilla has improved its browser significantly since 2008, Chrome still feels faster in many cases. I’m going to miss Chrome — but I’m no longer willing to tolerate the way Google handles the update process. It’s incredibly user-hostile and it’s based on a myth of infallibility.

Up until January 2014, I never gave a thought to Chrome’s frequent auto-updates. Then I got hit with version 32.0.1700, and my experience went straight to hell. Chrome began crashing upwards of 20x a day, typically without the option to recover the previous session. In some cases, I’d initiate recovery and the browser would crash before finishing the process. I tried all of the troubleshooting techniques I could find online and a few standard solutions, like disabling GPU acceleration. Nothing worked.

That’s when I discovered that Google monitors the Internet and forbids anyone from offering old versions of Chrome to download. File aggregation sites like OldVersion.com and FileHippo don’t archive Chrome. FileHippo has a notice that states Google’s policies disallow the site from offering downloads. I found a few downloads for the early version of Chrome, but all I wanted to do was step back to version 31 — and at the time, I couldn’t find it anywhere. In the end, I downloaded a beta version of Chromium.

AutoUpdate

After my experience with Chrome 32, I wanted to make certain I wasn’t caught by surprise again. Unfortunately, Chrome’s auto-update policy is deliberately difficult to use. Originally, you could disable Chrome’s Auto-Update via registry values. Google felt this was insecure, however, and mandated that you have to be able to edit group policies in Windows in order to make these changes. By default, that restricts auto-update control only to Windows 7 or Windows 8 Professional. Luckily, I have Windows 7 Pro, so I disabled the update process and went on my way.

Google Auto-Updates anyway

Last August, I logged into my system and found that Chrome had been updated. It turns out that Google had made changes to its own update process. It was no longer sufficient to set the “Auto-Update Check Period Override” to 0, as it had been. Now, the company’s help pages contained the following: “Warning: To prevent abuse of this policy, if a device is not joined to an Active Directory domain, and if this policy has been set to 0 or to a value greater than 77 hours, this setting will not be honored and replaced by 77 hours after August 2014. If you are affected by this, and still want to disable Chrome updates (NOT RECOMMENDED), you may do so by using ‘Update policy override’ as described.”

In other words, Google was still able to reach into my machine and forcibly update my software. I made the appropriate additional changes described above and again went about my business. It turns out, Google really hates it when you do that. I began to see pop-ups, at least once a day, telling me that I needed to update Google Chrome manually. Google services like Gmail or Google Drive would embed a yellow banner (shown below) when I attempted to use them. The banner would pop up every single time I used a Google service, and apparently can’t be dismissed or blocked.

chrome_not_supported

Then, last week, I stopped getting the errors. I checked my Google version and discovered I’m now running 44.0.2403.89. My policy settings haven’t changed. The only way to set them is by manually editing gpedit.msc, and that’s not a command you enter accidentally. My Downloads folder indicates that I haven’t downloaded Chrome’s installer for more than a year. Somehow, and entirely not by choice, I’m running a new browser version.

I’m aware, of course, that the trend in software is to force users to install security updates by default, and if Google had only made security patches mandatory, I’d have little issue with the company. My problem with Chrome isn’t that Google pushed out a broken software version that crashed 20x a day on my primary system — my problem is that Google has made it virtually impossible to actually choose not to update your browser. You can’t opt out. You can’t install an older version. You can’t shut Auto Update off unless you own the professional version of the Windows OS (though there are hacks to allow gpedit.msc to run on other versions of Windows). Even once you’ve jumped through the hoops required to shut off Auto Update, Google retains the ability to turn it right back on. Windows 10 at least allows users to uninstall updates if they cause a problem. In Google’s world, every version is better than the last for everyone, period, without exception.

I still like Chrome, but I’m no longer willing to put up with Google’s lockdown and willingness to override its own update policies. Back to Firefox for me.

Update: Multiple readers have questioned how I knew my problem in January 2014 was caused by a Chrome update. I didn’t just troubleshoot my browser installation — I manually deleted all associated files and reinstalled from scratch, ran stress tests and evaluations on all of my hardware including both RAM and CPU, switched from an Nvidia to an AMD GPU, confirmed that the browser would crash with just one tab and one window open (meaning not a memory leak issue), manually monitored Chrome’s memory use through Process Explorer, and tried the standard troubleshooting techniques like removing all plugins and disabling GPU acceleration. None of it worked. I didn’t include all this in the initial story because the point was to focus on the inability to disable auto-updates, not the scenario that led me to do so in the first place, but since folks have been asking, there it is.

Why I’m dumping Google Chrome

I’ve been a Google Chrome user for so many years, I can’t remember when I switched. It’s been my favorite browser for a long time — I remember being blown away by how fast it was compared with Firefox, and while Mozilla has improved its browser significantly since 2008, Chrome still feels faster in many cases. I’m going to miss Chrome — but I’m no longer willing to tolerate the way Google handles the update process. It’s incredibly user-hostile and it’s based on a myth of infallibility.

Up until January 2014, I never gave a thought to Chrome’s frequent auto-updates. Then I got hit with version 32.0.1700, and my experience went straight to hell. Chrome began crashing upwards of 20x a day, typically without the option to recover the previous session. In some cases, I’d initiate recovery and the browser would crash before finishing the process. I tried all of the troubleshooting techniques I could find online and a few standard solutions, like disabling GPU acceleration. Nothing worked.

That’s when I discovered that Google monitors the Internet and forbids anyone from offering old versions of Chrome to download. File aggregation sites like OldVersion.com and FileHippo don’t archive Chrome. FileHippo has a notice that states Google’s policies disallow the site from offering downloads. I found a few downloads for the early version of Chrome, but all I wanted to do was step back to version 31 — and at the time, I couldn’t find it anywhere. In the end, I downloaded a beta version of Chromium.

AutoUpdate

After my experience with Chrome 32, I wanted to make certain I wasn’t caught by surprise again. Unfortunately, Chrome’s auto-update policy is deliberately difficult to use. Originally, you could disable Chrome’s Auto-Update via registry values. Google felt this was insecure, however, and mandated that you have to be able to edit group policies in Windows in order to make these changes. By default, that restricts auto-update control only to Windows 7 or Windows 8 Professional. Luckily, I have Windows 7 Pro, so I disabled the update process and went on my way.

Google Auto-Updates anyway

Last August, I logged into my system and found that Chrome had been updated. It turns out that Google had made changes to its own update process. It was no longer sufficient to set the “Auto-Update Check Period Override” to 0, as it had been. Now, the company’s help pages contained the following: “Warning: To prevent abuse of this policy, if a device is not joined to an Active Directory domain, and if this policy has been set to 0 or to a value greater than 77 hours, this setting will not be honored and replaced by 77 hours after August 2014. If you are affected by this, and still want to disable Chrome updates (NOT RECOMMENDED), you may do so by using ‘Update policy override’ as described.”

In other words, Google was still able to reach into my machine and forcibly update my software. I made the appropriate additional changes described above and again went about my business. It turns out, Google really hates it when you do that. I began to see pop-ups, at least once a day, telling me that I needed to update Google Chrome manually. Google services like Gmail or Google Drive would embed a yellow banner (shown below) when I attempted to use them. The banner would pop up every single time I used a Google service, and apparently can’t be dismissed or blocked.

chrome_not_supported

Then, last week, I stopped getting the errors. I checked my Google version and discovered I’m now running 44.0.2403.89. My policy settings haven’t changed. The only way to set them is by manually editing gpedit.msc, and that’s not a command you enter accidentally. My Downloads folder indicates that I haven’t downloaded Chrome’s installer for more than a year. Somehow, and entirely not by choice, I’m running a new browser version.

I’m aware, of course, that the trend in software is to force users to install security updates by default, and if Google had only made security patches mandatory, I’d have little issue with the company. My problem with Chrome isn’t that Google pushed out a broken software version that crashed 20x a day on my primary system — my problem is that Google has made it virtually impossible to actually choose not to update your browser. You can’t opt out. You can’t install an older version. You can’t shut Auto Update off unless you own the professional version of the Windows OS (though there are hacks to allow gpedit.msc to run on other versions of Windows). Even once you’ve jumped through the hoops required to shut off Auto Update, Google retains the ability to turn it right back on. Windows 10 at least allows users to uninstall updates if they cause a problem. In Google’s world, every version is better than the last for everyone, period, without exception.

I still like Chrome, but I’m no longer willing to put up with Google’s lockdown and willingness to override its own update policies. Back to Firefox for me.

Update: Multiple readers have questioned how I knew my problem in January 2014 was caused by a Chrome update. I didn’t just troubleshoot my browser installation — I manually deleted all associated files and reinstalled from scratch, ran stress tests and evaluations on all of my hardware including both RAM and CPU, switched from an Nvidia to an AMD GPU, confirmed that the browser would crash with just one tab and one window open (meaning not a memory leak issue), manually monitored Chrome’s memory use through Process Explorer, and tried the standard troubleshooting techniques like removing all plugins and disabling GPU acceleration. None of it worked. I didn’t include all this in the initial story because the point was to focus on the inability to disable auto-updates, not the scenario that led me to do so in the first place, but since folks have been asking, there it is.

Google throws nearly a billion Android users under the bus, refuses to patch OS vulnerability

Android mascot broken

Android mascot broken

When it comes to providing security updates for previous products, various manufacturers have pursued different strategies. Some, like Microsoft, tend to provide security updates long after they’ve stopped selling an operating system (Microsoft only stopped providing Windows XP support last year). Others, like Google and Apple, have pursued tighter timelines for security updates. Google is now doubling down on that schedule, refusing to patch bugs in Android 4.3 or prior, even when those bugs could expose critical vulnerabilities on nearly a billion devices.

The flaws in this case affect Android 4.1 to 4.3, aka Jelly Bean, which began shipping in mid-2012 and was the primary version of Android through late 2013, or roughly 14 months ago. Up until quite recently, Google has aggressively patched problems in Android’s WebView rendering engine. Before KitKat (Android 4.4), all versions of Android used the version of WebView found within the Android Browser for rendering HTML webpages. With KitKat and Lollipop, Google updated the operating system to use a WebView plugin derived from its Chromium project.

When Security firm Rapid7 discovered a new exploit in the Android Browser version of WebView, it contacted Google to inform the company that Android 4.3 and below were vulnerable. Google’s response and policy change are raising major eyebrows. Specifically, the company states that:

If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves, but welcome patches with the report for consideration. Other than notifying OEMs, we will not be able to take action on any report that is affecting versions before 4.4 that are not accompanied with a patch.

KitKat-Webview

This isn’t a minor issue. 60% of Android users are on pre-KitKit versions. No one uses Lollipop yet.

In other words, security staff are now expected to submit a patch to fix an issue when they report it. If they do, Google will “consider” the patch to see if it resolves the problem. If they don’t, Google now says the only thing it can do is inform various OEMs of the problem.

What Google is doing, in essence, is telling its user community “Sorry, you have to tell Samsung, LG, and Motorola to provide you with an updated version of our operating system.” This is hilariously impossible. It would never fly in the PC world — imagine Microsoft telling customers “Sorry, you have to make HP, Dell, and Lenovo provide you with a free update for our operating system.” The disparity is even larger if you consider that, in most cases, a computer running a previous version of Windows can be upgraded by the end user to run the next version. That upgrade may be a headache, but system requirements on Windows haven’t budged in nine years.

The average phone or tablet buyer has no way to upgrade their operating system unless the carrier provides an OTA update, and two-year upgrade cycles means that plenty of people are going to be stuck on broken devices with known exploits that Google isn’t going to fix. Granted, the fact that Google fixes an exploit doesn’t mean that carriers will deploy it, and fragmentation has been a major problem in Android’s ecosystem over the years — but there’s a difference between acknowledging the difficulty of maintaining security updates for the entirety of one’s user base and flatly refusing to do them.

Pushing OEMs off open-source Android

One obvious reason for Google to stop fixing Android Browser problems is that the company is aggressively moving to get OEMs to stop using Android’s open-source features and to replace them with features licensed directly from Google. Ars Technica has done an extensive write-up on this trend here, and getting rid of the Android Browser is a key facet of moving away from an Android that’s actually maintained and useful.

No, Google isn’t killing Android — it’s just ensuring that the only parts of the program that get feature updates, capability improvements, and performance enhancements are the parts that require licensing agreements and promises not to develop competing products. The reason Amazon’s Kindle Fire has its own app store, and Samsung’s continued interest in Tizen are both the result of Google’s push to embed itself into the center of mobile business while paying lip service to the idea of open source.

By throwing all of the responsibility for security updates back on carriers and security researchers, Google is telling OEMs that they can either agree to its licensing terms and fall in line, or take on the responsibility of performing security updates that they’re typically not qualified or funded to do. It’s a trick worthy of Microsoft in the Bad Old Days, and it’s particularly funny to see the company doing this, given that it threw Microsoft under the bus in December when it published the full details of a security flaw two days before Redmond patched it, on the grounds that the desktop and laptop OS company wasn’t moving fast enough.

Now read: Google finds critical vulnerability in SSL 3.0 called POODLE

Google throws nearly a billion Android users under the bus, refuses to patch OS vulnerability

Android mascot broken

When it comes to providing security updates for previous products, various manufacturers have pursued different strategies. Some, like Microsoft, tend to provide security updates long after they’ve stopped selling an operating system (Microsoft only stopped providing Windows XP support last year). Others, like Google and Apple, have pursued tighter timelines for security updates. Google is now doubling down on that schedule, refusing to patch bugs in Android 4.3 or prior, even when those bugs could expose critical vulnerabilities on nearly a billion devices.

The flaws in this case affect Android 4.1 to 4.3, aka Jelly Bean, which began shipping in mid-2012 and was the primary version of Android through late 2013, or roughly 14 months ago. Up until quite recently, Google has aggressively patched problems in Android’s WebView rendering engine. Before KitKat (Android 4.4), all versions of Android used the version of WebView found within the Android Browser for rendering HTML webpages. With KitKat and Lollipop, Google updated the operating system to use a WebView plugin derived from its Chromium project.

When Security firm Rapid7 discovered a new exploit in the Android Browser version of WebView, it contacted Google to inform the company that Android 4.3 and below were vulnerable. Google’s response and policy change are raising major eyebrows. Specifically, the company states that:

If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves, but welcome patches with the report for consideration. Other than notifying OEMs, we will not be able to take action on any report that is affecting versions before 4.4 that are not accompanied with a patch.

KitKat-Webview

This isn’t a minor issue. 60% of Android users are on pre-KitKit versions. No one uses Lollipop yet.

In other words, security staff are now expected to submit a patch to fix an issue when they report it. If they do, Google will “consider” the patch to see if it resolves the problem. If they don’t, Google now says the only thing it can do is inform various OEMs of the problem.

What Google is doing, in essence, is telling its user community “Sorry, you have to tell Samsung, LG, and Motorola to provide you with an updated version of our operating system.” This is hilariously impossible. It would never fly in the PC world — imagine Microsoft telling customers “Sorry, you have to make HP, Dell, and Lenovo provide you with a free update for our operating system.” The disparity is even larger if you consider that, in most cases, a computer running a previous version of Windows can be upgraded by the end user to run the next version. That upgrade may be a headache, but system requirements on Windows haven’t budged in nine years.

The average phone or tablet buyer has no way to upgrade their operating system unless the carrier provides an OTA update, and two-year upgrade cycles means that plenty of people are going to be stuck on broken devices with known exploits that Google isn’t going to fix. Granted, the fact that Google fixes an exploit doesn’t mean that carriers will deploy it, and fragmentation has been a major problem in Android’s ecosystem over the years — but there’s a difference between acknowledging the difficulty of maintaining security updates for the entirety of one’s user base and flatly refusing to do them.

Pushing OEMs off open-source Android

One obvious reason for Google to stop fixing Android Browser problems is that the company is aggressively moving to get OEMs to stop using Android’s open-source features and to replace them with features licensed directly from Google. Ars Technica has done an extensive write-up on this trend here, and getting rid of the Android Browser is a key facet of moving away from an Android that’s actually maintained and useful.

No, Google isn’t killing Android — it’s just ensuring that the only parts of the program that get feature updates, capability improvements, and performance enhancements are the parts that require licensing agreements and promises not to develop competing products. The reason Amazon’s Kindle Fire has its own app store, and Samsung’s continued interest in Tizen are both the result of Google’s push to embed itself into the center of mobile business while paying lip service to the idea of open source.

By throwing all of the responsibility for security updates back on carriers and security researchers, Google is telling OEMs that they can either agree to its licensing terms and fall in line, or take on the responsibility of performing security updates that they’re typically not qualified or funded to do. It’s a trick worthy of Microsoft in the Bad Old Days, and it’s particularly funny to see the company doing this, given that it threw Microsoft under the bus in December when it published the full details of a security flaw two days before Redmond patched it, on the grounds that the desktop and laptop OS company wasn’t moving fast enough.

Now read: Google finds critical vulnerability in SSL 3.0 called POODLE

Google throws nearly a billion Android users under the bus, refuses to patch OS vulnerability

Android mascot broken

When it comes to providing security updates for previous products, various manufacturers have pursued different strategies. Some, like Microsoft, tend to provide security updates long after they’ve stopped selling an operating system (Microsoft only stopped providing Windows XP support last year). Others, like Google and Apple, have pursued tighter timelines for security updates. Google is now doubling down on that schedule, refusing to patch bugs in Android 4.3 or prior, even when those bugs could expose critical vulnerabilities on nearly a billion devices.

The flaws in this case affect Android 4.1 to 4.3, aka Jelly Bean, which began shipping in mid-2012 and was the primary version of Android through late 2013, or roughly 14 months ago. Up until quite recently, Google has aggressively patched problems in Android’s WebView rendering engine. Before KitKat (Android 4.4), all versions of Android used the version of WebView found within the Android Browser for rendering HTML webpages. With KitKat and Lollipop, Google updated the operating system to use a WebView plugin derived from its Chromium project.

When Security firm Rapid7 discovered a new exploit in the Android Browser version of WebView, it contacted Google to inform the company that Android 4.3 and below were vulnerable. Google’s response and policy change are raising major eyebrows. Specifically, the company states that:

If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves, but welcome patches with the report for consideration. Other than notifying OEMs, we will not be able to take action on any report that is affecting versions before 4.4 that are not accompanied with a patch.

KitKat-Webview

This isn’t a minor issue. 60% of Android users are on pre-KitKit versions. No one uses Lollipop yet.

In other words, security staff are now expected to submit a patch to fix an issue when they report it. If they do, Google will “consider” the patch to see if it resolves the problem. If they don’t, Google now says the only thing it can do is inform various OEMs of the problem.

What Google is doing, in essence, is telling its user community “Sorry, you have to tell Samsung, LG, and Motorola to provide you with an updated version of our operating system.” This is hilariously impossible. It would never fly in the PC world — imagine Microsoft telling customers “Sorry, you have to make HP, Dell, and Lenovo provide you with a free update for our operating system.” The disparity is even larger if you consider that, in most cases, a computer running a previous version of Windows can be upgraded by the end user to run the next version. That upgrade may be a headache, but system requirements on Windows haven’t budged in nine years.

The average phone or tablet buyer has no way to upgrade their operating system unless the carrier provides an OTA update, and two-year upgrade cycles means that plenty of people are going to be stuck on broken devices with known exploits that Google isn’t going to fix. Granted, the fact that Google fixes an exploit doesn’t mean that carriers will deploy it, and fragmentation has been a major problem in Android’s ecosystem over the years — but there’s a difference between acknowledging the difficulty of maintaining security updates for the entirety of one’s user base and flatly refusing to do them.

Pushing OEMs off open-source Android

One obvious reason for Google to stop fixing Android Browser problems is that the company is aggressively moving to get OEMs to stop using Android’s open-source features and to replace them with features licensed directly from Google. Ars Technica has done an extensive write-up on this trend here, and getting rid of the Android Browser is a key facet of moving away from an Android that’s actually maintained and useful.

No, Google isn’t killing Android — it’s just ensuring that the only parts of the program that get feature updates, capability improvements, and performance enhancements are the parts that require licensing agreements and promises not to develop competing products. The reason Amazon’s Kindle Fire has its own app store, and Samsung’s continued interest in Tizen are both the result of Google’s push to embed itself into the center of mobile business while paying lip service to the idea of open source.

By throwing all of the responsibility for security updates back on carriers and security researchers, Google is telling OEMs that they can either agree to its licensing terms and fall in line, or take on the responsibility of performing security updates that they’re typically not qualified or funded to do. It’s a trick worthy of Microsoft in the Bad Old Days, and it’s particularly funny to see the company doing this, given that it threw Microsoft under the bus in December when it published the full details of a security flaw two days before Redmond patched it, on the grounds that the desktop and laptop OS company wasn’t moving fast enough.

Now read: Google finds critical vulnerability in SSL 3.0 called POODLE