As an app owner, how do you provide the best experience for your genuine users while keeping out the bad actors? It's not an easy problem to solve, especially on mobile.
On desktop devices, you could put a cookie on a web browser, and that would give you a high degree of confidence about the identity of that device going forward. Unfortunately, it doesn't work that way on mobile devices – apps can’t use browser cookies, or communicate with each other.
As a result, many companies rely on probabilistic approaches to mobile device identity – collecting data about the device and the user’s settings – to make little more than an educated guess as to whether the mobile is really the same one previously used on that account.
But guessing means making an uneasy trade-off between risk and usability. Either you have a low fraud threshold, which makes it easy for good users to get on board but also lets through a lot of bad actors. Or you do the opposite: clamping down hard on fraud, but putting legitimate users through a high-friction UX, which inevitably results in many good users abandoning.
Neither solution is exactly optimal. Fortunately, there is now another way, which gives you reliable security without the friction. You no longer have to guess on mobile device identity, but can be confident of knowing for sure, with a possession-based solution that gives a simple, definitive answer.
Cookies are pieces of data that a website stores on a user’s device for a variety of functions. At a basic level, cookies are used to assign each visiting device an identity, so that the site can recognise them.
This is how websites are able to keep users logged in, and how sites which don’t require a login are still able to keep track of their individual visitors and gain audience insights. By contrast, when you visit a site for the first time, or use a different device, you’ll be alerted about cookies, and 2FA (two-factor authentication) and other identification challenges may be triggered. Cookies function much the same on a mobile browser as they do on a computer.
Mobile applications, though, don’t work the same way as a browser. By nature, apps have a ‘sandbox’ design, meaning they are closed off from interacting with other apps on the phone. You’ll notice this if you try, for example, to sign in to a game using your Facebook account details. The game can’t automatically tell that you are logged in to the Facebook app or Safari: it will instead open its own WebView (in-app browser), and require you to enter your details again.
This inconvenience is by design, as it’s an important security measure: if you download an app which actually contains malware, the closed-off sandbox means it can’t infect or spy on the rest of your phone. However, the lack of cookies leads to a big user identity problem in apps, meaning they must try to verify their users through other means – with varying levels of success.
Many of the current approaches use handset data and data from the app, often with some kind of AI, to essentially ‘guess’ the answer. Let’s look now at how such probabilistic methods work – and why they’re flawed.
One probabilistic alternative to cookies is to build a ‘statistical ID’. Various services offer the ability to build a user profile – whether for identity or marketing purposes – by tracking insights about the user’s device.
For example, the app could be enabled to take note of the device’s model, user-agent, operating system, IP address, and even details such as screen size, language settings, and font. By collecting this data, the service can build up a user profile, allowing for certain degrees of variation, to attempt to determine who the user is (and whether they’re the same person across multiple instances). In theory, this data is reliable because the user can’t falsify these details. However, in reality, that’s not quite true, as users who ‘root’ their phones are able to alter even these fundamentals.
Rooting is a type of hacking that allows users to bypass restrictions and edit the core settings on their phone, normally cut off from user access – including essential system files. Since the Android operating system is open source, anyone can build on it, and although it’s more difficult, Apple devices can also be tampered with (known as ‘jailbreaking’). People root their phones for a variety of reasons, but this often involves changing the system settings to modify their phone beyond its intended capabilities, meaning data from the device can no longer be trusted.
One obvious issue with statistical profiling is privacy: users are understandably concerned about their personal information being compiled. Additionally, apps themselves can be hacked, meaning bad actors can get access to the data that is being collected – so apps that store their users’ every detail risk that information being leaked.
The landscape is shifting in response. Not only do GDPR laws mean EU businesses have had to allow users the choice to opt out of this type of data processing, but this approach is becoming a global standard.
As of iOS 14, Apple now requires explicit consent for data tracking within apps. If users opt out, their IDFA – a form of user ID which Apple offers to advertisers – is unusable to app publishers. Android’s equivalent ID is less easily rejected: users can currently only reset, not reject, data processing. But the result is the same; mobile apps cannot simply profile their users without their consent, meaning malicious actors can simply say No to being traced.
The fundamental flaw with probabilistic methods like these is that they’re still guesswork, which means having to make a trade-off between letting bad actors in, or flagging legitimate users as threats.
With a high threshold – lower security for easier user onboarding – there isn’t enough information to make a safe and high-confidence assessment: after all, malicious actors can generate endless throwaway aliases, such as email addresses, with ease.
So a low threshold – higher security requirements for user onboarding – is typically set up to catch the bad actors. But this results in too many false positives: real users get caught in the security and are then put through additional checks. As we have seen, profiling users to that degree is both increasingly more difficult and carries its own risk if compromised.
All this user dissatisfaction translates into poor conversion rates too, especially at the onboarding stage – which in turn can lead to reputational issues. New users will quickly drop off an app which gives the first impression of a frustrating UX, and look for an alternative.
Being able to identify a mobile device can have benefits to a user (a low-friction login experience, for example), but can also have some downsides (such as concerns around privacy). A balance has to be struck – maintain an acceptable level of user privacy (where the user is in explicit control of what data is being shared) in return for a greatly improved user experience, while keeping out the bad actors.
This balance is achieved by using the mobile phone number. Users are generally prepared to share their mobile phone number in order to get access to a website or application. Provided there is no other personal information required and the number is only used to identify them in order to enable access and prevent fraud, it is a trade-off users are willing to make.
Using the mobile phone number as the identifier, together with the SIM card in a user’s mobile phone for authentication (security), provides a deterministic solution (meaning no guesswork).
A SIM card is cryptographically secure, and can be verified with certainty in real time. When used in conjunction with the mobile phone number, this identification method effectively becomes a ‘server-side cookie’ for the mobile phone. How it works is simple: the user enters their mobile phone number, and the app communicates instantly with the MNO (mobile network operator) to verify that this number is the one linked to that SIM.
This ensures that the user possesses a unique physical device and isn’t a bot or fraudster using multiple identities. Rather than probabilistic, this solution is deterministic: it provides a simple yes/no answer, giving the user a frictionless experience, and giving the app confidence that each user is a genuine individual.
tru.ID can help you to implement this 21st century approach to user identity. No more guessing with unreliable and invasive data collection: our range of API-based products enable you to quickly and easily implement deterministic, secure, frictionless mobile user authentication, reducing fraud and helping you to increase mobile revenues.