Apple and Google could be a lot clearer about their security patches

Multiple times this week, I’ve updated mobile devices with security patches from Apple and Google. And every time, the user experience has left me feeling that these companies don’t think I need to know anything about the content of those patches.

On my iPad mini 6 and my Google Pixel 5a, and then later on a review iPhone 11 (I don’t know why Apple PR hasn’t started charging me late fees on that loaner), the notice of a security patch came with a description no more specific than “bug fixes and security updates,” the vague phrasing shown on my tablet.

Photo of Google Pixel 5a and Apple iPhone 11 with each phone open to the respective company's page purporting to describe the update. The phone are seen from above, resting on a brown background.

Each update notice also came with a link that should have provided more details but did not. On the iPad and iPhone (plus the Mac mini on which I’m typing this post), Apple sent me to the same “Apple security updates” page I’ve been visiting for years–“a dusty bookshelf of a page indexing patches going back to Jan. 8, 2020,” as I described it at PCMag. My Android phone’s notification, meanwhile, sent me to a “Pixel Community” page that led off with a “Featured Posts” list of the past few months’ worth of updates for Pixel devices.

So on each device, I had to tap further to see just what was getting patched. In Apple’s case, it was a serious vulnerability in its WebKit browser framework: “Processing maliciously crafted web content may lead to arbitrary code execution.” And somebody was already exploiting this to attack users: “Apple is aware of a report that this issue may have been actively exploited.”

That kind of “zero-day” vulnerability deserves a more direct description, so people will know that it’s worth having their devices unusable during the install process (more than 6 minutes on the iPhone 11) to lower the odds of getting hacked.

Google’s February 2023 patch, meanwhile, revealed itself to include patches for accessibility, audio, Bluetooth, and calendar features, plus security fixes that were not specified in any way until after three more taps of links. Except that the Pixel update bulletin I unearthed itself only listed the vulnerabilities by “CVE” (Common Vulnerabilities and Exposures) numbers that I then had to Google for more details.

The one issue that the Pixel bulletin labeled a “high” risk turned out to be a memory bug that, per the National Institute of Standards and Technology’s vulnerabilies database, could allow “local information disclosure with no additional execution privileges needed.” I read that as an opportunity for a hostile app to snoop on my data and was then relieved to see that NIST did not describe this “vuln” as already being exploited.

I’m not saying that you should hold off on security fixes until you get a detailed breakdown of their code; your safest course is to trust Apple, Google and Microsoft and install their patches as soon as possible, because the developers there spend more time on this than you possibly can. I am saying that it should be basic software manners for these companies to allow their more curious customers to enlighten themselves about these updates as fast as possible. That means in one click, not two, four, or more.

Advertisement

Late or never Android updates remain a problem

Here’s yet another unintentional benefit of my shattering my Pixel 5a’s screen last weekend: an opportunity to reacquaint myself with how slowly many Android smartphone manufacturers still ooze out Google’s system updates.

This is not a new problem, as I can see from re-reading a piece I wrote almost 10 years ago that’s aged a little too well. I had thought that architectural changes Google made to Android starting back in 2017 would have put a dent into this problem by removing much of the recoding work from manufacturers. But dusting off the budget-priced Android phones I reviewed for CNN Underscored early this year (most of which I had not yet returned to the companies responsible, because my desk is a mess) revealed the error of that thought.

Photo shows Android phones stacked on a wooden floor, each showing their software-information screen. The Samsung Galaxy A13's screen is most visible, showing it's running Android 12 with the July 1 security patch.

After multiple cycles of checking for updates on these six phones, installing these updates, rebooting these phones, and checking for updates again until every device reported it was current, here’s where they wound up:

  • Moto G Power: Android 11, August 1 security update
  • Nokia X100: Android 11, August 1 security update
  • OnePlus Nord N200 5G: Android 12, September 5 security update
  • Samsung Galaxy A13 5G: Android 12, July 1security update
  • TCL 20 SE: Android 11, August 1 security update
  • TCL 20 Pro 5G: Android 11, April security update

The current month is October and the current Android version is 13, so the problem should be immediately obvious. And not only did none of these devices have the Android release that I installed on my beloved, now battered Pixel 5a in the middle of August, only one of these devices had Google’s latest security fixes–and only two had the Android release that Google shipped a year ago.

The good news, such as it may be, is that a low price doesn’t condem an Android phone to obsolescence. The A13 sells for $250 and the N200 $240, but both have aged better, software-wise, than the pricier Android devices in that review. You may want to consider that a factor in favor of OnePlus and Samsung if you’re shopping for a low-cost Android phone–while the lagging performance of those other vendors should rate as a serious strike against them.