MECS handbook

Fra Robin

Revisjon per 5. okt 2017 kl. 12:38 av Trentonw (Diskusjon | bidrag)
Gå til: navigasjon, søk

Innhold

The MECS Handbook

Introduction

This handbook should provide the basics to getting started in working with MECS. The idea is to put everything here that we feel a new person needs to know when they start the project. If there is something here that is missing, please add it.

Conventions used

To provide some consistency, we try to use the following convertions.

Items that are terms will be presented in italics.

Items on the command-line will be shown in their own environment (as shown below). Commands to be entered by a normal user will start with a dollar sign ($). The hash mark (#) will indicate if the command needs to be run as an administrator.

$ A command. 
$ Another command.
# Command needed to be run by an administrator (or root)

For items that can only be done via the a GUI, we will try to lead the way with figures.

Handbook overview

This handbook does not need to be read in a particular order. This is a quick summary of the different chapters, so you know where to look for things.


Introduction
What you are reading right now.
About MECS
A short summary of the ◊|mecs| project and what we are working on.
Sharing Data
This chapter describes how we access the different data and information about how to access it, including the holes.
Logo use
Information on logo use.

About MECS

Some information about the MECS project goes here. The idea is to let everyone have a consistent message about the project. This is in favor of having to always think it up on the spot.

Sharing Data

Since the MECS project spans multiple informatics groups, we have tried to consolidate storage. The current locations are:

  • The shared area on Bifrost
  • TSD

We’ll document the current layout so that people can navigate and find data. Some data may be restricted depending on how the person is involved in the project.

But before we look at these items, let’s take a quick look at personal data and how we can best protect it.

Personal Data & Sensitive Personal Data

Since MECS involves research on people, it necessarily will be collecting personal data about these people. Depending on the activities that we do, we may also end up collecting sensitive personal information.

What is personal data? There is good information about personal data from the Data Directorate [https://www.datatilsynet.no/om-personvern/personopplysninger/|{(in Norwegian)]. Personal data is data that can identify a person and includes information like:

  • name
  • birth date
  • contact information
  • picture
  • behavior patterns

Sensitive personal information includes things like a person's race, ethnicity background, health or disabilities, political, relegious, or philiophical opinions, sexual relationships, and membership in unions. This needs to be protected at a higher level.

Regardless of whether the personal data is sensitive or not, we need to be good about keeping the personal data safe so that people can trust us with ◊emph{their} data. One doesn't have to | look far to find data about people can be stolen. Ideally, we should avoid being one of those stories.

Why can we have access to and use personal data?

Research projects don't automatically get access to this data. Any project that collects data from people needs to be registered with the Directorate (Datatilsynet). While we can do that directly, it requires some administration work that is more work than an average researcher wants. Instutions like UiO have a privacy vernombud whose job is do the registration and maintain dialogue with the Data Directorate. For UiO, that means using the Center for Research Data (Norsk senter for forskningsdata) or simply NSD for short.

At the start of the project, we created an application that we sent to the NSD. This included information about what kind of data we plan to collect, what activities we will do to collect it, how we inform people about this collection, where we store the data, how long we will keep the data, and what happens to the data at the end of the project. In addition, we needed to include samples of our informed consent form and the interview guides we were using. The application along with their response is included on ◊xref[#:to-id "bifrost-files"]{bifrost}. In general, as long as we follow what we've reported in the application, we can collect the data. If we need to do something different, that's fine, but we need to send a request for change to the NSD and it takes some time for it to be approved.

Now that we have an idea about what sensitive data is and how we take care of it here in the project. Let's look at how we can handle the data.

Guidelines for handling personal data

This is not an exhaustive list, but it should give you a basic idea about what things to consider when working with personal data. Some of these things make life more difficult for us, but it's better for the people's data. Consider if the situation was different, how would you like your personal data leaked by a researcher (even if the researcher meant well).

Guidelines are always just that, guidelines. You may run into a situation where following this practice will make the data vulnerable, or you have to make the best of a bad situation. The important thing is that you consider the different issues and the need of keeping the data safe.

Keep unencrypted data off the Internet

This may be obvious, but the personal data should not go over the Internet. Data that goes over the Internet can be copied. If it's unencrypted, it can be readily used by others. If you must send the data over the Interent, please encrypt the data.

To make this easier, minimize storing data on devices that will automatically upload data. For example, many phones are automatically set up to upload pictures and films that are taken on the phone or stored on the phone. This functionality is also set up on laptops. Since the upload is automatic, you may not notice it until data is already uploaded, making it difficult to remove. This can make it difficult to simply look at something without it being uploaded behind your back. If you must do this, consider disconnecting from the Internet completely.

Using a recording device that doesn't have an Internet connection eliminates this issues when the data is at rest or the device is being used.

Sending unencrypted data via email is also a bad idea. You can think of email messages as text written on the back of postcards. Anyone who wants to can read it. Though it might be OK between ◊|uio| addresses, since it would likely stay on the same server, you don't know where the data goes afterwards (e.g., onto a machine that automatically uploads pictures). Just don't send unencrypted data.

Encrypt your data

Encryption is a way of making sure that data is safer. Encryption scrambles the data so that it unreadable except for people that know how to decrypt the data. Usually this requires some sort of knowlegde, a key, or both. Encrypted data can also be used as a way of ◊emph{permantly deleting data}, especially in a cloud environment where you have no idea how many copies of your data exist. If the key to decrypt data is destroyed, there is no realistic way to decrypt the data. So, encrypting personal data will make it safe from being casually read by anyone.

Unfortunately, | encryption is hard. First, because of the concepts that are involved. Second, because of the quality of the tools for encryption. We have tools available in the TSD section that make things easier, but it is far from perfect.

Personlige verktøy