At first sight, data security is a dust-dry topic. It is very theoretical, and even if you visualize its core elements, such as encryption, they don’t really become tangible. But it doesn’t have to be like that. Data security touches our every day lives, and there are measures to show it. During our exchange project in Novosibirsk, we played a management game on data security. It’s one of the best ways to make the advantages and risks of huge databases a concrete experience.

The game was split into two stages. We were around 20 people, divided into groups of four. During the first stage of the game, each group would represent one institution where data are collected, e.g. a supermarket, a library, a gas station, a bank or a registration office. Each participant would also get a list of tasks to fulfill one after another, such as borrowing a book or buying certain items at the supermarket, and a personal ID number. The stations would have forms in which to write down information on their “customers”, such as the ID number and what they bought or borrowed. Thus, several databases were created.

In the second stage of the game, each group would get assigned a job for which to fulfill they needed to use the databases compiled beforehand. Two groups would have to find a job candidate matching a certain profile, two others had to find potential subscribers for a magazine. The fifth group acted as the police, researching a hit-and-run accident.

I got to be in one of the personnel boards. We used the criteria given (e.g. the applicant had to be obedient, incorruptible and sound) and added others, such as intelligence and professional experience. Then we converted these criteria into information we could get from the databases. For professional experience, we assumed a person had to be of a certain age (listed at the registration office), for intelligence we looked at the books they got from the library. We excluded people buying alcohol or pharmaceuticals at the supermarket and those who had a negative balance at the bank.

Through this process, we managed to cut our list down to three people. Using “inofficial” information overheard from the police office, we excluded another person who was a suspect in the hit-and-run case. Finally, we chose one of the two applicants because she had refueled at the gas station, leading us to assume she had a driver’s license, thus being more flexible.

When presenting our findings it turned out the other “personnel board” group had agreed on a different company profile. While we had looked out for people suiting a dislikable chemical corporation, they had explicitly tried to avoid yuppies (by excluding people who had “too much money for their age”). Still, their choice was number two on our list, which means that our (rudimental) algorithms worked relatively similar. The two groups researching potential customers for a magazine on the other hand did not have any overlap on their top three spots.

Still, the findings of the “police” group were the most interesting ones. The group had summoned three people they alleged to be possible perpetrators, but all denied to have committed the crime. The real offender was not found, data mining thus failed in this case.

The group had assumed that the perpetrator had to have left traces in connection with the scooter involved in the accident. Subsequently, they had collected information from library, supermarket and gas station: People who had borrowed books on repairing scooters, bought tools or filled up on a certain kind of fuel used by scooters. People who had borrowed relevant books and stocked up on tools where thus most suspicious. But when interviewed about their errands, the suspects declared to have gotten books and tools for their brothers.

The “police” group had in fact missed one important source of information. At the registration office, addresses of all participants were listed. Using a map on the wall, the investigators could have matched this data with the site of the crime, by this means compiling a list of people living close to it. Together with data from the other institutions, this would have led them to the actual perpetrator.

This management game makes data security a real experience for all participants. It becomes clear that data are not self-explanatory, and that misinterpretation is a huge risk. Of course the game very much simplifies the actual situation. E.g., different rights of access to data sources for different institutions did not play a role, nor did data accuracy. Still it is a good introduction into the issue and a good way to attract awareness for the issue.

After my experience with the management game method in Novosibirsk, I would like to use it in a Privacy Workshop. Participants need to be able to work independently to a certain degree, therefore I would recommend it for students of higher grades only. On the other hand, this approach might also appeal to participants who are less computer-savvy.

(Crossposted from the Privacy Workshop Project blog)

At first sight, data security is a dust-dry topic. It is very theoretical, and even if you visualize its core elements, such as encryption, they don't really become tangible. But it doesn't have to be like that. Data security touches our every day lives, and there are measures to show it. During our exchange project in Novosibirsk, we played a management game on data security. It's one of the best ways to make the advantages and risks of huge databases a concrete experience. The game was split into two stages. We were around 20 people, divided into groups of four. During the first stage of the game, each group would represent one institution where data are collected, e.g. a supermarket, a library, a gas station, a bank or a registration office. Each participant would also get a list of tasks to fulfill one after another, such as borrowing a book or buying certain items at the supermarket, and a personal ID number. The stations would have forms in which to write down information on their "customers", such as the ID number and what they bought or borrowed. Thus, several databases were created. In the second stage of the game, each group would get assigned a job for which to fulfill they needed to use the databases compiled beforehand. Two groups would have to find a job candidate matching a certain profile, two others had to find potential subscribers for a magazine. The fifth group acted as the police, researching a hit-and-run accident. I got to be in one of the personnel boards. We used the criteria given (e.g. the applicant had to be obedient, incorruptible and sound) and added others, such as intelligence and professional experience. Then we converted these criteria into information we could get from the databases. For professional experience, we assumed a person had to be of a certain age (listed at the registration office), for intelligence we looked at the books they got from the library. We excluded people buying alcohol or pharmaceuticals at the supermarket and those who had a negative balance at the bank. Through this process, we managed to cut our list down to three people. Using "inofficial" information overheard from the police office, we excluded another person who was a suspect in the hit-and-run case. Finally, we chose one of the two applicants because she had refueled at the gas station, leading us to assume she had a driver's license, thus being more flexible. When presenting our findings it turned out the other "personnel board" group had agreed on a different company profile. While we had looked out for people suiting a dislikable chemical corporation, they had explicitly tried to avoid yuppies (by excluding people who had "too much money for their age"). Still, their choice was number two on our list, which means that our (rudimental) algorithms worked relatively similar. The two groups researching potential customers for a magazine on the other hand did not have any overlap on their top three spots. Still, the findings of the "police" group were the most interesting ones. The group had summoned three people they alleged to be possible perpetrators, but all denied to have committed the crime. The real offender was not found, data mining thus failed in this case. The group had assumed that the perpetrator had to have left traces in connection with the scooter involved in the accident. Subsequently, they had collected information from library, supermarket and gas station: People who had borrowed books on repairing scooters, bought tools or filled up on a certain kind of fuel used by scooters. People who had borrowed relevant books and stocked up on tools where thus most suspicious. But when interviewed about their errands, the suspects declared to have gotten books and tools for their brothers. The "police" group had in fact missed one important source of information. At the registration office, addresses of all participants were listed. Using a map on the wall, the investigators could have matched this data with the site of the crime, by this means compiling a list of people living close to it. Together with data from the other institutions, this would have led them to the actual perpetrator. This management game makes data security a real experience for all participants. It becomes clear that data are not self-explanatory, and that misinterpretation is a huge risk. Of course the game very much simplifies the actual situation. E.g., different rights of access to data sources for different institutions did not play a role, nor did data accuracy. Still it is a good introduction into the issue and a good way to attract awareness for the issue. After my experience with the management game method in Novosibirsk, I would like to use it in a Privacy Workshop. Participants need to be able to work independently to a certain degree, therefore I would recommend it for students of higher grades only. On the other hand, this approach might also appeal to participants who are less computer-savvy. (Crossposted from the Privacy Workshop Project blog)