Lab Safety Software Safety

In the everyday life of a scientist in the lab safety is the most important issue. Lab safety has two different aspects. It encompasses the steps and precautions necessary to only protect oneself from any potential hazard, but also to prevent undesired release of engineered (and potentially harmful) organisms or chemical reagents in the environment. Especially the latter point is often addressed in discussions about genetic engineering and synthetic biology. The anxiety of those who do not deal with genetically modified organisms often stems from biosafety issues. Here we want to shed light upon the daily handling and precautions that biologists take to prevent danger that can arise from the mishandling of biological material. Since distributed computation plays a major role in our project, we would like to discuss here also “software safety”.

In both safety areas, we actively searched communication with safety advisors and eventually put useful approaches into practice. We used all the received advice to shape our projects and think about precautions that are crucial to fulfill the claims of biosafety.

Here you can find our Safety form!

Lab Safety

At the beginning of our project, we were given the safety introduction by the responsible safety coordinator Dr. Nicole Metzendorf, who explained to us how to work in the lab and how to apply good laboratory practice. By observing personal safety precautions, such as wearing a lab coat and gloves when working on the bench, or wearing safety goggles when using dangerous chemicals, we protect ourselves from the daily hazards in the lab.

To prevent contamination within the lab, we devised separated workspaces for running gels with ethidium bromide, and an area to work with genetically modified organisms. To protect ourselves from exposure to toxic fumes, chemicals were only used under the fume hood. The documentation of the daily lab work was done only on the desks, were no biological or chemical material is allowed.

In addition to the general lab safety, we talked to the safety advisor on our campus, Dr. Willi Siller, with whom we double-checked the feasibility of the project concerning its safety. Together we examined the donor- and chassis- organisms that we are using for our project and ranked them in their biosafety level. Fortunately, all bacteria strains that we use in the lab were classified as safety level 1, meaning that our bacteria are not harmful.

Indeed, the bacterial species used in our experiments - several E. coli strains, Bacillus subtillis and Micrococcus lysodeikticus – are categorized as safety level 1 (S1) (link). The cell line HEK293T, a human kidney cell line used for phototoxicity is also at safety level 1. Even though none of the organisms we are working with cause any threat to the environment, we were careful in handling them, always wearing the proper protection and disinfecting and autoclaving anything which got in contact with living organisms, or discarded it in the S1-waste. These steps assure containment of any bioactive material within the lab and prevent contamination of the environment.

To reduce anxiety in society about synthetic biology, it is of major concern to discuss the issue of biosafety with the public and elucidate which precautions and regulations are practiced in the lab. Therefore this issue was broadly discussed in our theme night “Synthetic Biology, Religion and Ethics”, during which, once again, it became clear that genetically modified organisms and their release in the environment are delicate issues among non-scientists.

Software Safety

One essential part of our project is computational, using not only our own PCs, but computers around the world via distributed computing. By providing their PCs, our users trust us not to provide them with any malware or virus, as well as not spying on their private data. To guarantee the safety of our users’ PC, we used a security mechanism called code signing. The BOINC software will only run software code, which is signed by the correct certificate. Essentially, code signing is based on two unique keys, a public and a private key. The private key is kept on a PC or Medium, in our case on a CD, with no access to the Internet, to keep it secure. Whenever there is an update on software code, you need the private key to generate a new certificate. The end user receives the new certificate, and using the public key, compares the check sum from the software code and the certificate. The program can only be executed, when this matching is successful. Since the public key cannot be used to alter the code itself, this system assures that the BOINC client only runs software created by the developer. This solution was discussed with some of the developers of BOINC itself and was deemed sufficient to allow us to have our software sponsored on their official webpage.

Despite all our efforts to ensure the safety of our software, we noticed that the numbers of visitors of our iGEM@home page largely exceeded the number of those effectively downloading the program to calculate linkers on their computers. We interpret this as a clear sign of fear and suspicion and, while we discussed a lot about what more we could do to tempt people to download the program and trust us, we could not find any better idea and realized that it is almost impossible to guarantee software safety at 100% and that very often it is a matter of trust towards those who realize a piece of software.