REVIEW 3 major objections 4 minor 21 references
Envisioning Tool Support for Designing Privacy-Aware Internet of Thing Applications
T0 review · 3 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash
Pith's one-line read The paper argues that a usable, knowledge-driven design tool can turn ordinary IoT application designs into privacy-aware ones and produce evidence of compliance.
desk verdict A coherent, well-positioned IoT privacy-by-design vision paper whose load-bearing privacy index is never defined; fine as a research agenda if the verification claim is tempered. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The load-bearing mechanism is the data flow diagram (DFD) as a computable representation: nodes are device profiles, edges are data flows, and optional annotations add data retention and domain context. The DFD is converted into a semantic graph that algorithms can traverse, pair with a growing library of privacy patterns, and reason over using knowledge-based AI and automated planning. That graph is also what makes the privacy index possible, since rules can check where a pattern such as minimisation is applied — earlier in the flow scores higher — and then combine node-level and composition-level results into one number.
What would settle it
A concrete test would be to implement the minimal workflow on the paper's own two rehabilitation designs and ask a panel of privacy experts to rank them, then check whether an automatically generated privacy index always agrees with the panel's ranking and with the paper's claim that design 2 is better. A single pair of experts who rank the designs in opposite directions, or any design where the index contradicts every reasonable expert order, would falsify the premise that privacy awareness can be operationalised in this way.
Extended reading notes
Core claim
The central claim is that a privacy-aware IoT design tool can both transform and verify: it should take a developer's sketch of nodes and data flows, apply privacy-protecting patterns such as minimisation at the right place in the architecture, and then examine the result at both node level and composition level to produce an overall privacy index. On this view, privacy is a trade-off function rather than a fixed property, so the tool's job is not to dictate one design but to inform engineers which choices are more privacy-aware and why, before implementation starts. The paper's concrete object is the nine-step workflow in which steps 1–5 capture the design, steps 6–7 automatically assign services to nodes and insert privacy protections, step 8 rates the result, and step 9 generates terms and conditions.
Load-bearing premise
The whole vision depends on privacy being measurable as a computable property of a data-flow design: if a privacy index, composition rules, and pattern rankings cannot be defined and validated, the automated steps that transform and verify designs cannot be built.
Editorial extensions
If this is right
- Engineers without privacy expertise could sketch an IoT design and receive justified suggestions for making it privacy-aware before any code is written.
- The same design could be rated by an automatically computed privacy index, letting engineers compare alternatives without hiring a privacy consultant.
- Compliance reporting could be generated from the design itself, turning a diagram into evidence usable for GDPR-style approval decisions.
- The tool could double as privacy education, teaching novice developers and students the effect of applying a pattern early versus late in a data flow.
- Small and medium enterprises and freelance developers could reduce the cost of privacy consultancy and avoid expensive re-engineering after deployment.
Reading between the lines
- Beyond the paper: the privacy index idea could be tested against human expert panels; if the tool's rankings diverge from expert judgement on realistic designs, the operationalisation would need revision before the tool is trustworthy.
- Editorial inference: the same data-flow graph could support more than rating — it could drive formal checks such as reachability of raw personal data to a cloud node, or generate privacy-threat trees automatically.
- Editorial inference: the runtime-adaptation simulation the paper mentions could be extended to verify that privacy guarantees survive node failures, such as a smart band failing and the application reconfiguring to carry data through other sensors.
- Editorial inference: if such a tool matured, app-store style review could treat its automatically produced terms and conditions and privacy index as a standard submission artefact, making privacy comparison between IoT products possible for end users.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. This paper presents a research vision for a software tool that would help engineers design privacy-aware IoT applications. It motivates the vision through a healthcare scenario in which two designs satisfy the same functional requirements but differ in privacy awareness, then poses two research questions: how to operationalize 'better' designs and how to automatically convert weaker designs into better ones. The proposed workflow (Figure 2) has nine steps, from drawing a data-flow-diagram-style design to automatic service placement (Step 6), automatic incorporation of privacy-protecting measures (Step 7), computation of an overall privacy index at node and composition levels (Step 8), and automatic generation of terms and conditions (Step 9). The paper discusses candidate AI techniques (knowledge-based AI, case-based reasoning, automated planning, explainable AI), reviews related work in software engineering and HCI, and lists anticipated benefits including reduced engineering effort, lower consultancy costs, privacy education, and compliance support. It also identifies research directions including design notations, privacy pattern libraries, context-aware planning, and operationalization of a privacy index.
Significance. If the envisioned tool could be realized, it would address a real gap: IoT developers currently lack practical, design-time privacy support that goes beyond manual checklists. The paper usefully connects the vision to established frameworks such as Hoepman's privacy design strategies, LINDDUN, and PRIPARE, and it correctly highlights the need for usable, explainable tools rather than black-box automation. The nine-step workflow is a coherent structuring of the design problem, and the paper is honest in labeling key aspects as open challenges. However, the significance is conditional on the load-bearing premise that privacy can be operationalized as a computable, composable property of a DFD-style design; the paper does not yet demonstrate this. The contribution at this stage is a well-posed research agenda rather than a validated approach.
major comments (3)
- [Operationalisation, Measuring and Rating / Step 8 of Figure 2] The paper's central claim, stated in the abstract, is that the tool should 'transform IoT application designs into privacy-aware application designs' and 'validate and verify' them. The only verification mechanism proposed is the privacy index of Step 8, but the 'Operationalisation, Measuring and Rating' section lists factors (patterns used, pattern order, data sensitivity, risks) without defining a metric, a composition rule, a weighting scheme, or a validation semantics. The example that applying 'minimisation' earlier yields a higher index is an assertion about an undefined function. Because Step 7's output is to be judged by Step 8, the absence of a concrete or even sketched index leaves the central claim unsupported. The paper should either provide a preliminary computational model for the index (e.g., a concrete composition rule over node-level scores) or explicitly temper the claimed 'validate and verify' capability to 'support and inform'.
- [Abstract and 'Benefits and Impact'] The abstract anticipates that the tool 'will save many engineering hours' and the 'Economic Impact' section claims it will help SMEs reduce or eliminate privacy consultancy costs. No user study, prototype, cost model, or empirical benchmark is presented or cited to support these quantitative claims. As a vision paper, these should be framed as testable hypotheses or intended benefits to be evaluated in future work, not as anticipated outcomes. Please revise the wording to avoid presenting unsupported cost savings as established expectations.
- [State of the Art] The claim in 'Tool-Assisted Privacy-Aware IoT Applications Design' that 'The tool we propose is something that the engineering community has not seen before' is stronger than the paper's own related-work discussion supports. LINDDUN [12] is already a DFD-based framework that systematically identifies privacy threats, and PRIPARE provides privacy patterns classified by Hoepman's strategies. What appears genuinely novel is the proposed automation of pattern selection, integration, and verification in an interactive design tool, not the absence of any prior privacy-focused design support. The novelty claim should be narrowed accordingly.
minor comments (4)
- [Intelligence and Automation, Case-based reasoning] There is a typo in the case-based reasoning bullet: 'from is a library' should read 'from a library.'
- [Research Questions (Privacy Challenge at Design Time)] The two research questions are presented in italics without numbering; numbering them (e.g., RQ1 and RQ2) would make later references to them easier for readers.
- [Intelligence and Automation] The sentence 'These techniques can be contributed to implementing step 1 to step 9' is awkward; consider 'These techniques can contribute to the implementation of Steps 1 through 9.'
- [State of the Art / References] Reference [6] is cited as the source for the claim that applying privacy principles to IoT applications is time-consuming and difficult, but it is a self-citation that appears to be closely related to this paper; please clarify the nature of the prior investigation and ensure the citation is not circular.
Circularity Check
No circularity: the paper is a vision statement, and its proposed privacy index and transformation workflow are explicitly open research challenges rather than derived results.
full rationale
This is a vision/position paper rather than a derivation. The abstract's central claim—that a tool could transform IoT designs into privacy-aware designs and validate them—is presented as a research proposal with an envisioned workflow (Steps 1–9), not as a derived theorem or empirical prediction. No equation or algorithm is defined, so there is no input-output relation that could be equivalent to its inputs by construction. The self-citations [6] and [10] are used for background statements ('Previous investigations have shown that applying privacy principles into IoT applications is time-consuming and difficult [6]') and for a granular guideline set built on Hoepman's external design strategies; these citations support motivation and provide reusable content, but the paper's core proposal does not reduce to them. The privacy index is explicitly acknowledged as an open operationalisation challenge ('Operationalisation of privacy is a challenging task'), and the factors listed are not combined into a metric; this is an unfulfilled feasibility premise, not a circular definition. Therefore no circular step can be identified.
Assumptions & free parameters
assumptions (4)
- domain assumption An IoT application design drawn as nodes and data flows contains enough semantic information to assess privacy and automate privacy-preserving transformations.
- domain assumption Privacy quality can be operationalized as a numeric index by combining node-level and composition-level scores.
- domain assumption Automated service allocation and privacy-pattern insertion can be formulated and solved as a constraint or planning problem at practical scale.
- domain assumption Software engineers targeted by the tool (SMEs, freelancers, makers) would adopt it and would otherwise lack privacy expertise.
Cite this review
Pith. "Pith review of Envisioning Tool Support for Designing Privacy-Aware Internet of Thing Applications." pith.science (2026). https://pith.science/paper/6O4D4BCH
@misc{pith2026190802724,
author = {Pith},
title = {Pith review of: Envisioning Tool Support for Designing Privacy-Aware Internet of Thing Applications},
year = {2026},
howpublished = {\url{https://pith.science/paper/6O4D4BCH}},
note = {Machine review of arXiv:1908.02724}
}
read the original abstract
The design and development process for Internet of Things (IoT) applications is more complicated than for desktop, mobile, or web applications. IoT applications require both software and hardware to work together across multiple different types of nodes (e.g., microcontrollers, system-on-chips, mobile phones, miniaturised single-board computers, and cloud platforms) with different capabilities under different conditions. IoT applications typically collect and analyse personal data that can be used to derive sensitive information about individuals. Without proper privacy protections in place, IoT applications could lead to serious privacy violations. Thus far, privacy concerns have not been explicitly considered in software engineering processes when designing and developing IoT applications, partly due to a lack of tools, technologies, and guidance. This paper presents a research vision that argues the importance of developing a privacy-aware IoT application design tool to address the challenges mentioned above. This tool should not only transform IoT application designs into privacy-aware application designs but also validate and verify them. First, we outline how this proposed tool should work in practice and its core functionalities. Then, we identify research challenges and potential directions towards developing the proposed tool. We anticipate that this proposed tool will save many engineering hours which engineers would otherwise need to spend on developing privacy expertise and applying it. We also highlight the usefulness of this tool towards privacy education and privacy compliance.
Reference graph
Works this paper leans on
-
[6]
Designing Privacy- aware Internet of Things Applications,
C. Perera, M. Barhamgi, A. K. Bandara, M. Ajmal, B. Price, and B. Nuseibeh, “Designing Privacy- aware Internet of Things Applications,” Inf. Sci. (Ny)., vol. 512, pp. 238–257, Mar. 2020
work page 2020
-
[10]
Privacy-by-Design Framework for Assessing Internet of Things Applications and Platforms,
C. Perera, C. Mccormick, A. Bandara, B. A. Price, and B. Nuseibeh, “Privacy-by-Design Framework for Assessing Internet of Things Applications and Platforms,” in The 6th International Conference on the Internet of Things, 2016, pp. 83–92
work page 2016
-
[12]
M. Deng, K. Wuyts, R. Scandariato, B. Preneel, and W. Joosen, “A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements,” Requir. Eng., vol. 16, no. 1, pp. 3–32, 2011
work page 2011
-
[1]
Privacy and Data Protection by Design - from policy to engineering,
G. Danezis et al., “Privacy and Data Protection by Design - from policy to engineering,” 2014
work page 2014
-
[2]
Internet of Things IoT Governance, Privacy and Security Issues,
European Communities, “Internet of Things IoT Governance, Privacy and Security Issues,” 2015
work page 2015
-
[3]
HACKING IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities,
M. Stanislav and T. Beardsley, “HACKING IoT: A Case Study on Baby Monitor Exposures and Vulnerabilities,” 2015
work page 2015
-
[4]
General Data Protection Regulation (GDPR),
European Commission, “General Data Protection Regulation (GDPR),” Off. J. Eur. Union, 2016
work page 2016
-
[5]
My Physio App: Better communication, understanding and results,
S. Cowan, “My Physio App: Better communication, understanding and results,” Br. J. Sports Med., vol. 50, no. 21, pp. 1348–1349, 2016
work page 2016
Show all 21 references
-
[7]
Resolution on Privacy by Design,
A. Cavoukian, “Resolution on Privacy by Design,” in 32nd International Conference of Data Protection and Privacy Commissioners, 2010
2010
-
[8]
Engineering Privacy,
S. Spiekermann and L. F. Cranor, “Engineering Privacy,” IEEE Trans. Softw. Eng., vol. 35, no. 1, pp. 67–82, Jan. 2009
2009
-
[9]
Privacy Design Strategies,
J.-H. Hoepman, “Privacy Design Strategies,” in ICT Systems Security and Privacy Protection, vol. 428, N. Cuppens-Boulahia, F. Cuppens, S. Jajodia, A. Abou El Kalam, and T. Sans, Eds. Springer Berlin Heidelberg, 2014, pp. 446–459
2014
-
[11]
Howard and S
M. Howard and S. Lipner, The security development lifecycle: SDL, a process for developing demonstrably more secure software. Microsoft Press, 2006
2006
-
[13]
A pattern language for developing privacy enhancing technologies,
M. Hafiz, “A pattern language for developing privacy enhancing technologies,” Softw. Pract. Exp., vol. 43, no. 7, pp. 769–787, Jul. 2013
2013
-
[14]
Playing the Legal Card: Using Ideation Cards to Raise Data Protection Issues within the Design Process,
E. Luger, L. Urquhart, T. Rodden, and M. Golembewski, “Playing the Legal Card: Using Ideation Cards to Raise Data Protection Issues within the Design Process,” Proc. ACM CHI’15 Conf. Hum. Factors Comput. Syst., vol. 1, pp. 457–466, 2015
2015
-
[15]
A ‘nutrition label’ for privacy,
P. G. Kelley, J. Bresee, L. F. Cranor, and R. W. Reeder, “A ‘nutrition label’ for privacy,” Proc. 5th Symp. Usable Priv. Secur. SOUPS 09, vol. 1990, p. 1, 2009
1990
-
[16]
Understanding the Purpose of Permission Use in Mobile Apps,
H. Wang, Y. Li, Y. Guo, Y. Agarwal, and J. I. Hong, “Understanding the Purpose of Permission Use in Mobile Apps,” ACM Trans. Inf. Syst., vol. 35, no. 4, pp. 1–40, Jul. 2017
2017
-
[17]
Privacy Expectations and Preferences in an IoT World,
P. E. Naeini et al., “Privacy Expectations and Preferences in an IoT World,” in Thirteenth Symposium on Usable Privacy and Security (SOUPS 2017), 2017, pp. 399–412
2017
-
[18]
Design, construction, and application of a generic visual language generation environment,
K. Zhang, D.-Q. Zhang, and J. Cao, “Design, construction, and application of a generic visual language generation environment,” IEEE Trans. Softw. Eng., vol. 27, no. 4, pp. 289–307, 2001
2001
-
[19]
Privacy compliance and enforcement on European healthgrids: an approach through ontology,
H. B. Rahmouni, T. Solomonides, M. C. Mont, and S. Shiu, “Privacy compliance and enforcement on European healthgrids: an approach through ontology,” Philos. Trans. R. Soc. A Math. Phys. IEEE Internet of Things Magazine Eng. Sci., vol. 368, no. 1926, pp. 4057–4072, 2010
1926
-
[20]
Web Service Composition,
A. L. Lemos, F. Daniel, and B. Benatallah, “Web Service Composition,” ACM Comput. Surv., vol. 48, no. 3, pp. 1–41, Dec. 2015
2015
-
[21]
Expectation and Purpose: Understanding Users Mental Models of Mobile App Privacy through Crowdsourcing,
J. Lin, N. Sadeh, S. Amini, J. Lindqvist, J. I. Hong, and J. Zhang, “Expectation and Purpose: Understanding Users Mental Models of Mobile App Privacy through Crowdsourcing,” in Proceedings of the 2012 ACM Conference on Ubiquitous Computing - UbiComp ’12, 2012, p. 501. Charith ...
2012
Reviewed August 14, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.