Suchergebnisse

Following GDPR's Article12.7's proposal to use standardized icons to inform data subject in "an easily visible, intelligible and clearly legible manner," several icon sets have been developed. In this paper, we firstly critically review some of those proposals. We then examine the properties that icons and icon sets should arguably fulfill according to Art.12's transparency provisions. Lastly, we discuss metrics and evaluation procedures to measure compliance with the Article.

Lately, icons have witnessed a growing wave of interest in the view of enhancing transparency and clarity of data processing practices in mandated disclosures. Although benefits in terms of comprehensibility, noticeability, navigability of the information and user's attention and memorization can be expected, they should also be supported by decisive empirical evidence about the efficacy of the icons in specific contexts. Misrepresentation, oversimplification, and improper salience of certain aspects over others are omnipresent risks that can drive data subjects to wrong conclusions. Cross-domain and international standardization of visual means also poses a serious challenge: if on the one hand developing standards is necessary to ensure widespread recognition and comprehension, each domain and application presents unique features that can be hardly established, and imposed, in a top-down manner. This article critically discusses the above issues and identifies relevant open questions for scientific research. It also provides concrete examples and practical suggestions for researchers and practitioners that aim to implement transparency-enhancing icons in the spirit of the General Data Protection Regulation (GDPR).

Oftentimes information disclosures describing personal data-gathering research activities are so poorly designed that participants fail to be informed and blindly agree to the terms, without grasping the rights they can exercise and the risks derived from their cooperation. To respond to the challenge, this article presents a series of operational strategies for transparent communication in line with legal-ethical requirements. These "transparency-enhancing design patterns" can be implemented by data controllers/researchers to maximize the clarity, navigability, and noticeability of the information provided and ultimately empower data subjects/research subjects to appreciate and determine the permissible use of their data.

The increasing demand of reliable software services and the dependability that our daily personal and professional life have on them is bringing significant changes in the domain of software service engineering. One of the most revolutionary is the introduction of regulations, repeating what in the past has concerned the product market. Regulations need to find a balance between the interests of several roles and reduce the inevitable tensions that would otherwise arise among them, as well as to defend the right of the weakest parties (normally the end users). There are multiple interests to balance: the interests of end users, the protection of intellectual property, a fair competition against other enterprises, just to name a few. While some of these requirements concern the structure and organization of the enterprise, some of them are fit to penetrate into the software development life cycle. This would serve multiple purposes: allow the enterprise to design services which already take the legal requirements into account; visually represent the requirements and their interaction with the functionality of the system; develop the software components using tools and methodologies that are able to deal with those requirements; define metrics to measure the degree to which such requirements are met; measure the impact of the requirements on the functionality of the service and on other parameters of the service (such as performance or storage occupation); verify and monitor whether the legal requirements are met; and, last but not least, to have an argument to be used in case of a complaint in a court or at a competent authority. Before being considered in the software service life cycle, legal requirements must undergo a preprocessing phase in which they are translated into some form which is compatible with the tools and methodologies proper of the software engineering, for instance being modelled into a formalism that makes them processable by a machine. There is a significant amount of interdisciplinary topics that need to be combined together to reach an integration between regulation and software life cycle. In particular, at least from three complementary perspectives are needed. One perspective requires the analysis of the provisions of the law, the extraction of the legal requirements classified according to the stakeholders affected, and the translation of those requirements into some formal model that can be processed using appropriate software tools. A second perspective requires a study of the legal requirements from the point of view of requirements engineering techniques, also defining metrics to measure them. The third concerns the models used in the various stages of software engineering (design, modeling, development, validation and testing), which need to be extended to accommodate the legal requirements in their formal representation. Only by putting together these perspectives a comprehensive approach to deal with legal requirements in software engineering is possible.

The modelling of a legal text into a machine-processable form, such as a list of logic formulæ, enables a semi-automatic reasoning about legal compliance but might entail some anticipation of legal interpretation in the modelling. The formulæ need therefore to be validated by legal experts, but it is unlikely that they are familiar with the formalism used. This calls for an interdisciplinary validation methodology to ensure that the model is legally coherent with the text it aims to represent but that could also close the communication gap between formal modellers and legal evaluators. This paper discusses such a methodology, providing an human-readable representation that preserves the formulæ's meaning but that presents them in a way that is usable by non-experts. We exemplify the methodology on a use case where Articles of the GDPR are translated in the Reified I/O logic encoded in LegalRuleML.

Lately, researchers, journalists, and regulators are devoting attention to dark patterns, defined as "design choices that benefit an online service by coercing, steering or deceiving users into making decisions that, if fully informed and capable of selecting alternatives, they would not make". Those patterns that have the purpose" or the "substantial effect of obscuring, subverting, or impairing user autonomy, decision-making, or choice" have also been qualified as dark. These definitions are dense: they contain concepts like coercion, nudging, and deception that all alone would deserve an entire work to be discussed.