MECS handbook

From Robin

Revision as of 13:28, 5 October 2017 by Trentonw (Talk | contribs)
Jump to: navigation, search


The MECS Handbook


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.

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.

The shared area on Bifrost

Bifrost is a file server run by IFI-drift. It is available as a standard network share on Windows and MacOS. Access outside of UiO should via VPN, Remote Desktop or via secure shell (ssh). We'll cover the access methods and then the general layout of the bifrost area. Unfortunately, outside the network also means that eduroam doesn't work either.

Paths to access Bifrost

The URL to access bifrost is


on Windows or


On MacOS or other Unix-like operating systems.

If you are logged into via ssh, you can also access the project area using the path:


or it's full path:


Enterprising people who can access via ssh can also access it via sshfs, but that is left as an exercise to the reader.

Read and write permissions on Bifrost

By default, everyone at IFI has read access to this area! That is, anyone who has a IFI-login could see what's in the path. This was an intentional decision. So, work with a rule of thumb that anything you put in this drive area could be seen by any of your colleagues at IFI.

If you want write access to the files, you have need to belong to the ifi-mecs group. Contact Trenton to be added. This can usually be sorted within the day.


UiO offers a service for sensitive data (tjenester for sensitivdata or TSD). We store all our personal data about people in TSD.

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 [|{(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 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 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.

This data needs to be protected at a higher level. We choose the TSD because it gives us a known level of security without us having to maintain everything ourselves. It is straight-forward to use.

Should something be in TSD or not?

The simple rule of thumb of if something should be in the TSD or not is if it involves people who are informants or participating in the project, but are not officially part of the project (i.e., they aren't listed as the project partners). If you collect information from participants, especially if it's pictures, contact information, or recordings. It should go on the TSD.

Getting access to TSD

MECS’s project ID is: p260.

Access to TSD is controlled. For MECS the project's TSD administrator is Trenton. Contact him and he will authorize you. Once you have been authorized, you need to | register to become a user on TSD. You'll need access to your minID account for a digital signature and the project ID (above).

Using TSD

There is already a | TSD user guide written by the university. It's not the most exciting read, but it works well if you follow it closely. This section is mostly for notes that we have found while using TSD during the project.

Import/export of data for advanced users
The information provided by TSD is fine, but if you know how to use | GPG you can use the project's public key to encrypt data before it is sent to or from the server.
Personal tools