One thing I think is definitely going to disappear in the next five years is third-party application repositories (aka "app stores"). Whether that be in the form of sketchy download websites, torrent services, or even the venerable Steam.
(In the coming analysis I'm discounting advanced persistent threats like the NSA or similar intelligence agencies as their motives and capabilities are completely different from that of the kind of malware we're concerned about here. APTs are mainly concerned about breaching a very specific target and ideally leaving no evidence.)
Simply put, all application repositories are a potential vulnerability because they provide a quick and easy way to distribute potentially malicious software to a wide audience - exactly what most malware developers want. As a result, application repositories have the task of sorting though new software and filtering software known to engage in mailicious behavior. This task is complicated by the fact that, in order to "respect" the developer's "intellectual property", the repository is generally forbidden from actually inspecting the software in question. The conditions of software sold as a product forbid the easiest way of detecting common malicious behaviors.
Instead of direct inspection of source or object code, application repositories instead must make do with certification testing, sandboxing technology, and the threat of post-submission removal as the means by which they can prevent the spread of malicious software on their service.
- Certification testing is the process by which application software is run by the application store itself in order to verify compliance with a set of guidelines defining what application behavior is allowed. This allows verification of functionality but cannot prevent malicious behavior that detects the testing environment and disables itself in that case.
- Sandboxing technology prevents applications from requesting or altering information they should not have access to. This potentially allows prevention of all malicious behaviors but requires us to precisely define what a malicious behavior is. Additionally, it cannot prevent malicious behavior stemming from combinations of otherwise seemingly innocuous permissions as the proprietary nature of most software restricts us from doing dynamic analysis on application data flows.
- Post-submission removal is very simple - if you're doing something bad, we'll kill your app after-the-fact. This relies on the malicious behavior being found, however.
There's some common themes running through these procedures: they're expensive, or they are of limited use. Application repositories can and most certainly do slack off on certification testing. The business model of an app store is contrary to this kind of careful testing and sandboxing technologies are often too restrictive outside of entertainment and communication software. They exist to sell software as a fungible commodity, and that requires having low barriers to entry first and foremost, with security concerns second.
So why am I specifically mentioning third-party application stores? First-party stores have the same problems. However, first-party stores are also operated by the company that controls the chain-of-trust for the hardware platform they are selling. As a result, they have no reason to keep third-party stores running. In fact, many platforms (most notably game consoles) explicitly lock-out unauthorized software sources and have done so for about 30 years now. The platforms that didn't do that were and are subject to waves of malicious software.
The thing keeping production-capable personal computing (e.g. "desktop") platforms from adopting the kind of lock-out seen on other computing devices is mainly inertia. The kinds of software used here is sold by conglomerates like Adobe or Autodesk that already have a captive audience to begin with. Sacrificing 30% of that pure profit to an Apple or a Microsoft simply does not make sense for them. These are the big corporate clients that are keeping "desktop" computing alive.
The remaining proprietary platforms that allow third-party distributors are Windows, Mac OS, and Android. (Discounting "Linux") Each has their own ideological or historical reasons to do so: for Microsoft and Apple, it's more of a matter of backwards-compatibility. Let's look at each of them:
- Microsoft actually tried releasing a version of Windows (specifically, the RT versions of Windows 8) with restrictions on third-party distribution and the result was so unpopular that it genuinely killed any hope of ARM-based Windows hardware. Windows 10 actually backpedaled so hard on this even the phone builds now have app sideloading as an option like Android, and they never actually have attempted to enforce any kind of lockout for traditional Win32 software. (Aside from removing Win32 outright...)
- Apple is seemingly willing to treat their desktop and laptop operating system, Mac OS, as a separate entity from their more consumer-y operating systems for phones, tablets, smartwatches, and televisions. Mac OS did gain a lockout feature called "Gatekeeper", but it's easily disabled and actually allows third-parties to build, sign, and distribute their software on their own terms so long as they are willing to buy a fairly inexpensive signing certificate from Apple. In fact,
- Google's Android has had the ability to disable the lockout since day one. This is for purely ideological reasons: Google is a company staffed mainly by people who enjoy and support Free Software; so they have no interest in a lockout. The ability to install third-party replacements for keyboards, lock screens, home screens, and the app store have been there since the beginning. Yes, if you want to use their store, they'll happily take their 30%. But they aren't interested in forcing Google Play down your throat. (Which is good, because Google Play is actually worse than Apple in some places...)
So all of this sounds like good, longstanding reasons why third-party distribution is here to stay. But at the same time, they are also legacy reasons. Any medium-size shift or compromise could easily bring the last holdouts of third-party distribution onto first-party app stores, or at least within some kind of lockout framework that gives hardware owners control over the process. Microsoft could easily say that, in Windows 11, the ability to run unsigned Win32 software is a Pro pack feature, and/or requires some registry edits made by an Active Directory/Group Policy server. Apple could easily just eliminate that one checkbox on Gatekeeper that auto-approves unsigned software in OSX 10.24 or whatever.
I mean, it was a close enough fear, that back when Microsoft tried it once, Valve actually started work on their own hardware ecosystem specifically so they could keep their software one relevant. And, out of the big players in the software distribution industry, Valve's Steam is probably the most vulnerable. Not only do they rely entirely on other hardware ecosystems to work, but they also have the same quality-control problems other app stores have. What happens when the next Digital Homicide decides to get revenge on people who mock their crappy games by, say, stealing their private messages or bank details or what have you?
Hell, this isn't even an abstract concern - there have already been attempts at distributing malware through fake Steam download prompts. And Steam applications, unlike literally every other first-party app store, are not sandboxed at all. Some of them actually come with their own intrusive DRM, which should be considered on the same level as malware.
So that's what I think about third-party app-stores and their future in a world with hardware manufacturers more concerned about malware than ever before. I think the days of third-party app stores are numbered; the days of developers being able to independently distribute their stuff is numbered. Maybe not in exactly five years, but soon.