User Data Privacy in iOS: Why and How To

07 Aug 2017
User Data Privacy in iOS

Nowadays, many people can't even last a minute without their phones. Probably because phones have the same functionality as computers and we can't quite picture our life without them. Our precious devices know everything about us and even more. Real-time streaming, tweets, posts on Instagram and other social networks are possible everywhere because of them. Simply put, the Internet is just crawling with our personal information. What good is that? It doesn't matter to us. Well, it doesn’t seem important till we share this information ourselves. But what if our information is stolen by applications that we are so fond of? We can't just give up many of them.

It may be said that we pay a huge price for staying in the "public digital world". Google is a good example of such services. It monitors our search history, allegedly just to help us find exactly what we want, with the use of advertising. That's very nice, but is it true that this is only for our own good? How do we know this service is not doing something bad with our data? Developers may be lying about this, but the fact is - we just don't know. We are just ready to use these services, even if there is a risk of sharing our data. Almost all good things come with a price, and this is the price we have to pay.

The above stated is true from the user's point of view, but what about the developer's perspective?

Our main goal, as developers, is to leave a trace in this world - to create a product that will be used, which will bring income and will be remembered. But it's not easy to create a good product or service. What should developers do in order to create good products? "Good user experience requires comfort, security and privacy," says Apple. Apple is positioning itself as a company that worries about us and about our personal data more than everyone else in the Silicon Valley. They are a kind of leader in user-privacy.

It sounds good, but is it indeed so?

If we take a closer look at the products and technologies that Apple produces, then they really take good care of us. Starting with the simplest: the most varied passwords, the use of fingerprints. By having these options, we already know that our data will not be taken by a thief so simply.

Also, the company says that all of their applications exist in a sandbox mode, in order to once again secure our information. And what about the constant requests for the use of our data? This is another key point in their privacy approach. With such a request, no application will be able to receive any of your personal information and certainly will not be able to use it. However, no such luck, I'm afraid, from the developers' point of view. But this is only at first glance! After all, we are heading towards a good user experience and want to enter “the hall of fame”.

Every year the company restricts the use of user data more and more, without the user's consent. As a direct consequence, there has been a continuous improvement in their products. This is very cool if you ask me. After all, even unscrupulous developers can’t steal anything that easy. We can feel free to download a lot of applications from the App Store, without worrying about a thing.

What about privacy concepts?

"Transparency, Consent and Control" should be considered as three parts on which the user data privacy is based.

They are quite similar and they themselves are not particularly separable from each other.

 

Apple has implemented these principles out of the box and they are an integral part of all applications that are created and will be created for the iOS platform. The same user consent is requested on a mandatory basis with the obligatory explanation of why we want to use his/her data and what will happen to it later on. In addition, even if you convinced the user to give you access, he/she always has the ability to monitor all applications.

This can be changed in the phone application's settings. There is a description in each application and what it does with your data. For example, the indicator of the arrow in the uppermost bar (near the time) tells us that one of the installed applications is now tracking our location data. If the user has claims against the application (or just had a change of mind) - he or she can always change the decision in the same settings. It will be done, and the developer won't be able to stop this.

From this case emerges the first important principle, which should be remembered when working with user data:

Always make sure that your user has not changed his mind so that if this happens, nothing breaks. A lot of things happen, you never know.

What other principles and rules are important in working with the user's data?

Oh, there are many of them and they will eventually multiply, since we are always on the move, like the world around us. Now, I would like to talk about some mandatory and basic recommendations for you and your precious applications:

The first case is the identification of users and their devices. There are many different situations when we really need it. Yes, there are many ready-made solutions and frameworks and so on, but we're talking about a situation where we need to do it ourselves. First and foremost, Apple recommends us to use the API out of the box. In other words, use those identifiers that already exist within the iOS platform.

What are these identifiers?

The first is the Universally Unique Identifier. It is a kind of “random value”, which is quickly and easily generated. Just one line of code and a new 128-bit unique identifier is at your service!

What if we need something more stable, without having to deal with a new value every time? Then we can safely use the second type - the Vendor Identifier. It binds to your Team ID and will be the same for all applications of the same ID. But it should be remembered that when all applications of this Team ID are deleted from the device it will be reset. Then with a new installation, the value will be new and it will live up to the next removal of all applications.

But just by coincidence, all of a sudden we need some kind of a personal identifier? In this case, Apple tells us that we should use as anonymous one rather than a “long living” identifier if possible. Anonymity will be pleasant and safe for the user, and the short lifespan of our custom ID will protect us, in case suddenly attackers somehow conjure up a way to hack us. Very convenient, isn’t it?

Among other things, this year Apple introduced their new developments for device identification. Now the developer will have the opportunity to keep a small amount of anonymous data on the device and this data won't be scared of fire, water, or even a zombie apocalypse. It will remain even after the application is removed and even if the device has been reset.

This novelty is now in the beta version and doesn’t reveal much information about itself. But let's hope that Apple will soon rejoice us with the release version of the DeviceCheck framework.

By the way, the use of this framework is possible only in the situation when you have a server with your application, because this is a server-oriented API. Therefore, saving (as well as reading) of this saved data will occur between three main elements: Applications <-> App Server < -> Apple.

Let's look at what data we can save on the device. Perhaps it will be a bit shocking, but it's only two bits of data. Yes-yes, precisely! You didn’t misread. This is 00, 01, 02 or 11. In addition, Apple will save and return to you the last modification date of these bits on the device.

Yes, it’s true that there’s really not enough data, but for some special cases, it will still be very useful. How can we accurately verify and know that this device is not a device from which some fraudulent actions were committed? Or what about the trial period of your application? The user, after all, can try to simply register under another email or number. Now you can check and monitor this.

 

Yet, there is a mandatory rule. It is relates to using this framework only as an internal additional tool. In no case as “the only” tool. And, do not forget about time. If the last time this device had an application installed was a year ago, it is quite logical that the owner could have changed. Or maybe our application has suffered huge changes and a lot of new things have been added. So, do not forget about other tools, because DeviceCheck is meant to be a “handy helper”, but not one sure solution.

The second case, (which is also quite frequent and important), derives from the first:

If in the first case we talked about how to properly identify users, now we need to somehow correctly save the data and analyse it. The second case that I would like to consider is the User Data collection. Now it doesn't even really matter for what purposes you need it. It's important to do it right. This is what we will discussing below.

Let me give you an example: We have an application that already has success with users and one day we have released a new version with some new feature. But here's the rub. We are not sure if our new feature is really good and whether our users will like it. That's why we need to collect information.

First of all, let's do this the easy way. Let's say we will give our server the date and time when the user used this novelty. So, here's the bottom line.

 

And if suddenly our data will be hacked or intercepted, then the attacker will know this too and this is not safe at all.

Everything seems well, but it isn't. What is the upside of us sending so much data to our server? We do it constantly too.  It's not good for us. What if there will be no Internet connection? More importantly, we now know a lot of unnecessary information about our users, which we really shouldn’t know. After all, now we can understand that User 3 is a “night-owl”, for example. Maybe, just maybe, our data will be hacked. The attacker will also know this info about User 3 and that doesn't sound safe at all.

Well then, let's improve the situation. Let us eschew the use of time and date. Now we will simply send a numerical-value to the server. It will represent the number of times the user has to use our new feature. What is the benefit? Well, now we're not dependent on the Internet. We store less data and do not affect user privacy. Look what happened:

 

This solution already looks much better than the first. But we can still find out that the second user loves our feature the most, and the first one does not like it at all. This is still a privacy breach.

How else could it be remedied?

What if we change the question? Instead of always counting, we will have a number that we need and we will simply compare it with our counter once a day. So, the result will be only a boolean value: true or false. It is more secure and we still have what we want to know.  

For example, if a user has used our new functionality more than 10 times a day, then he/she likes it.

 

Now we will store the same count and reset it once in a while. Along with a reset, we will send our bool value to the server. Only true or false, which represents "like" or "don't like".

Now, even if the attacker intercepts our data or hacks the server, he'll have nothing.

Bingo! Now we no longer know which user loves the feature the most, and which the least. This data is only kept between the device and its owner, as it should be.

If we sum all of this up, what do we realise?

Well, we realise the fact that we often don’t think about how NOT to interfere with user privacy. We do not worry about him/her because it comes down to our needs. We want to do everything in the best possible way. But it is for the sake of this "best possible way" that we need to think about the user. Providing him with the protection and comfort of using the application and his personal data, we help ourselves. At the same time, we help our server too. Sometimes to get what we really wanted, we mistakenly collect too much data, which actually shouldn’t be allowed to be collected at all. A large amount of this data can even be really useless to us.  

Identifying devices and users, analysing, collecting data and maintenance of statistics is, no doubt, needed. Simply because it helps us and our products get better. However, we will not improve if we are dealing with this issue so carelessly. We're harming ourselves every time we don't care about our users. Think about how they would feel if they knew about the ways we use them and their personal info. We need to take care of our users and not exploit them! Just think, if we act in this manner, nothing will prevent other developers from doing the same thing. And hey, we are users as well! As well as our relatives and friends. Someone will get into their or your personal information. Is it really worth it? Think about it.

At the very beginning, we talked about the fact that our goal is to create a good user experience. I think we can safely say that the formula for this goal is very simple:

Now we can say with assurance that the formula for success is very simple:  Users + You + Privacy
 

Hope you have found this article useful, don't forget to leave your comments below the article. If you have a project idea in mind but don't know where to start, we're always here to help you

SEE ALSO: