While I haven’t been mentioning it much in my previous posts due to the fact that I myself was not involved with the system, the New Intelligence App uses Unity’s analytics system to send data to a server for… well… analytic purposes.
However, sending data, even analytic data, comes with risk. What information is being exposed? Is it personal data? How often is it being sent? These are all serious concerns that could potentially have serious consequences. I’m going to take a look at the Ashley Madison data leaks that occurred in 2015 and see what the consequences of it were.
For those who don’t know, Ashley Madison is a dating website specifically targeting people who are married and looking to get the hanky panky with other married peopel. As you can imagine, this stirred some criticism, with Trish McDermott, a co-founder of Match.com, describing the site as a “business built on the back of broken hearts, ruined marriages, and damaged families”. Ashley Madison also gained unwanted attention when it was revealed that Ashley Madison would create fake websites dedicated to criticising and verifying dating services, and then creating false testimonies that Ashley Madison was legitimate.
All in all, their business practices were shady at best, and unethical at worst. So it shouldn’t surprise anyone that they could be a target for data attacks. If you want to follow a timeline of the Ashley Madison hacks, go here.
On July 12th, 2015, the company Avid Life, the parent firm of Ashley Madison, found a message from a group known as Impact Team. They claimed that they had all their database information, including that of the company and all their clients, and that they would release the information if Ashley Madison and its sibling website Established Men, were shut down. Ashley Maddison promised a 100% discreet service gaurentee as displayed on the picture above. However, they apparently did not delete the data of their users unless they paid a $19 fee to do so. With such a large number of potentially leaked users, would Avid Life play the side of caution? Short answer, no. Avid Life did not shut down their sites, and on August 18th, Impact Team released the information of up to 30 million users on the Tor network. Totalling to 10gb of data, it included email addresses, physical addresses, credit card numbers, sexual preferences, and even physical details such as height and weight of all their users.
However, many of the 30 million users might not have existed as people. The website did not require email authentication to continue to the website and its functions, and there was many instances of peoples emails being used maliciously to try and frame them. Former Prime Minister of England can be seen on the list as well as many other government employees and politicians around the world. According to Gizmodo, only 12,000 of the 5.5 million registered females on the sight would use the sight on a regular basis. In addition, women rarely checked their email messages, with reportedly one woman checking their messages for every 13 THOUSAND men.
While its possible that Tony Blair could have signed up for the site, I highly doubt he used his Labour party email to engage in extramarital affairs.
![CMuLFyeUcAAGE8w[1]](https://calebbarton.dev/wp-content/uploads/2017/05/cmulfyeucaage8w1.jpg?w=490)
Now then, I suppose you’re asking, how does this in ANY way relate to a serious app related to interview techniques? The answer is at the top of this page. We’re collecting and storing data on our users. Lets examine the information we send off to our analytic server to see what we can make more secure.
1.) Anonymous ID
As we’re using analytics, we need some way of identifying each set of data from the other. We need some method of identifying the user so we can see how often they access the app and how long. We discussed requiring a google account to log into the app at the beginning of development, with the idea that we could save and upload the profile data to googles cloud service. We however decided not to do this as this was too much overhead for the data we wanted.
As Android OS creates an ID for an app every time the user installs one, we decided to utilise this ID to identify users. This ID would be consistent for every playthrough the user did, except if they re-installed the app. We decided that this was an acceptable tradeoff, as we’re still getting the same data.
2.) Android Phone Model
As a part of the analytics, we collect what phones are being used primarily to see if there’s performance problems on older phones. While we aren’t sending any data relating to the app performance, if enough models of a Galaxy S2 (for example) have very short connection times, we can start looking at testing and optimising for that model.

3.) Game Specific Data
This one is fairly straightforward, as we’re simply sending how quickly people took to complete a question, how many they got right and wrong, what question was it, what skill it was increasing … etc.
So now that we’ve looked at the data, and determined what we’re sending, we can tell users what we’re sending and why.
Using this as a base for creating the statement, I’ve created a privacy statement for the NI App for those using it.
