3 Major Problems With Using 3rd Party Libraries
Unlike PC software, which took many decades to evolve, mobile apps have burst onto the scene with seemingly exponential growth. The versatility apps provide is unprecedented, from controlling your TV to finding the restaurant and even the arm candy you want to bring with you. From the moment a person wakes up till they fall asleep, they’re using apps to make their lives smoother and more manageable.
Making life easier through apps has brought us to an interesting paradigm – modern people are moving away from carrying around wads of cash and plastic credit cards to carrying just a few items – their phone and smartwatch. Developing and deploying apps is fairly easy, obviously depending on the intended functions and features, and many apps use some type of monetization, whether through direct credit card transfers or some form of ad marketing. By performing menial functions through 3rd parties you have less control over the product, including any vulnerabilities.
Our argument against 3rd party libraries is backed up by numerous incidents, such as questionable practices in popular SDKs, for example the Baidu scandal, where over 100 million Android users may have been spied on through a backdoor. If you think this was a simple ploy to get some simple data, think again. The exploit allowed the ill-wishing programmers to get phone details, download files on the device, upload files from the device, silently install other apps (if the device is rooted), get phone’s geolocation, and more.
Problem #1 Security
If you’re running an app with hundreds of libraries, what are the chances that one of them has a code vulnerability, and better yet, how can you possibly find such vulnerabilities? Third party libraries are a double-edged sword, powerful if used correctly, but dangerous if used incorrectly. One of the most integral parts of an app is keeping user data safe and secure. As shown in the example above, and in massive data leaks from the likes of Facebook, Dropbox, and many more. These SDKs are used by millions of apps, development teams, and startups, and they spend millions of dollars and countless hours meticulously developing these SDKs. It boggles the mind to think of what vulnerabilities lay waiting in less supported libraries.
In preparation for this year’s DEF CON, a team of researchers discovered that iOS users are not immune to data leakage and security threats. The team did a random snapshot of the App Store’s top free applications and showed 24 examples of popular apps and how they leak GPS data. It is arguable whether the app creators monetize this data, selling it to the highest bidder, but the concerns are real – some of the apps mentioned in the report were Tapatalk and Photobucket.
We don’t recommend waiting for apps to be updated, protect yourselves today by following the instructions the researchers recommend to mitigate potential problems:
Just this year it was revealed that millions of apps may be leaking data through faulty ad SDKs. Presenting his research at an RSA conference after this discovery, Roman Unuchek, security researcher, Kaspersky Lab, said that:
“The scale of what we first thought was just specific cases of careless application design is overwhelming.” “Millions of applications include third party SDKs, exposing private data that can be easily intercepted and modified – leading to malware infections, blackmail and other highly effective attack vectors on your devices.”
Problem #2 Performance
With dependency managers like CocoaPods, which has over 52 thousand libraries, it’s easy to search, install, and deploy a project pretty easily. And again, to reiterate, there’s nothing wrong with doing this for some things. These types of tools most likely won’t noticeably affect load times and other performance metrics. But they do come with caveats.
The downside of using libraries, SDKs, and dependency managers extends beyond load times into app stability, evident in crash analytics, and other bugs that cause unintended actions.
Problem #3 Lack of control
You shouldn’t expect a library creator to have any understanding or care about what your business model is. Those creators are likely trying to cater to other businesses, and you may not need all the features that are included in a certain library. This means that your code and app won’t be fully optimized. The solution? Write your own code so that it does exactly what you want it to and nothing more.
By integrating a 3rd party library, you and your code become dependent on it. You’re tied in, and if at some point you’re forced to change libraries, your code may need to be rewritten. An especially annoying thing about libraries is how quickly or slowly they’re updated and supported. In both cases, you have to rely on someone else to implement changes, and oftentimes, these changes cause crashes and other disturbances.
There’s simply no way to control the code that’s being put in the library. What ends up happening is developers spend half their time and attention reading and rereading changelogs and test engineers testing and retesting after every library update.
Takeaways: We still need 3rd party libraries
Of course, it would be silly to completely disregard 3rd party libraries. The plug-and-play aspect they bring to the table is magnificent. You can put together a working prototype lightning quick or launch a web store in a few clicks.
The dark side of open source libraries is the fact that developers and startups use too many to get the job done and get to market faster without any foresight into scaling issues down the line. So, the bottom line is – use libraries only where absolutely necessary and don’t skimp on developing your own.
Cover Photo by Andrea Piacquadio from Pexels
