25th Aug 2020

Why Third-Party Libraries Can Be a Privacy Headache and How To Minimise Their Risk

by Julian Evans, CEO and founder of AppSecTest –
a Keywords Ventures company
www.linkedin.com/in/julianevans/

When it comes to developing video games, functionality quality assurance (QA) testers have many considerations to ensure an optimal end-user experience.

And while the primary function of QAs remains the discovery and documentation of software defects and bugs, the introduction in May 2018 of General Data Protection Regulation (GDPR) in the EU has seen the addition of another layer of quality control, with specific implications around third-party libraries.

In programming, third-party software is a reusable component developed by a body other than the original vendor of the development platform.

In mobile game apps, third-party libraries might be an advertising software developer kit (SDK) or a crash reporter. The third-party advertising SDK can help a developer optimise in-game advertising, whereas the crash reporter displays information to the developer to help with identifying and fixing coding problems found in the mobile game.

Generally, third-party libraries provide developers with the unique opportunity to integrate pre-tested, reusable software that saves development time and cost. This allows the developer to focus on the core features of the game that matter to players.

Mobile apps and games often share data

However, third-party libraries can be frequently updated, so it’s up to the developer to check for the latest version. The latest version might have performance improvements as well as fixes for security and privacy issues that, unless updated, could lead to a potential breach of GDPR with the threat of fines and negative publicity.

Developers should be looking to isolate library code from the mobile game if possible, to mitigate improper app behaviour, such as collecting and sharing personal information without the knowledge of the player.

For Android and iOS mobile games, third-party libraries and URLs should be reviewed by developers to check whether personal identifying information about the player is being collected and/or shared and if so, they should check that is aligned with GDPR.

It’s also important for developers to refresh consent when adding new features or third-party libraries to a game that might identify a player and share this information with another party.

However, it’s not just third parties that developers and publishers need to be conscious of.

Parent companies and data brokers can collect device and player unique identifiers to identify a player which can be used to aggregate with other data to learn more about the player such as age, billing information, location, likes and more.

The potential issues arise with third-party libraries because developers will have little or no knowledge of GDPR and what to look for in their games.

QAs have limited options when it comes to detecting third-party library GDPR issues. One option would be to develop a list of third-party libraries used for development and regularly check whether the libraries have been updated prior to every new release.

A good starting point is the US National Vulnerability Database (NVD) tool, which enables automation of vulnerability management, security measurement, and compliance. Another useful tool would be the OWASP project Dependency-Check, which has an active development community and will most likely appeal to the developers.

However, these tools won’t help you with understanding the GDPR relevance, so developers still need to know whether the GDPR applies and, if so, why, which is a current major challenge facing developers and publishers.

But there is a time-saving solution.

ASAnalyzer is designed to remove the need to have GDPR knowledge by displaying the GDPR context in an easy-to-understand language that is relevant to the problem detected.

The cloud-based tool uses detectors to identify privacy issues and advisories in the mobile game code. Data privacy issues are reported when there is a potential security issue and consent is not required. Advisories, on the other hand, are reported when personal and player information might be collected and shared without the player’s consent.

Detecting and reviewing the code for data privacy issues can take up considerable resource, but with ASAnalyzer this work can be done in minutes rather than hours.

It displays GDPR developer guidance and the location of the third-party library in the game code.

No other platform in the world is able to detect insecure code and coding defects in mobile games and display these findings as GDPR issues.

For mobile games, third-party libraries and URLs should be reviewed by developers

So while the introduction of GDPR has undoubtedly added another layer for QAs to identify third-party processors to help minimise the risk associated with data breaches, there are tools and technologies available to help games studios and developers map data flows throughout the game and third-party data system.

It’s important to remember though that GDPR also means good news for all developers working with data.

By ensuring best practice for data management and privacy when it comes to third parties, studios have the opportunity to foster a trust-based relationship with their players.

And it’s an opportunity that shouldn’t be ignored.


Julian Evans is CEO of AppSecTest — A Keywords Ventures company — with 20 years’ experience specialising in technology development, mobile/web app security and data compliance.

Learn more about ASAnalyzer here.

Share This