Unit 10
Faceted data
Read Schmitz et al (2016) article about faceted data.
- Do you think this is a good approach to protect systems from data leakage? What are the pros and cons?
- Create a basic outline design of how you would create such a system in Python.
Faceted data offers a way to restrict access to information and control its disclosure (including through side effects) during a program’s execution (Schmitz et al., 2016). The idea builds on earlier work by Devriese and Piessens (2010) on noninterference: a strategy to ensure that a program running at a lower authorization level cannot access or infer information about higher-level execution. They introduced secure multi-execution to tackle this — a method that runs the same logic for different access rights in parallel, reuses inputs, and delays outputs until it can verify the user has sufficient permissions. Only then the result is returned and any side effects are applied.
However, this concept does not integrate well with existing approaches in Python’s information flow and introduces mental overhead for a programmer, as such multi-execution effectively introduces another level of branching and abstractions over the programming language in use. It would also require wrapping the connections to the outer world with faceted-data-compatible interfaces o prevent side effects in unauthorized branches.
In any case, the concept of the faceted values that prevent accidental data leaks is a fascinating concept worth exploring. I would focus on this angle, which is also discussed in Cifuentes and Bierman (2019) with reference to CWE-532 “Insertion of Sensitive Information into Log File” (The MITRE Corporation, no date). This scenario is more common and has clear attack vectors and consequences. To address it, we can introduce a simple wrapper class that behaves differently depending on the context: returning the real value for authorized access and a default value otherwise. Contexts can also be arranged hierarchically (for example, admin → manager → logger → user → guest).
An example implementation is below:
from enum import IntEnum, auto
class Level(IntEnum):
GUEST = 0
USER = auto()
LOGGER = auto()
MANAGER = auto()
ADMIN = auto()
class FacetedValue:
"""Return the true value only to callers at or above the owner’s level."""
def __init__(self, value, level: Level, default=None):
self._value = value
self._level = level
self._default = default
def reveal(self, caller: Level = Level.GUEST):
return self._value if caller >= self._level else self._default
secret = FacetedValue("Alice's salary: €95 000", Level.MANAGER)
print(secret.reveal()) # → None
print(secret.reveal(Level.LOGGER)) # → None
print(secret.reveal(Level.MANAGER)) # → Alice's salary: €95 000
print(secret.reveal(Level.ADMIN)) # → Alice's salary: €95 000
References
Cifuentes, C. and Bierman, G. (2019) ‘What is a Secure Programming Language?’, in B.S. Lerner, R. Bodík, and S. Krishnamurthi (eds) 3rd Summit on Advances in Programming Languages (SNAPL 2019). Dagstuhl, Germany: Schloss Dagstuhl – Leibniz-Zentrum für Informatik (Leibniz International Proceedings in Informatics (LIPIcs)), p. 3:1-3:15. Available at: https://doi.org/10.4230/LIPIcs.SNAPL.2019.3.
Devriese, D. and Piessens, F. (2010) ‘Noninterference through Secure Multi-execution’, in 2010 IEEE Symposium on Security and Privacy. 2010 IEEE Symposium on Security and Privacy, pp. 109–124. Available at: https://doi.org/10.1109/SP.2010.15.
Schmitz, T. et al. (2016) ‘Faceted Dynamic Information Flow via Control and Data Monads’, in Principles of Security and Trust. International Conference on Principles of Security and Trust, Springer, Berlin, Heidelberg, pp. 3–23. Available at: https://doi.org/10.1007/978-3-662-49635-0_1.
The MITRE Corporation (no date) CWE - CWE-532: Insertion of Sensitive Information into Log File (4.17). Available at: https://cwe.mitre.org/data/definitions/532 (Accessed: 20 July 2025).
API demonstrations
Read the article by Bogner et al (2023) and write a paragraph on the relevance of these design rules to your system.
The research by Bogner, Kotstein, and Pfaff (2023) shows that REST APIs designed according to established guidelines are generally easier to understand, use, and maintain. Although the study is recent and based on survey data, the idea of writing and organizing code according to consistent style guidelines to improve collaboration and maintainability has been widely accepted for a long time (Zakas, 2012).
Since the developed solution includes a REST API for accessing the system’s server component, it is important to follow commonly accepted recommendations for API design. These practices not only help create APIs that are easier to understand and maintain, but also support better endpoint organization making it easier to identify missing functionality. If endpoints are named or structured arbitrarily, or if GET
parameters are used instead of path parameters, the API lacks internal logic, which makes it harder to verify its completeness.
References
Bogner, J., Kotstein, S. and Pfaff, T. (2023) ‘Do RESTful API design rules have an impact on the understandability of Web APIs?’, Empirical Software Engineering, 28(6), pp. 1–35. Available at: https://doi.org/10.1007/s10664-023-10367-y.
Zakas, N.C. (2012) Why Coding Style Matters, Smashing Magazine. Available at: https://www.smashingmagazine.com/2012/10/why-coding-style-matters/ (Accessed: 20 July 2025).