Search

Context: Programmers frequently look for the code of previously solved problems that they can adapt for their own problem. Despite existing example code on the web, on sites like Stack Overflow, cryptographic Application Programming Interfaces (APIs) are co monly misused. There is little known about what makes examples helpful for developers in using crypto APIs. Analogical problem solving is a psychological theory that investigates how people use known solutions to solve new problems. There is evidence that the capacity to reason and solve novel problems a.k.a Fluid Intelligence (Gf ) and structurally and procedurally similar solutions support problem solving. Aim: Our goal is to understand whether similarity and Gf also have an effect in the context of using cryptographic APIs with the help of code examples. Method: We conducted a controlled experiment with 76 student participants developing with or without procedurally similar examples, one of two Java crypto libraries and measured the Gf of the participants as well as the effect on usability (effectiveness, efficiency, satisfaction) and security bugs. Results: We observed a strong effect of code examples with a high procedural similarity on all dependent variables. Fluid intelligence Gf had no effect. It also made no difference which library the participants used. Conclusions: Example code must be more highly similar to a concrete solution, not very abstract and generic to have a positive effect in a development task., Comment: 2 pages

As Smart Devices have access to a lot of user-preferential data, they come in handy in any situation. Although such data—as well as the knowledge which can be derived from it—is highly beneficial as apps are able to adapt their services appropriate to the respective context, it also poses a privacy threat. Thus, a lot of research work is done regarding privacy. Yet, all approaches obfuscate certain attributes which has a negative impact on context recognition and thus service quality. Therefore, we introduce a novel access control mechanism called PATRON. The basic idea is to control access to information patterns. For instance, a person suffering from diabetes might not want to reveal his or her unhealthy eating habit, which can be derived from the pattern “rising blood sugar level” “adding bread units”. Such a pattern which must not be discoverable by some parties (e. g., insurance companies) is called private pattern whereas a pattern which improves an app's service quality is labeled as public pattern. PATRON employs different techniques to conceal private patterns and, in case of available alternatives, selects the one with the least negative impact on service quality, such that the recognition of public patterns is supported as good as possible.

Applications for the Internet of Things are becoming increasingly popular. Due to the large amount of available context data, such applications can be used effectively in many domains. By interlinking these data and analyzing them, it is possible to gather a lot of knowledge about a user. Therefore, these applications pose a threat to privacy. In this paper, we illustrate this threat by looking at a real-world application scenario. Current state of the art focuses on privacy mechanisms either for Smart Things or for big data processing systems. However, our studies show that for a comprehensive privacy protection a holistic view on these applications is required. Therefore, we describe how to combine two promising privacy approaches from both categories, namely AVARE and PATRON. Evaluation results confirm the thereby achieved synergy effects.

Context: System Theoretic Process Analysis for Privacy (STPA-Priv) is a novel privacy risk elicitation method using a top down approach. It has not gotten very much attention but may offer a convenient structured approach and generation of additional artifacts compared to other methods. Aim: The aim of this exploratory study is to find out what benefits the privacy risk elicitation method STPA-Priv has and to explain how the method can be used. Method: Therefore we apply STPA-Priv to a real world health scenario that involves a smart glucose measurement device used by children. Different kinds of data from the smart device including location data should be shared with the parents, physicians, and urban planners. This makes it a sociotechnical system that offers adequate and complex privacy risks to be found. Results: We find out that STPA-Priv is a structured method for privacy analysis and finds complex privacy risks. The method is supported by a tool called XSTAMPP which makes the analysis and its results more profound. Additionally, we learn that an iterative application of the steps might be necessary to find more privacy risks when more information about the system is available later. Conclusions: STPA-Priv helps to identify complex privacy risks that are derived from sociotechnical interactions in a system. It also outputs privacy constraints that are to be enforced by the system to ensure privacy., Comment: author's post-print