Perhaps unbeknownst to you, your journey to this webpage has been a series of hops made possible by dozens of open source applications. Whether it is the encryption used to connect to this website, your browser’s engine, or the server operating this website, open source software is ubiquitous in today’s world. There are two primary reasons why many developers have jumped on the open source wagon:

• Open source projects are highly customizable, which gives developers a lot of freedom to tailor the code to fit their needs. They can pull the code apart, trim the fat that doesn’t apply to their use case, and suggest in-depth improvements. With proprietary software, you can only ask the vendor for features but can’t suggest specific implementations.
• Open source projects are agile with quick QA cycles. Fixing bugs is a community effort spread across a large number of developers who can iterate at high velocities. This feature is succinctly captured in Linus’ Law, named after Linus Torvalds, the creator of Linux. (Linus’ Law states that “given enough eyeballs, all bugs are shallow.”)

Conversely, open source projects that don’t have a commercial entity behind them lack warranties and contractual liabilities. The software is distributed as-is—without any guarantees of functionality, SLAs, or liabilities for malfunction. Because this could be a deal-breaker for enterprise companies, numerous vendors sprung up to satisfy this need and provide enterprise-level paid support for open source projects. Branch gives you the best of both worlds—we open source our SDKs, but at the same time professionally maintain them. We also extend the same best-of-class support that we provide for our core and paid products to our SDKs.

Why are open source SDKs better?

When it comes to mobile SDKs geared towards attribution and analytics, the open source model is a strong asset because:

• The open source model provides transparency. When you include an open source SDK, you know every bit of data the vendor collects about your users from their devices and websites.
• The open source model ensures security. While open source doesn’t imply secure software by default, it provides you with the ability to audit the code (or hire specialists) and determine whether the code meets your security standards. With a closed source SDK, your main line of defence is trusting the vendor when they say the code behaves as expected from a security standpoint.

You may have heard claims that open source SDKs affect the weight of the app, or that they can’t be used for enterprise apps. Such judgements are not related to whether the SDKs are open or close sourced, but rather to general software quality and processes. As such, you can know beforehand how much space any 3rd party library (open or closed) would add to your released app.

The same logic applies to claims about scalability and, more specifically, the claim that any modifications to open source code will break existing builds. You can include a specific version of third party libraries, which usually have semantic release versions. This practice ensures predictability and protects your app from any unintended consequences of a new library release. Again, these are widespread software practices that apply to both open and close sourced SDKs.

What actually does matter for security?

Users expect your mobile app to consistently function as advertised, and trust that you are taking the necessary precautions to protect their privacy. The bad guys only need to get lucky once—it only takes one security incident to ruin your reputation and erode that hard-earned trust. Therefore, it is important to understand the practices adopted by third-party vendors when integrating their SDKs. Here are the top 3 things to keep in mind when integrating an outside SDK into your mobile app:

1. Data encryption is critical when communicating between clients and servers to prevent bad actors from reading users’ data when they connect to public or compromised networks.That’s why all of Branch’s SDKs secure data transmission between apps and our servers by defaulting to leveraging HTTPS/SSL protocols since the beginning.
2. Certificate pinning is an extra layer of security added on top of SSL to prevent attackers from forging server identities. Attackers can exploit some of the trust mechanisms built into the SSL protocol to pose as legitimate entities such as the Branch API servers. Pinning circumvents such attacks by explicitly specifying the limited set of servers you can trust inside the SDK itself. Recent Branch SDK versions have made use of certificate pinning to prevent man-in-the-middle attacks as well as sniffing app traffic.
3. Proper input validation ensures that only accepted data formats are allowed into the various communication channels, preventing malformed data from corrupting databases or wreaking havoc in downstream systems. Because validation is always recommended as early as possible, all external requests to the Branch API go through a strict validation phase in our gateway before hitting any of our application servers or databases.

At Branch, two of our core values are partners first and transparency. By open-sourcing our SDKs, we’re living up to our values by maintaining transparency with respect to our data. Gone are the days of wondering how open sourced SDKs like Branch behave inside your apps and on your websites.

Click here to learn how Branch can take your mobile growth to the next level.