The proliferation of AI conversation platforms has introduced unprecedented privacy risks through user-shared conversations. This paper presents a comprehensive analysis of privacy vulnerabilities in shared conversations across three major LLM platforms: ChatGPT, Microsoft Copilot, and Google Gemini. We collected and analyzed 100 342 conversations using an automated LLM-based privacy detection pipeline enhanced with a defined risk scoring system and the LINDDUN threat modeling framework. Our analysis identifies 8 131 conversations (8%) to incur privacy risks deriving from the disclosure of private and sensitive data including user identifiers (49%) and user location data (40%), yet in some cases also financial (4%), health (3%) and authentication data such as access tokens (3%). Through systematic analysis of conversation length and temporal disclosure patterns, we demonstrate that extended conversations exhibit higher privacy risk rates compared to brief interactions. Notably, 60% of private data disclosures in longer con- versation occur in the final quartile of these conversations, which may indicate that users progressively lose privacy awareness as interactions deepen. Our findings have immediate implications for platform designers and policymakers, highlighting the need for proactive interventions including real-time privacy warnings, pre- share scanning, and clearer education about the permanence and discoverability of shared conversation links.

Threat modeling involves the early identification, prioritization and mitigation of relevant threats and risks, during the design and conceptualization stages of the software development life-cycle. Tree-based analysis is a structured risk analysis technique that starts from the articulation of possible negative outcomes and then systematically refines these into sub-goals, events or intermediate steps that contribute to this outcome becoming reality. While tree-based analysis techniques are widely adopted in the area of safety (fault tree analysis) or in cybersecurity (attack trees), this type of risk analysis approach is lacking in the area of privacy.To alleviate this, we present privacy impact tree analysis (PITA), a novel tree-based approach for privacy threat modeling. Instead of starting from safety hazards or attacker goals, PITA starts from listing the potential privacy impacts of the system under design, i.e., specific scenarios in which the system creates or contributes to specific privacy harms. To accommodate this, PITA provides a taxonomy, distinguishing between privacy impact types that pertain (i) data subject identity, (ii) data subject treatment, (iii) data subject control and (iv) treatment of personal data. In addition, a pragmatic methodology is presented that leverages both the hierarchical nature of the tree structures and the early ranking of impacts to focus the privacy engineering efforts. Finally, building upon the privacy impact notion as captured in the privacy impact trees, we provide a refinement of the foundational concept of the overall or aggregated ‘privacy footprint’ of a system.The approach is demonstrated and validated in three complex and contemporary real-world applications, through which we highlight the added value of this tree-based privacy threat analysis approach that refocuses on privacy harms and impacts.

ERATOSTHENES is an EC, co-funded, research project strongly considering modern security challenges in the domain of Internet of Things in mind of their huge penetration into our day to day lives. There are a series of recent challenges that recently have been converted into obstacles or risk points that could block the secure operation of IoT networks in all day to day activities, from home to office, to leisure and security. These include examples such as the highly increased number of connected devices (at all network levels) that are on top forming inhomogeneous networks and systems of systems. Different vendor characteristics further increase the attack surface that is expected to further rise in the upcoming years. Such, highly critical, characteristics, dramatically increase the needs for confidentiality access control, user and things’ privacy, devices’ trustworthiness and compliance that require lifecycle considerations. The ERATOSTHENES project orchestrates a novel distributed, automated, auditable, yet privacy-respectful, Trust and Identity Management Framework and Reference Architecture with the ultimate scope to dynamically and holistically manage IoT devices in a lifecycle approach, strengthening trust, identities, and resilience in the entire IoT ecosystem while supporting the enforcement of the NIS directive, GDPR and Cybersecurity Act. This publication describes the ERATOSTHENES technical concept and reference architecture as well as design considerations, architecture characteristics, connectivity and interoperability.

NoSQL technology provides specialized solutions for specific data models and is as such often combined in polyglot persistence implementations. The technological heterogeneity in monitoring APIs and inspection capabilities complicates the management of such storage architectures, and this is further exacerbated by their distributed deployment. More specifically, (i) the use of a combination, e.g., in a multi-cloud context, requires extensive knowledge of these technologies and their APIs, which results in increased application complexity and further leads to technology or vendor lock-in, and (ii) relying solely on a generalistic approach for monitoring different databases falls short in providing in-depth inspection of an individual database.In this paper, we present MonitDB, a uniform API that uses a hybrid approach (a combination of both generalistic and specialistic) for monitoring different types of databases. The approach adopted by MonitDB covers a broad range of databases in terms of a set of common monitoring metrics and also gives more detailed visibility and insights into key metrics for each specific database. At its core, MonitDB is (i) extensible both in terms of new database technologies and monitoring metrics, (ii) configurable (through policies) in scheduling specific monitoring metrics from each of the supported databases, and (iii) customizable in terms of the type of data monitored (i.e. monitoring metrics) and also a performance by simply changing parameters, and as such without storing the measurements in the underlying database of MonitDB.We have validated MonitDB in a working prototype implementation and conducted an extensive evaluation, the results of which confirm the extensibility and configurability benefits, which are achieved with an acceptable performance overhead (around 1% for insert and 9% for read operations).

Multi-tenant Software-as-a-Service (SaaS) providers allow tenants to customize the application at different levels. When the customization involves tenant custom code and a single application instance is shared among multiple tenants, the issue of tenant isolation becomes critical. In common practice, tenant isolation, which amounts to protection of tenants against any interference and disturbance from each other, is performed by isolating tenant custom code in either a dedicated Virtual Machine (VM) or a dedicated container.

Multi-cloud storage is the practice of composing the data tier of an application with heterogeneous cloud storage technologies, resources and services. In a federated cloud storage architecture which involves multiple cloud storage providers, both the complexity and the importance of trust management increases drastically. A trust relation is established between a data owner and a cloud storage provider when the data owner subscribes to the service and service level agreements (SLAs) are established. In practice, this trust relation is seldom revised, only when serious infractions are discovered and made public. In this paper, we evaluate the potential of continuous and client-centric trust monitoring of cloud storage services. This approach leverages upon the statistical correlations between black-box performance metrics and reported white-box metrics, and identifies significant deviations between both. We evaluate in terms of (a) the effectiveness of correlating black-box and white-box measurements, and (b) the incurred performance overhead of the approach to continuously monitor for trust.

Data Protection by Design (DPbD) is a truly interdisciplinary effort that involves many stakeholders such as legal experts, requirements engineers, software architects, developers, and system operators. Building software-intensive systems that respect the fundamental rights to privacy and data protection is the result of intensive dialogue and careful trade-off decisions. In practice however, there is a dichotomy between the legal reasoning which is conducted in Data Protection Impact Assessments (DPIA) and software engineering approaches, such as threat modeling, aimed at identifying privacy requirements and privacy risks. These activities are commonly performed in total isolation, which negatively impacts (i) the compliance exercise, (ii) the ability to evolve the system over time, and (iii) the architectural trade-offs made during system design. In this article, we present an architectural viewpoint for describing software architectures from a legal, data protection perspective whose core modeling abstractions are based on an in-depth legal analysis of the EU General Data Protection Regulation. This viewpoint is tied to Data Flow Diagrams-commonly used in threat modeling-through correspondence rules. The proposed viewpoint supports the automation of a number of data protection impact assessment steps through (i) meta-model constraints, (ii) model analysis, and (iii) interaction with the involved stakeholders. This enables a streamlined compliance exercise, reconciling legal privacy and data protection notions with architecture-driven software engineering practices. We validate our approach in the context of a realistic e-health application for a number of complementary development scenarios.

De-identification is the process of removing the associations between data and identifying elements of individual data subjects. Its main purpose is to allow use of data while preserving the privacy of individual data subjects. It is thus an enabler for compliance with legal regulations such as the EU’s General Data Protection Regulation. While many de-identification methods exist, the required knowledge regarding technical implications of different de-identification methods is largely missing. In this paper, we present a data utility-driven benchmark for different de-identification methods. The proposed solution systematically compares de-identification methods while considering their nature, context and de-identified data set goal in order to provide a combination of methods that satisfies privacy requirements while minimizing losses of data utility. The benchmark is validated in a prototype implementation which is applied to a real life data set.

Container orchestration systems, such as Docker Swarm, Kubernetes and Mesos, provide automated support for deployment and management of distributed applications as sets of containers. While these systems were initially designed for running load-balanced stateless services, they have also been used for running database clusters because of improved resilience attributes such as fast auto-recovery of failed database nodes, and location transparency at the level of TCP/IP connections between database instances. In this paper we evaluate the performance overhead of Docker Swarm and Kubernetes for deploying and managing NoSQL database clusters, with MongoDB as database case study. As the baseline for comparison, we use an OpenStack IaaS cloud that also allows attaining these improved resilience attributes although in a less automated manner.

The last few years have seen a drastic increase in the amount and the heterogeneity of NoSQL data stores. Consequently, exploration and comparison of these data stores have become difficult. Once chosen, it is hard to migrate to different data stores. Recently, a number of data access middleware platforms for NoSQL have emerged that provide access to different NoSQL data stores\nfrom standardized APIs. \n\nHowever, there are two key concerns related to: (i) the performance overhead introduced by these platforms,\nand (ii) the effort required to migrate between different data stores. \n\nIn this paper, we present two complementary studies that provide answers to the above mentioned concerns for three of the most mature data access middleware platforms: Impetus Kundera, Playorm, and Spring Data. First, we evaluate the performance overhead introduced by these platforms for the CRUD operations. Second, we compare the cost of migration with and without these platforms. \n\nOur study shows that, despite their similarity in design, these platforms are still substantially different performance-wise. Both studies are complementary as they show the trade-off inherent in adopting a data access middleware platform for NoSQL: by allowing some performance overhead, the developer gain benefits in terms of portability and easy migration across heterogeneous data stores.

Contemporary storage systems increasingly offer schema flexibility and support for semi-structured data models. This is the case for document-oriented databases, which as such allow ingestion of data from heterogeneous sources (IoT, sensors, monitoring). The increased influx of data further emphasizes the necessity for horizontal and elastic scalability, which are attained in NoSQL document stores through simplifying query functionality and relaxing transactional properties, e.g. through eventual consistency. The most compelling benefits of document stores are attained when data is stored in a denormalized form (De-NF). For example, one can decide to store relationships as an embedded copy to increase read query performance and as such avoid costly cross-node consultations. In comparison to the normalized form (NF), such designs come at a cost of additional data duplication, consistency and decreased write- and update performance. Determining the most appropriate data model for an application however depends on many factors, and the application developer is faced with the complexity of designing document data models that are optimized in terms of performance, scalability, storage and memory size, all requiring in-depth knowledge on the technology, the data meta-model, query plans and expected workloads. In this paper, we first discuss factors that impact the data schema design in document stores, such as the nature of the document and its attributes, horizontal partitioning, index selection, workload variability, and data uniformity. Although some data model design support tools are in existence, there are none that systematically take into account all these factors. Then, we outline our vision and roadmap towards systematic schema design support and tooling that involves (i) leveraging heuristics and common tactics to generate a finite number of candidate data models and (ii) ranking these candidate data models by means of cost functions that express their cost-effectiveness.

Regression testing is a form of software quality assurance (QA) that involves comparing the behavior of a newer version of a software artifact to its earlier correct behavior, and signaling the QA engineer when deviations are detected. Given the large potential in automated generation and execution of regression test cases for business process models in the context of running systems, powerful tools are required to make this practically feasible, more specifically to limit the potential impact on production systems, and to reduce the manual effort required from QA engineers.

Software product line engineering is a compelling methodology that accomplishes systematic reuse in families of systems by relying on two key principles: (i) the decomposition of complex systems into composable and reusable building blocks (often logical units called features), and (ii) on-demand construction of products and product variants by composing these building blocks.

With the increasingly pervasive role of software in society, security is becoming an important quality concern, emphasizing security by design, but it requires intensive specialization.

Software product line engineering (SPLE) and variability enforcement techniques have been applied to run-time adaptive systems for quite some years, also in the context of multi-tenant Software-as-a-Service (SaaS) applications. The focus has been mainly on (1) the pre-deployment phases of the development life cycle and (2) fine-grained (tenant-level), run-time activation of specific variants. However, with upcoming trends such as DevOps and continuous delivery and deployment, operational aspects become increasingly important.

This paper discusses the merits and challenges of adopting software product line engineering (SPLE) as the main development process for an automotive Hall Effect sensor. This versatile component is integrated into a number of automotive applications with varying safety requirements (e.g., windshield wipers and brake pedals).