Data Capsule: A New Paradigm for Automatic Compliance with Data Privacy Regulations

Andrew Low; David Dao; Dawn Song; Joseph P. Near; Lun Wang; Neel Somani; Peng Gao

REVIEW 4 major objections 4 minor 33 references

Data Capsule: A New Paradigm for Automatic Compliance with Data Privacy Regulations

T0 review · 4 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Privacy policies that ride with data automate compliance checks.

desk verdict Nice paradigm and clearly written, but the abstract interpreter is unsound for composition, so the 'ensures compliance automatically' claim doesn't hold as stated. read the letter →

arxiv 1909.00077 v1 pith:BIYEFRYG submitted 2019-08-30 cs.CY

Lun Wang , Joseph P. Near , Neel Somani , Peng Gao , Andrew Low , David Dao , Dawn Song This is my paper · ORCID

classification cs.CY

keywords dataprivacyGDPRformalpolicycapsuleresidualpoliciesabstractinterpretationstaticcompliancecheckingPriv

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that privacy-compliance checking can be made automatic by bundling each person's data with a formal policy and keeping that policy attached as the data is copied, transformed, and combined. The proposed Data Capsule paradigm covers GDPR, CCPA, HIPAA, and FERPA by reducing them to five principles, encodes the formalizable parts in the PrivPolicy language, and verifies data-processing programs statically before they run. If the paradigm works as claimed, organizations would not have to audit every pipeline by hand or retrofit systems after the fact; compliance would be a by-product of how data is stored and processed. The paper also reports a proof-of-concept manager, PrivGuard, with negligible measured overhead.

What carries the argument

The carrying object is the data capsule: a triple of sensitive data, a PrivPolicy policy, and metadata, tracked in a data capsule graph. The argument is carried by two formal pieces. First, the abstract interpreter over a small data-flow language ($getDC$, $filter$, $project$, $redact$, $join$, $union$, $dpCount$), whose derivation rules attach attributes such as $filter$, $schema$, $redact$, and $declass$ to the policy effect of the program. Second, the residual-policy rule RP, which removes from the input policy any attribute whose value is subsumed by a guarantee in the program's policy effect, so the output capsule inherits only the requirements that remain unsatisfied. Attribute domains are defined as lattices, with interval domains for filters and set domains for schemas, which lets policies express richer conditions than earlier policy languages.

What would settle it

The cleanest falsifier would be a program $e$ in the supported data-flow language for which the rules build a derivation $\Delta \vdash e : D[s,\psi]$ while the program's concrete execution actually violates an attribute in $\psi$; finding one would refute the soundness claim on which residual policies rest. A practical version: run PrivGuard on a pipeline that projects a column containing a protected identifier and declassifies the output; if the residual policy no longer requires redaction yet the identifier remains raw in the output, the guarantee fails.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that privacy compliance can be made automatic by encapsulating data with its policy and statically checking the programs that process it. The check works by abstract interpretation of data-flow programs: an abstract interpreter derives a policy effect $\psi$ for a program $e$, written $\Delta \vdash e : D[s,\psi]$, recording attributes the program is guaranteed to satisfy, such as a filter, a projection, a redaction, or a differential-privacy count. The residual policy for the output capsule is the input policy minus every attribute the program is guaranteed to satisfy, computed by the rule $residual(c,\psi) = c - \{k:p \mid k:p \in c \land satisfies(k:p,\psi)\}$. If the paper is right, an organization can run existing analysis pipelines while a data capsule manager ensures that no policy is ever violated and that derived data continue to carry the still-unsatisfied requirements.

Load-bearing premise

The load-bearing premise is that the abstract-interpretation derivation $\Delta \vdash e : D[s,\psi]$ genuinely guarantees the program satisfies every attribute in $\psi$, and that the same rules carry over to real SQL, Pandas, Spark, and imperative programs; the paper states this and calls the extension straightforward, but proves neither soundness nor the extension.

Editorial extensions

If this is right

Data subjects can see the full path of their data by restricting the data capsule graph to reachable capsules, which directly implements the transparency, portability, and deletion requirements of GDPR.
Pipelines compose cleanly: intermediate capsules stay hidden, and a final capsule is declassified only after its residual policy is empty and the analyst passes a role check.
Because enforcement is static and does not depend on the data, it scales to arbitrary dataset sizes and adds only parsing, policy-ingestion, and residual-policy overhead, with ingestion as the measured bottleneck.
A system built on the five privacy principles can be extended to future regulations, since new requirements only need to be expressible as PrivPolicy attributes and lattices.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper states soundness but does not prove it; a formal proof connecting $\Delta \vdash e : D[s,\psi]$ to the concrete semantics of the program would be needed before a residual policy could be relied on in an audit or a legal proceeding.
The claim that the analysis extends straightforwardly to SQL, Pandas, Spark, Hadoop, and imperative programs is asserted rather than demonstrated; implementing the abstract transformers for those real platforms and checking them against runtime provenance is the natural testable next step.
A deeper consequence the paper leaves implicit: because declassification is the only exit from a capsule, residual policies could carry cumulative privacy-loss budgets, so repeated differentially private analyses on derived capsules stay within a global privacy-loss bound.
The residual-policy rule merges input policies by taking their disjunctive-normal-form least upper bound; testing how conflicting values of the same attribute, such as two subjects with different consent conditions, flow through a join would reveal whether the merge semantics preserves each subject's individual guarantee.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

You should know this paper's core claim doesn't survive close reading. The residual-policy idea is genuinely interesting, and the paper is well written, but the formal machinery that is supposed to guarantee compliance has a load-bearing soundness hole. The abstract interpreter of Section 5.3 gives no theorem connecting its derivations to any concrete semantics, and the rules themselves are not conservative under composition. The dpCount rule records declass:DP(ε,δ) in an ordinary set, duplicates collapse, and satisfies() is existential. So join(dpCount(0.5,δ,...), dpCount(0.5,δ,...)) has effect containing a single DP(0.5), which satisfies a policy requirement of DP(0.75). But if the two inputs share data subjects—the analysis cannot rule this out—the combined output has ε=1.0 under basic composition, so the residual policy drops a requirement the program actually violates. That is exactly what the system promises to prevent. The stress-test note is right, and this is not a minor gap: it breaks the central claim inside the formalized subset.

What the paper does well: the core concepts—data capsules, the data capsule graph, residual policies as a pipeline mechanism—are presented cleanly and make sense. The move from LEGALEASE's concept lattices to abstract-interpretation-style attribute domains (FILTER intervals, schema sets) is a real step forward in expressiveness. The policy encodings of GDPR/HIPAA/CCPA/FERPA are thought through, and the authors are honest about what they omit, saying 'We omit the details here' rather than pretending. The implementation, such as it is, works for the toy language.

The soft spots are proportionate: the missing soundness theorem is the big one, and the DP-composition hole makes the theorem non-trivial. The claim that extending to SQL/Pandas/Spark/Hadoop and functional or imperative programs is 'straightforward' is unsupported, and the evaluation measures ingestion and set-difference cost, not the abstract interpretation of real programs. The GDPR encoding is informal and not validated against legal practice.

Who is this for? Privacy engineering researchers looking for a paradigm and a starting point. It deserves a serious referee, but the referee should send it back with a clear request: fix the abstract interpretation so that composition is sound (e.g., carry a privacy-budget monoid instead of a set), prove a soundness theorem against a concrete semantics, and scope the claims to what is actually implemented.

My recommendation: send it to peer review—the ideas are worth serious engagement—but expect major revision and do not accept it in its current form.

Referee Report

4 major / 4 minor

Summary. The paper proposes the Data Capsule paradigm for automatic compliance with data privacy regulations such as GDPR, HIPAA, CCPA, and FERPA. A data subject's data is paired with a policy written in PrivPolicy, and the policy travels with derived data through a data capsule graph. The authors introduce a static enforcement mechanism based on abstract interpretation: for each analysis program, an abstract interpreter derives a policy effect, and a residual policy for the output capsule is computed by removing from the input policy those attributes the program is claimed to satisfy. The paper also describes PrivGuard, a reference implementation, reports a scalability evaluation, and gives a formal encoding of a subset of GDPR.

Significance. If the technical claims were fully established, this would be a significant contribution: it combines a formal policy language, a compositional residual-policy mechanism, and a static analysis for policy enforcement into a deployable-looking system, with an explicit attempt to encode real regulations. The residual-policy concept and the use of abstract-interpretation domains for policy attributes are promising ideas, and the performance evaluation shows that the policy-ingestion bottleneck can scale. However, the central claim of guaranteed automatic compliance is currently not supported: the abstract interpreter has no soundness proof and, as written, is unsound for a concrete class of programs involving differential privacy composition. The GDPR encoding is informal and unvalidated, and the claimed extensibility to SQL/Pandas/Spark/Hadoop is asserted without implementation. These gaps are load-bearing for the paper's main contribution, so the manuscript needs substantial revision before the enforcement guarantee can be accepted.

major comments (4)

[Section 5.3, Figure 6] The abstract interpreter is not conservative, and no soundness theorem is stated or proved. The sentence after Figure 6 ('we know that the program is guaranteed to satisfy the policy clause ψ') is the only justification, but the rules are refuted by a concrete case. Because ψ is an ordinary set, the JOIN rule uses ψ1 ∪ ψ2 and duplicate declass:DP attributes collapse. Consider join(dpCount(0.5, δ, filter(...)), dpCount(0.5, δ, ...)) computed over inputs with overlapping data subjects. Basic composition gives total privacy loss ε = 1.0 and δ roughly doubled, yet the inferred effect contains a single declass:DP(0.5, δ). The satisfies() relation in Section 5.4 then treats a policy requirement DECLASS DP(0.75, δ) as fulfilled, so the residual policy drops a requirement the program does not actually meet. This directly contradicts the claim that the analysis 'ensures compliance automatically'.
[Section 5.4, residual-policy rule (RP)] The residual-policy computation inherits the unsoundness of the effect system and is not proved to preserve the input policy's requirements. The rule drops attribute k:p when ψ contains k:p' with p ⊑ p', but the example in the previous comment shows that ψ can overstate guarantees of composed programs. The paper gives no theorem of the form: if residual(c, ψ) = c' and a later program satisfies c', then the composite program satisfies c. Without such a preservation result, the key claim in Section 1 that 'the residual policy encodes the policy requirements which remain to be satisfied by later programs' is not established. The problem also crosses pipeline stages because residual policies carry no privacy-budget information, so a pipeline can be certified even though one stage's DP guarantee does not survive composition with the next stage's processing.
[Section 4 and Section 5.3] The paper's deployment claim is not supported by the formalization or the evaluation. The language in Figure 5 is a small dataflow calculus, and the text asserts that extending it to SQL, Pandas, Hadoop, Spark, and functional or imperative programs is 'straightforward' (Section 4), but no extension, implementation, or case study is provided. The evaluation in Section 7 measures only the performance of parsing, policy ingestion, and residual-policy computation; it does not test enforcement on real analysis programs. Thus the abstract's claim that the solution 'ensures compliance automatically' in heterogeneous infrastructures currently rests on an unverified extrapolation from the toy language.
[Section 6 and Section 5.2] The GDPR encoding is informal and the attribute definitions are incomplete. The paper says the role, declass, and redact attribute domains are defined by finite lattices but then says 'We omit the details here' (Section 5.2), so the enforcement semantics is only partially specified. Furthermore, Figure 7 contains no proof or formal argument that the encoding faithfully captures the legal requirements of GDPR, and the paper provides no methodology for validating such encodings. Since compliance is established only with respect to the policy, not directly with respect to the regulation, unvalidated or incomplete encodings leave open the possibility that a certified program is not actually GDPR-compliant.

minor comments (4)

[Section 1] The phrase 'without no systematic record of the copies' should be 'without any systematic record of the copies'.
[Figure 8 and Section 7.2] The label 'HIPPA' is a misspelling of 'HIPAA', and the description of the scalability trend ('polynomial growth at first and then keep stable') is unclear because the figure is log-log; a more precise explanation of the plateau would help.
[Section 6, Figure 7] Line 17 of Figure 7, 'AND PURPOSE PublicInterest LegalObligation PublicHealth', does not correspond to the grammar given in Table 1, which requires AND/OR connectives; the intended conjunction or disjunction should be made explicit.
[Section 5.2, Eq. (1)] The interval abstract domain for FILTER attributes is defined only for integer-valued fields, but the paper does not discuss how string-valued or real-valued filter conditions would be handled, which is relevant for the claimed applicability to Pandas and Spark.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity; the residual-policy rule is a definition (input minus satisfied attributes) rather than a fitted prediction, and the only self-citation is not load-bearing.

full rationale

The paper's central derivation is a formal construction: Section 5.4 defines the residual policy as Υout(e) = {c−{k:p | k:p∈c ∧ satisfies(k:p,ψ)} | c∈Υin(e)}, where ψ is the abstract effect obtained from the rules in Figure 6. This is exactly the definition of a residual policy—the input policy weakened by requirements the program's effect satisfies—so it is not an empirically predicted quantity and does not use the output to define the input. The claimed 'automatic compliance' depends on the soundness of the abstract interpreter, which Section 5.3 asserts without a concrete semantics or soundness theorem ('If we can use the semantics to build a derivation tree of the form ∆⊣ e : D[s,ψ ], then we know that the program is guaranteed to satisfy the policy clause ψ'); that is an unproved correctness premise, not a circular reduction. The same is true of the Section 5.4 satisfies() rule, whose existential check over the set-valued effect ψ can be non-conservative under composition (e.g., two dpCount steps may collapse their DP(ε,δ) attributes, so a requirement could be dropped that was not actually met); this would be unsoundness, not circularity. The only self-citation, [10] (Maniatis et al., HotOS 2011, a prior work by overlapping author D. Song), supports the motivating claim that organizations cannot locate all copies of data for deletion; the residual-policy analysis does not rely on it, so the self-citation is not load-bearing. Other unsupported claims—Section 4's assertion that extending the analysis to SQL/Pandas/Spark/Hadoop and to functional/imperative programs is 'straightforward,' and Section 3.3's statement that the portability one-to-one-mapping requirement is 'formalized in Section 5' (which Section 5 does not actually do)—are missing support or omitted proofs, not circular steps. Because no quoted equation reduces a claimed result to its own input or to a fitted parameter, circularity is at most mild and incidental.

Assumptions & free parameters 0 free parameters · 4 assumptions · 5 invented entities

The central claim rests on the unproven soundness of the abstract interpreter, the compositionality of residual policies, the unsupported extension to real data processing systems, and the informal GDPR encoding. No parameters are fitted to data; the ε and δ in the example policy are policy inputs rather than fitted constants.

assumptions (4)

domain assumption Abstract interpretation rules are sound: if Δ⊢ e : D[s,ψ] then every execution of e guarantees all attributes in ψ.
Section 5.3 asserts 'we know that the program is guaranteed to satisfy the policy clause ψ' but no soundness proof is provided.
ad hoc to paper The residual policy computation preserves the original input policy's requirements in composed pipelines.
Section 5.4 defines residual via the satisfies relation and does not prove that chaining residual policies keeps the original policy enforceable.
domain assumption The toy dataflow language analysis extends to SQL, Pandas, Spark, Hadoop, and imperative/functional programs.
Section 4 states extending to these is 'straightforward', without proof or implementation.
ad hoc to paper The PrivPolicy encoding of GDPR in Figure 7 accurately captures the regulation's requirements.
Section 6 presents the encoding informally; attributes such as HasAppropriateSafeguards are not defined, and no legal validation is given.

invented entities (5)

Data capsule
purpose: Bundle of a data subject's data, a PrivPolicy policy, and privacy metadata, carried through all processing.
Introduced as the core abstraction; implementation not released. The notion predates this paper in [10].
Data capsule graph
purpose: Tracks all capsules and the programs that process them, enabling transparency, portability, and deletion.
Described as a component of PrivGuard; no independent artifact or formal model.
PrivPolicy
purpose: Formal language for expressing privacy policies as clauses over lattice attributes.
New language, but no formal grammar implementation or tooling beyond prototype.
Residual policy
purpose: Policy attached to the output of an analysis program, expressing requirements not yet satisfied.
Defined in Section 5.4; the definition is not verified by soundness proof or external check.
PrivGuard
purpose: Reference data capsule manager implementing ingestion, graph management, and static analysis.
Mentioned as implemented, but no code release or executable artifact, so the falsifiable handle is not available.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Data Capsule: A New Paradigm for Automatic Compliance with Data Privacy Regulations." pith.science (2026). https://pith.science/paper/BIYEFRYG

@misc{pith2026190900077,
  author       = {Pith},
  title        = {Pith review of: Data Capsule: A New Paradigm for Automatic Compliance with Data Privacy Regulations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BIYEFRYG}},
  note         = {Machine review of arXiv:1909.00077}
}

read the original abstract

The increasing pace of data collection has led to increasing awareness of privacy risks, resulting in new data privacy regulations like General data Protection Regulation (GDPR). Such regulations are an important step, but automatic compliance checking is challenging. In this work, we present a new paradigm, Data Capsule, for automatic compliance checking of data privacy regulations in heterogeneous data processing infrastructures. Our key insight is to pair up a data subject's data with a policy governing how the data is processed. Specified in our formal policy language: PrivPolicy, the policy is created and provided by the data subject alongside the data, and is associated with the data throughout the life-cycle of data processing (e.g., data transformation by data processing systems, data aggregation of multiple data subjects' data). We introduce a solution for static enforcement of privacy policies based on the concept of residual policies, and present a novel algorithm based on abstract interpretation for deriving residual policies in PrivPolicy. Our solution ensures compliance automatically, and is designed for deployment alongside existing infrastructure. We also design and develop PrivGuard, a reference data capsule manager that implements all the functionalities of Data Capsule paradigm.

Figures

Figures reproduced from arXiv: 1909.00077 by the authors.

**Figure 1.** Example Data Capsule Graph The life cycle of a data capsule includes four phases: 1. Data Ingestion. Data subjects construct data capsules from their sensitive data via the ingestion process, which pairs the data with the policy which will govern its use. In our setting, the data subject is the original data owner, whose privacy we would like to protect. 2. Analysis Program Submission. Analysts who would like to pro… view at source ↗

**Figure 2.** summarizes the architecture of PRIVGUARD. The two major components of the system are the data capsule manager itself, which maintains the data capsule graph, and the static analyzer, which analyzes policies and analysis programs to compute residual policies. We describe the data capsule manager here, and formalize the static analyzer in Section 5. PrivGuard Data Capsule Manager Static Analyzer Data Metadata + Polici… view at source ↗

**Figure 3.** A subset of GDPR using PRIVPOLICY. The grammar for the surface syntax of PRIVPOLICY is given in [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗

Figures from the paper (5 more)

**Figure 4.** Figure 4: Disjunctive normal form of the example policy. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

**Figure 5.** Figure 5: Program Surface Syntax We next describe the use of abstract interpretation to determine the policy effect of an analysis program. We introduce this concept using a simple dataflow-oriented language, similar to relational algebra, Pandas, or Spark, presented in [PITH_F…

**Figure 6.** Figure 6: Sample rules implementing an abstract interpreter for the data capsule expressions in the language presented [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]

**Figure 7.** Figure 7: Formal encoding of GDPR. This section describes our formal encoding of a subset of GDPR, which is intended to ensure automated compliance with the regulation. We are in the process of developing similar encodings for other regulations, including HIPAA, FERPA [PITH_F…

**Figure 8.** Figure 8: Scalability of policy analysis: ingestion operation. [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

33 extracted references · 33 canonical work pages

[1]

The 18 biggest data breaches of the 21st century,

“The 18 biggest data breaches of the 21st century,” https://www.csoonline.com/article/2130877/ the-biggest-data-breaches-of-the-21st-century.html, 2019, online; accessed 23 May 2019

work page arXiv 2019
[2]

Risk and anxiety: A theory of data-breach harms,

D. J. Solove and D. K. Citron, “Risk and anxiety: A theory of data-breach harms,” Tex. L. Rev., vol. 96, p. 737, 2017

work page 2017
[3]

Insider threat 2018 report,

“Insider threat 2018 report,” https://www.ca.com/content/dam/ca/us/ﬁles/ebook/insider-threat-report.pdf, 2019, online; accessed 23 May 2019

work page 2018
[4]

The use and abuse of computerized information: Striking a balance between personal privacy interests and organizational information needs,

L. E. Murdock, “The use and abuse of computerized information: Striking a balance between personal privacy interests and organizational information needs,”Alb. L. Rev., vol. 44, p. 589, 1979

work page 1979
[5]

The eu general data protection regulation (gdpr),

“The eu general data protection regulation (gdpr),” https://eugdpr.org/, 2019, online; accessed 16 April 2019

work page 2019
[6]

California consumer privacy act (ccpa),

“California consumer privacy act (ccpa),” https://www.caprivacy.org/, 2019, online; accessed 16 April 2019

work page 2019
[7]

The family educational rights and privacy act of 1974 (ferpa),

“The family educational rights and privacy act of 1974 (ferpa),” https://www.colorado.edu/registrar/students/records/ferpa, 2019, online; accessed 16 April 2019

work page 1974
[8]

Health insurance portability and accountability act (hipaa),

“Health insurance portability and accountability act (hipaa),” https://searchhealthit.techtarget.com/deﬁnition/HIPAA, 2019, online; accessed 16 April 2019

work page 2019

Show all 33 references

[9]

Google keeps your data forever - unlocking the future transparency of your past,

“Google keeps your data forever - unlocking the future transparency of your past,” https://www.siliconvalleywatcher. com/google-keeps-your-data-forever---unlocking-the-future-transparency-of-your-past/, 2019, online; accessed 30 May 2019

2019
[10]

Do you know where your data are? secure data capsules for deployable data protection

P. Maniatis, D. Akhawe, K. R. Fall, E. Shi, and D. Song, “Do you know where your data are? secure data capsules for deployable data protection.” inHotOS, vol. 7, 2011, pp. 193–205

2011
[11]

Extract, transform, load,

“Extract, transform, load,” https://en.wikipedia.org/wiki/Extract, transform, load, 2019, online; accessed 30 May 2019

2019
[12]

A relational model of data for large shared data banks,

E. F. Codd, “A relational model of data for large shared data banks,” Communications of the ACM , vol. 13, no. 6, pp. 377–387, 1970

1970
[13]

Chodorow, MongoDB: the deﬁnitive guide: powerful and scalable data storage

K. Chodorow, MongoDB: the deﬁnitive guide: powerful and scalable data storage. ” O’Reilly Media, Inc.”, 2013

2013
[15]

Cassandra: a decentralized structured storage system,

A. Lakshman and P. Malik, “Cassandra: a decentralized structured storage system,” ACM SIGOPS Operating Systems Review, vol. 44, no. 2, pp. 35–40, 2010

2010
[16]

Mapreduce: simpliﬁed data processing on large clusters,

J. Dean and S. Ghemawat, “Mapreduce: simpliﬁed data processing on large clusters,”Communications of the ACM, vol. 51, no. 1, pp. 107–113, 2008

2008
[17]

The hadoop distributed ﬁle system

K. Shvachko, H. Kuang, S. Radia, R. Chansler et al., “The hadoop distributed ﬁle system.” in MSST, vol. 10, 2010, pp. 1–10

2010
[18]

Spark: Cluster computing with working sets

M. Zaharia, M. Chowdhury, M. J. Franklin, S. Shenker, and I. Stoica, “Spark: Cluster computing with working sets.” HotCloud, vol. 10, no. 10-10, p. 95, 2010

2010
[19]

Bootstrapping privacy compliance in big data systems,

S. Sen, S. Guha, A. Datta, S. K. Rajamani, J. Tsai, and J. M. Wing, “Bootstrapping privacy compliance in big data systems,” in 2014 IEEE Symposium on Security and Privacy. IEEE, 2014, pp. 327–342. 12

2014
[20]

Formal concept analysis,

“Formal concept analysis,” https://en.wikipedia.org/wiki/Formal concept analysis, 2019, online; accessed 30 May 2019

2019
[21]

Nielson, H

F. Nielson, H. R. Nielson, and C. Hankin, Principles of program analysis. Springer, 2015

2015
[22]

Privacy issues and data protection in big data: A case study analysis under gdpr,

N. Gruschka, V . Mavroeidis, K. Vishi, and M. Jensen, “Privacy issues and data protection in big data: A case study analysis under gdpr,” in2018 IEEE International Conference on Big Data (Big Data). IEEE, 2018, pp. 5027–5033

2018
[23]

How to make privacy policies both gdpr-compliant and usable,

K. Renaud and L. A. Shepherd, “How to make privacy policies both gdpr-compliant and usable,” in 2018 International Conference On Cyber Situational Awareness, Data Analytics And Assessment (Cyber SA). IEEE, 2018, pp. 1–8

2018
[24]

Forgetting personal data and revoking consent under the gdpr: Challenges and proposed solutions,

E. Politou, E. Alepis, and C. Patsakis, “Forgetting personal data and revoking consent under the gdpr: Challenges and proposed solutions,”Journal of Cybersecurity, vol. 4, no. 1, p. tyy001, 2018

2018
[25]

Conceptual representation of the gdpr: Model and application directions,

J. Tom, E. Sing, and R. Matulevi ˇcius, “Conceptual representation of the gdpr: Model and application directions,” in International Conference on Business Informatics Research. Springer, 2018, pp. 18–28

2018
[26]

Data-purpose algebra: Modeling data usage policies,

C. Hanson, T. Berners-Lee, L. Kagal, G. J. Sussman, and D. Weitzner, “Data-purpose algebra: Modeling data usage policies,” inEighth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’07). IEEE, 2007, pp. 173–177

2007
[27]

Formalizing and enforcing purpose restrictions in privacy policies,

M. C. Tschantz, A. Datta, and J. M. Wing, “Formalizing and enforcing purpose restrictions in privacy policies,” in 2012 IEEE Symposium on Security and Privacy. IEEE, 2012, pp. 176–190

2012
[28]

Privacy promises that can be kept: a policy analysis method with application to the hipaa privacy rule,

O. Chowdhury, A. Gampe, J. Niu, J. von Ronne, J. Bennatt, A. Datta, L. Jia, and W. H. Winsborough, “Privacy promises that can be kept: a policy analysis method with application to the hipaa privacy rule,” in Proceedings of the 18th ACM symposium on Access control models and te...

2013
[29]

Declarative privacy policy: ﬁnite models and attribute- based encryption,

P. E. Lam, J. C. Mitchell, A. Scedrov, S. Sundaram, and F. Wang, “Declarative privacy policy: ﬁnite models and attribute- based encryption,” in Proceedings of the 2nd ACM SIGHIT International Health Informatics Symposium . ACM, 2012, pp. 323–332

2012
[30]

Lpl, towards a gdpr-compliant privacy language: Formal deﬁnition and usage,

A. Gerl, N. Bennani, H. Kosch, and L. Brunie, “Lpl, towards a gdpr-compliant privacy language: Formal deﬁnition and usage,” inTransactions on Large-Scale Data-and Knowledge-Centered Systems XXXVII. Springer, 2018, pp. 41–80

2018
[31]

Temporal mode-checking for runtime monitoring of privacy policies,

O. Chowdhury, L. Jia, D. Garg, and A. Datta, “Temporal mode-checking for runtime monitoring of privacy policies,” in International Conference on Computer Aided Veriﬁcation. Springer, 2014, pp. 131–149

2014
[32]

Assessment of menstrual health status and evolution through mobile apps for fertility awareness,

L. Symul, K. Wac, P. Hillard, and M. Salathe, “Assessment of menstrual health status and evolution through mobile apps for fertility awareness,”bioRxiv, 2019. [Online]. Available: https://www.biorxiv.org/content/early/2019/01/28/385054

2019
[33]

Predicting pregnancy using large-scale data from a women’s health tracking mobile application,

B. Liu, S. Shi, Y . Wu, D. Thomas, L. Symul, E. Pierson, and J. Leskovec, “Predicting pregnancy using large-scale data from a women’s health tracking mobile application,”arXiv preprint arXiv:1812.02222, 2018

2018 arXiv
[34]

Do sexually transmitted infections exacerbate negative premenstrual symptoms? Insights from digital health,

A. Alvergne, M. Vlajic Wheeler, and V . Hgqvist Tabor, “Do sexually transmitted infections exacerbate negative premenstrual symptoms? Insights from digital health,” Evolution, Medicine, and Public Health , vol. 2018, no. 1, pp. 138–150, 07 2018. [Online]. Available: https://do...

2018 doi

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [1]

The 18 biggest data breaches of the 21st century,

“The 18 biggest data breaches of the 21st century,” https://www.csoonline.com/article/2130877/ the-biggest-data-breaches-of-the-21st-century.html, 2019, online; accessed 23 May 2019

work page arXiv 2019

[2] [2]

Risk and anxiety: A theory of data-breach harms,

D. J. Solove and D. K. Citron, “Risk and anxiety: A theory of data-breach harms,” Tex. L. Rev., vol. 96, p. 737, 2017

work page 2017

[3] [3]

Insider threat 2018 report,

“Insider threat 2018 report,” https://www.ca.com/content/dam/ca/us/ﬁles/ebook/insider-threat-report.pdf, 2019, online; accessed 23 May 2019

work page 2018

[4] [4]

The use and abuse of computerized information: Striking a balance between personal privacy interests and organizational information needs,

L. E. Murdock, “The use and abuse of computerized information: Striking a balance between personal privacy interests and organizational information needs,”Alb. L. Rev., vol. 44, p. 589, 1979

work page 1979

[5] [5]

The eu general data protection regulation (gdpr),

“The eu general data protection regulation (gdpr),” https://eugdpr.org/, 2019, online; accessed 16 April 2019

work page 2019

[6] [6]

California consumer privacy act (ccpa),

“California consumer privacy act (ccpa),” https://www.caprivacy.org/, 2019, online; accessed 16 April 2019

work page 2019

[7] [7]

The family educational rights and privacy act of 1974 (ferpa),

“The family educational rights and privacy act of 1974 (ferpa),” https://www.colorado.edu/registrar/students/records/ferpa, 2019, online; accessed 16 April 2019

work page 1974

[8] [8]

Health insurance portability and accountability act (hipaa),

“Health insurance portability and accountability act (hipaa),” https://searchhealthit.techtarget.com/deﬁnition/HIPAA, 2019, online; accessed 16 April 2019

work page 2019