## 7 Discussion
### Ethics Considerations, Stakeholders and Privacy  
This study adds to the growing body of research that indicates that physical safety issues are addressable through technological solutions. The robot itself should be designed to be well visible. Every time the robot courier moves, or is about to move, it should provide some form of feedback to the surrounding people (e.g., lights, sounds, user interface response) [94]. These adjustments will improve the people's interaction with the robot and secure a way to avoid physical damage. At the same time, the robot should be able to avoid collisions itself, either against static obstacles or other people [95]. This can be done in two steps: first, the robot must be equipped with a sufficient number of sensors to be able to detect potential obstacles or other hazards in its surroundings. Then, its control software must implement a set of fail-safes that take over in case the user is driving the robot towardss a potentially dangerous situation. It should be impossible for the user to force the robot to cause harm either to itself or to other people.  
Privacy issues are harder to solve perfectly, but there are lots of precautions one can take to avoid them as much as possible. External privacy issues are largely addressed already in the context of classic teleconferencing software (e.g., videochat). Any data exchanged by the users must be encrypted and authenticated. The owner of the robot, in particular, must know with certainty the identity of the peer. This is closely tied with the internal privacy issues. From a software point of view, the owner of the robot must be able to configure, at a minimum, a set of authorized users. However, not every user might have the same privileges. The configuration possibilities should be extremely fine grained. The owner should be able to control, among other things: who can access the robot, at what times, what capabilities of the robot that he/she can use (camera, movement), where the robot can go, etc. These controls can be implemented in software, but they are not a perfect solution.  
The possibility of unauthorized access is always present. Software security can be circumvented. Having a robot equipped with a camera inside one's own house can be a great security problem if that robot can be accessed by malicious people. Therefore, it is necessary to provide security solutions implemented in hardware. The obvious one is to provide a master switch that effectively cuts off the robot from its power source. This would ensure the owner that nobody, whether they are authorized or not, can use the robot until switched on again. Additionally, the robot should feature finer-grained hardware controls, such as the ability to disable only movement and not the camera.  
With regard to data collected by the robot for its routine operations (e.g., map of the environment), designers of the robot must ensure that this is not accessible from the outside. One possibility is to provide a separate storing device, only accessible by the robot. To avoid unauthorized access, the core code of the robot should be digitally signed and its validity checked (possibly in hardware) every time it is started.  
These potential solutions highlight the underlying trust issue: the owner of a Telepresence robot must, implicitly, trust at least one party (the hardware manufacturer of the robot). The only way to avoid this would be to release publicly the hardware specifications, allowing the users to verify for themselves. Still, there is no guarantee that the robot does in fact implement those specs.