BackgroundThe recent proliferation of self-tracking technologies has allowed individuals to generate significant quantities of data about their lifestyle. These data can be used to support health interventions and monitor outcomes. However, these data are often stored and processed by vendors who have commercial motivations, and thus, they may not be treated with the sensitivity with which other medical data are treated. As sensors and apps that enable self-tracking continue to become more sophisticated, the privacy implications become more severe in turn. However, methods for systematically identifying privacy issues in such apps are currently lacking.ObjectiveThe objective of our study was to understand how current mass-market apps perform with respect to privacy. We did this by introducing a set of heuristics for evaluating privacy characteristics of self-tracking services.MethodsUsing our heuristics, we conducted an analysis of 64 popular self-tracking services to determine the extent to which the services satisfy various dimensions of privacy. We then used descriptive statistics and statistical models to explore whether any particular categories of an app perform better than others in terms of privacy.ResultsWe found that the majority of services examined failed to provide users with full access to their own data, did not acquire sufficient consent for the use of the data, or inadequately extended controls over disclosures to third parties. Furthermore, the type of app, in terms of the category of data collected, was not a useful predictor of its privacy. However, we found that apps that collected health-related data (eg, exercise and weight) performed worse for privacy than those designed for other types of self-tracking.ConclusionsOur study draws attention to the poor performance of current self-tracking technologies in terms of privacy, motivating the need for standards that can ensure that future self-tracking apps are stronger with respect to upholding users’ privacy. Our heuristic evaluation method supports the retrospective evaluation of privacy in self-tracking apps and can be used as a prescriptive framework to achieve privacy-by-design in future apps.

As the interest in using policy-based

The Internet of Things (IoT) systems are designed and developed either as standalone applications from the ground-up or with the help of IoT middleware platforms. They are designed to support different kinds of scenarios, such as smart homes and smart cities. Thus far, privacy concerns have not been explicitly considered by IoT applications and middleware platforms. This is partly due to the lack of systematic methods for designing privacy that can guide the software development process in IoT. In this paper, we propose a set of guidelines, a privacyby-design framework, that can be used to assess privacy capabilities and gaps of existing IoT applications as well as middleware platforms. We have evaluated two open source IoT middleware platforms, namely OpenIoT and Eclipse SmartHome, to demonstrate how our framework can be used in this way.

As the interest in using policy-based

Adaptive user interfaces (UIs) were introduced to address some of the usability problems that plague many software applications. Model-driven engineering formed the basis for most of the systems targeting the development of such UIs. An overview of these systems is presented and a set of criteria is established to evaluate the strengths and shortcomings of the state-of-the-art, which is categorized under architectures, techniques, and tools. A summary of the evaluation is presented in tables that visually illustrate the fulfillment of each criterion by each system. The evaluation identified several gaps in the existing art and highlighted the areas of promising improvement. The user interface (UI) layer is considered one of the key components of software applications since it connects their end-users to the functionality. Well-engineered and robust software applications could eventually fail to be adopted due to a weak UI layer. Some user interface development techniques such as: universal design [Mace et al. 1990], inclusive design [Keates et al. 2000], and design for all [Stephanidis 1997] promote the concept of making one UI design fit as many people as possible. Yet, a UI is not independent from its context-of-use, which is defined in terms of the user, platform, and environment [Calvary et al. 2003]. The "one design fits all" approach is unable to accommodate all the cases of variability in the context-of-use, in many cases leading to a diminished user experience. Building multiple UIs for the same functionality due to context variability is difficult since the scope of variability cannot be completely known at design-time and there is a high cost incurred by manually developing multiple versions of the UI. Adaptive UIs have been promoted as a solution for context variability due to their ability to automatically adapt to the context-of-use at runtime. User interfaces capable of adapting to their context-of-use are also referred to as multi-context or multi-target [Fonseca 2010]. A key goal behind adaptive UIs is plasticity denoting a UI's ability to preserve its usability across multiple contexts-of-use [Coutaz 2010]. Norcio and Stanley [1989] consider that the idea of an adaptive UI is straightforward since it simply means that: "The interface should adapt to the user; rather than the user adapting to the system" (p. 399) but they note that in spite of the simplicity of the definition, there are some difficult and complex problems relating to adaptive UIs. In our study of the literature, we noticed that some of these problems are technical and are related to devising systems that can support the development of adaptive UIs, while others are related to human factors such as the end-user acceptance of these UIs. Realizing the abstract properties illustrated in Fig. 1, could help in handling some of the technical and human problems related to adaptive UIs. Salehie and Tahvildari [2009] present a hierarchy of adaptability properties for software systems, referred to as self-* properties. This hierarchy demon...