--Originally published at Bytes of Mind

This time, we are going to be talking about data confidentiality and how it was handled in my STATS project. To give a little recap, there is more to confidentiality than just making data private,rather, it’s about keeping the needed information private, and letting the user know what it needs to know.

On our project we were handling four different types of users: students, teachers, principal and admin, and each had a different level of access to information. First we have the students, who are able to see their average scores based on they perform on the game Mateoro. Then we have teachers, who can see the average score for each student in their class, an average of the whole group and a comparison between students. After that we have the principal, who can see the same information as a teacher but for every group in the school. And finally we have the admin, who can’t see test results, but is able to add new users (with the exception of a principal) to the or edit some of their information (such as name, date of birth, class, etc.). This is deliberately handled such that students can’t compare their scores through our platform, or that teachers can’t measure the progress of classes not related to them.

This ensures that data is confidential between users, but what about the database? Well, once again, this is where the power of encryption comes in. By running our data through an encryption algorithm we can ensure that data can’t be interpreted even if someone can get their hands on it. Thus, we can ensure that the data can reach their respective users while keeping it safe from people looking from the outside or even from the inside, since the data is basically useless without

--Originally published at Bytes of Mind

This time, we are going to be talking about data confidentiality and how it was handled in my STATS project. To give a little recap, there is more to confidentiality than just making data private,rather, it’s about keeping the needed information private, and letting the user know what it needs to know.

On our project we were handling four different types of users: students, teachers, principal and admin, and each had a different level of access to information. First we have the students, who are able to see their average scores based on they perform on the game Mateoro. Then we have teachers, who can see the average score for each student in their class, an average of the whole group and a comparison between students. After that we have the principal, who can see the same information as a teacher but for every group in the school. And finally we have the admin, who can’t see test results, but is able to add new users (with the exception of a principal) to the or edit some of their information (such as name, date of birth, class, etc.). This is deliberately handled such that students can’t compare their scores through our platform, or that teachers can’t measure the progress of classes not related to them.

This ensures that data is confidential between users, but what about the database? Well, once again, this is where the power of encryption comes in. By running our data through an encryption algorithm we can ensure that data can’t be interpreted even if someone can get their hands on it. Thus, we can ensure that the data can reach their respective users while keeping it safe from people looking from the outside or even from the inside, since the data is basically useless without

--Originally published at Bytes of Mind

In my last post I talked a bit about the project I’m working on right now, and a lot of the things I mentioned had to do with data and the way we managed it. I will use this post to continue talking about data, more specifically, keeping it’s integrity.

Let me start by saying that the first thing we did to ensure that our data was complete was to define how the information was going to be stored. We decided on using a non relational database with MongoDB to be able to link and handle our data more freely, but it’s not a silver bullet. Since we are not using SQL, there isn’t really a danger to some data schemes making no sense, but that’s why we had to be careful and make sure every single little piece of data we needed was accounted for in the way it was intended. Even though we didn’t use relational schemas we still had to create our own pseudo-schemas.

But there is more to integrity than defining the way data is going to be handled. The principle of integrity basically states that information only has value if it is correct, in other words, that it hadn’t been tampered with. So what we decided to do about this was to encrypt the data and for things such as the login the encrypted data sent had to be checked against the encrypted data stored checking if it was correct. Other things such as the result of the game were a bit more tricky, since there isn’t anything to compare them to being dynamic data, so integrity of this was kept in line more by the sheer amount of information being generated by the game time and time again, and then running the data through