Pith. sign in

REVIEW 3 major objections 5 minor 66 references

Privacy policies and Google Play Data Safety labels contradict each other in roughly one of every three disclosures, with sharing far less consistent than collection and sensitive categories hardest hit.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-02 02:03 UTC pith:OOWSOGPD

load-bearing objection A serious, transparent measurement with a real contribution—but the sharing asymmetry needs a sharper sensitivity analysis before the headline numbers are trustworthy. the 3 major comments →

arxiv 2607.14442 v1 pith:OOWSOGPD submitted 2026-07-16 cs.CR

Disclosure Divergence: Measuring Privacy Policy and Data Safety Misalignment at Scale

Mst Eshita Khatun , Lamine Noureddine , Sideeq Bello , Aisha Ali-Gombe This is my paper
classification cs.CR
keywords privacy policiesData Safety labelsGoogle Playdisclosure misalignmentLLM extractionsensitivity risk scoredata sharingAndroid apps
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

This paper tries to establish that the two transparency documents an Android user can consult—the app's formal privacy policy and Google Play's summary Data Safety label—frequently disagree about what happens to user data. Across 6,051 apps, roughly a third of collection and sharing disclosures conflict, and more than 90% of apps have at least one inconsistency in their Data Safety label. The conflicts concentrate in sensitive categories such as personal information, device identifiers, location, and financial data, and sharing is far less consistent than collection even after accounting for chance agreement. If these measurements hold, users who rely on one layer alone get a partial and sometimes misleading picture, and platform-level privacy reporting is in need of structural fixes.

Core claim

The paper's central claim is that privacy policies and Google Play Data Safety labels—both written by the same developers—do not reliably say the same thing about data collection and sharing. Using a unified schema over Google Play's 14 data categories, the two layers disagree for 33% of collection disclosures and 31% of sharing disclosures, and over 90% of apps contain at least one inconsistency in their Data Safety label. Disagreement is asymmetric: the label omits disclosures that appear in the policy far more often than the reverse, and sharing shows much weaker chance-corrected agreement (kappa around 0.16) than collection (kappa around 0.31). The most sensitive categories—personal info

What carries the argument

The analytical engine is a two-layer comparison over a unified schema: each of 14 Google Play data categories is encoded as a binary indicator for two operations—collection and sharing—for both the privacy policy (read by an LLM-based extraction pipeline) and the Data Safety label (scraped from the store). From these indicators the paper computes consistency scores, misalignment scores, a chance-corrected kappa agreement statistic, and per-app cosine similarity between the two layers' disclosure profiles. A Sensitivity Risk Score weights each mismatch by a 1 to 3 sensitivity weight per category (location, personal, financial, health, contacts, audio, photos, web browsing, device IDs at weigh

Load-bearing premise

The central claim depends on the LLM-based extractor reading privacy policies accurately across all 6,051 apps; specifically, the rule that vague 'we may share' statements imply sharing of every category marked as collected could inflate the sharing misalignment that drives the main asymmetry.

What would settle it

Manually annotate the 1,315 policies the paper flags as containing generic sharing statements, replacing the 'share all collected categories' inference with explicit mentions only; if the sharing-versus-collection kappa gap (about 0.16 vs 0.31) shrinks to under 0.10, the central asymmetry and the service-provider loophole conclusion would be undercut. A complementary check would be to instrument a random sample of the high-risk apps and compare observed network traffic with both disclosures to see which layer, if either, reflects reality.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

Share X Bluesky LinkedIn Reddit HN

If this is right

  • With a third of disclosures conflicting, a user who reads only the Data Safety label receives a materially different picture of an app's data practices than a user who reads the full policy.
  • Because over 90% of apps have at least one label inconsistency, routine platform-side verification of labels against policies would flag most of the store for review.
  • Sharing being the weaker layer (kappa about 0.16) means the highest-risk transparency gap is third-party data flows, and label redesign or enforcement should target sharing first.
  • The service-provider loophole implies that 'No data shared with third parties' labels can coexist with real third-party data flows, so the label alone understates sharing in precisely the places users cannot see.
  • Sensitivity-weighted tiers identify a concrete audit target: apps in monitoring-, communication-, and device-control-heavy categories (wearables, remote desktop, health and fitness) are the ones where mismatches concentrate.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • A testable extension is to run the same two-layer consistency check against actual network traffic or static SDK analysis on a sample of the high-risk apps, which would reveal whether the policy, the label, or neither matches real behavior.
  • If platform regulators adopted this kind of consistency score at submission time, the large medium-risk majority would face pressure to align its disclosures, changing the incentive structure that currently lets self-reported labels go unchecked.
  • Because the study compares two self-reports, the reported divergence is a lower bound on the gap users actually face; comparing either layer against runtime behavior could show even larger discrepancies.
  • The paper's own suggested direction—re-crawling the same apps over time—could test whether apps align their labels after public scrutiny, incidents, or enforcement actions, turning a snapshot into a compliance dynamics study.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper proposes a cross-layer measurement framework that compares privacy-policy disclosures (PPD) with Google Play Data Safety Labels (DSL) for 6,051 Android apps, spanning 14 data categories and two operations (collection and sharing). Using an LLM-based extractor extended from Privacify, the authors compute per-app and per-category consistency, Cohen's kappa, a sensitivity-weighted risk score, and qualitative case studies. The main reported findings are micro-level misalignment of 33.1% for collection and 31.1% for sharing, DSL-only misalignment substantially exceeding PPD-only misalignment, Cohen's kappa of 31% vs. 16% for collection vs. sharing, and over 90% of apps with at least one inconsistency. The paper also introduces an SRS tiering in which roughly half of apps are medium risk and evaluates the distribution of risk across app categories. The artifact release is promised via a GitHub repository.

Significance. If the quantitative findings hold, this would be the largest cross-layer comparison of Google Play's two principal transparency artifacts and would identify a concrete structural asymmetry between collection and sharing disclosures, with direct implications for platform auditing and label design. The paper has notable strengths: a large corpus, a clearly specified extraction pipeline, a stratified 100-app validation with F1 scores around 91–92% and annotator agreement κ = 0.78, public artifact release, and explicit sensitivity checks for the SRS alpha parameter. However, the headline sharing-versus-collection asymmetry depends on a conservative inference rule whose validation is currently not independent of the rule itself, and the aggregate estimates lack uncertainty quantification. The central claim is plausible and valuable, but the current evidence is not yet sufficient to support it as stated.

major comments (3)
  1. [§3.1.3 / Appendix G / Eq. (14)] The conservative generic-sharing rule is load-bearing for the paper's central asymmetry finding. When a policy says 'we may share your information' without enumerating categories, the pipeline sets PPD_share equal to PPD_collect. The validation set's ground truth was constructed under the same rule, so the reported F1 ≈ 91% for sharing (§3.1.3, Table 1) cannot detect errors introduced by that rule. Appendix G's ablation is not an adequate sensitivity test: Eq. (14) applies a global multiplier (1 − 1315/6051) to all sharing metrics, which presupposes that all sharing disclosures in those 1,315 apps are artifacts of the rule; a proportional rescaling cannot identify categories that would remain shared under a strict reading. Because the sharing-versus-collection asymmetry (κ = 16% vs 31%; DSL-only sharing misalignment 26.0%) is the central RQ1 result, please provide a non-circular validati
  2. [§4.1, Eq. (10); §3.1.3, Table 1] The headline numeric claims are point estimates from LLM labels with no uncertainty quantification. With N ≈ 6,051 × 14 app–category pairs per operation, even small systematic extraction biases can move the reported misalignment rates and κ values; the validation set has only 100 apps, so the F1 ≈ 91–92% estimate has wide confidence intervals. The paper does not report confidence intervals for the aggregate rates or κ, nor a statistical test for κ(share) < κ(collect). These are needed to support the claim that sharing is 'systematically' less consistent than collection rather than a sampling artifact. Please add bootstrap intervals (resampling apps or app–category pairs) and, if possible, a misclassification sensitivity analysis for sharing extraction.
  3. [§3.3.1, Table 3, §4.3] The SRS tier distribution and the high-risk tail are directly controlled by the sensitivity weights w_c ∈ {1,2,3} and the 0.30/0.70 thresholds. Appendix H varies only α; no sensitivity analysis is given for the weights or thresholds. Since the weights are justified by an informal synthesis of prior work and the thresholds appear arbitrary, the statement that 'about half of apps fall into a medium-risk tier' should be accompanied by a sensitivity check (e.g., alternate weight vectors or threshold shifts), or explicitly framed as an ordinal presentation of the chosen parameterization rather than a calibrated risk level.
minor comments (5)
  1. [Abstract] Typo: 'Elevated privac risk' should be 'privacy risk'.
  2. [§3.3.1, Eq. (11)] MisScore is defined as an app-level score in Eq. (8), but Eq. (11) uses MisScore_i,c^{(o)} as if it were per-category. Please use Mis_{i,c}(o) or define a per-category misalignment term explicitly.
  3. [§4.1] The macro-level statistic 'over 90% of apps contain at least one inconsistency' follows almost mechanically from the micro-level rates over 14 categories; please report the expected rate under independence and avoid presenting it as an additional independent finding.
  4. [§4.2, Fig. 7] The ECDF curves would benefit from confidence bands or error bars, especially the sharing curve concentrated near zero, since it is derived from the same LLM labels as the other findings.
  5. [§5.1] The 'shared but not collected' analysis is based on 3,111 apps without a privacy policy. Please clarify whether this subset is comparable to the 6,051-app analysis set and whether any policy-less apps with this label could be legitimate under Google's definitions.

Circularity Check

0 steps flagged

No significant circularity; central claim is an empirical comparison. Minor self-citation via Privacify and a non-independent validation set lower confidence, but no equation reduces the result to its inputs.

full rationale

The paper's core finding is a large-scale empirical comparison between two separately collected disclosure artifacts: Google Play Data Safety labels are scraped from store listings, while privacy-policy statements are extracted from policy text by an LLM pipeline. The consistency/misalignment indicators in Section 3.2 and the Cohen's kappa computation in Section 3.3 are explicit, data-driven definitions; the reported 33%/31% misalignment rates and the kappa values are computed outcomes, not free parameters fitted to the conclusion. The Sensitivity Risk Score is a defined weighted average with weights taken from prior literature, so RQ3/RQ4 do not reduce to a fitted input. The main self-citation is Privacify [55], which shares an author with the present paper and serves as the LLM extraction backbone; the validation set is author-labeled, so the extractor is not independently benchmarked. This is a legitimate external-validity concern but not a load-bearing circular step: the paper does not invoke a self-cited uniqueness theorem or ansatz to force its conclusion. I also weighed the conservative generic-sharing rule in Section 3.1.3 ('we conservatively treated all data categories marked as collected for that app as shared with third parties') and the Appendix G ablation. That rule can inflate DSL-only sharing misalignment and suppress PPD-only sharing misalignment, and the proportional ablation in Eq. 14 is not a re-extraction test; those are serious threats to the sharing-versus-collection asymmetry claim. However, they are correctness/validity risks rather than circularity: the reported asymmetry is not entailed by the rule alone, because it also depends on the independently scraped DSL data. The validation ground truth was built with the same conservative rule, so Table 1's sharing F1 cannot validate the rule itself; again this weakens the evidence but does not make the paper's derivation equivalent to its inputs. Overall: no formal circular reduction found; score reflects the minor self-citation and non-independent validation, not definitional circularity.

Axiom & Free-Parameter Ledger

3 free parameters · 4 axioms · 0 invented entities

The central measurement rests on design choices (sensitivity weights, alpha, tier thresholds) and on LLM and generic-sharing assumptions. These are the main sources of uncertainty in the reported percentages and risk distribution.

free parameters (3)
  • Sensitivity weights w_c (1/2/3) for 14 categories = 3 for 10 categories, 2 for 2 categories, 1 for 2 categories
    Table 3 assigns hand-picked sensitivity weights to Google Play data categories, informed by prior literature but not independently justified; these weights directly determine SRS scores and tier assignments.
  • Alpha in the weighted overall SRS = 0.6
    Eq. 13; alpha controls the relative weight of sharing versus collection. The authors test 0.4-0.7 and choose 0.6 as a balanced setting, but the value is a design choice that affects the headline tier distribution.
  • Risk-tier thresholds = low < 0.30; medium 0.30-0.70; high >= 0.70
    Thresholds chosen for interpretability; they define the headline result that about half of apps fall into the medium-risk tier.
axioms (4)
  • domain assumption LLM extraction accuracy measured on a 100-app validation set (F1 91-92%) generalizes to all 6,051 apps.
    Section 3.1.3; the full corpus is not independently labeled, so aggregate rates inherit unquantified extraction error.
  • ad hoc to paper Vague sharing statements in a policy ('we may share your information') imply that every category marked as collected is shared with third parties.
    Section 3.1.3; this conservative rule can overstate sharing disclosures and may drive the sharing-versus-collection asymmetry. The Appendix G ablation scales metrics globally rather than re-extracting.
  • domain assumption Binary category-level representation over the 14 Google Play categories preserves enough contextual meaning for consistency measurement.
    Section 5.4 acknowledges this abstraction drops purpose, optionality, retention, and fine-grained distinctions; some partial or conditional disclosures are not fully represented.
  • domain assumption The crawled Data Safety labels and privacy policy URLs are correctly parsed and matched, and the English-only corpus is representative enough for ecosystem-level conclusions.
    Sections 3.1.1-3.1.4; 34% of apps without a privacy policy are excluded from the main analysis, and no geo/language weighting is attempted.

pith-pipeline@v1.3.0-alltime-deepseek · 24444 in / 12265 out tokens · 116162 ms · 2026-08-02T02:03:24.459805+00:00 · methodology

0 comments
Cite this review

Pith. "Pith review of Disclosure Divergence: Measuring Privacy Policy and Data Safety Misalignment at Scale." pith.science (2026). https://pith.science/paper/OOWSOGPD

@misc{pith2026260714442,
  author       = {Pith},
  title        = {Pith review of: Disclosure Divergence: Measuring Privacy Policy and Data Safety Misalignment at Scale},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OOWSOGPD}},
  note         = {Machine review of arXiv:2607.14442}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

With the rapid growth of mobile applications, user data privacy has become an increasing concern. While privacy policies describe how apps collect and share data, platforms such as Google Play provide Data Safety labels intended to summarize these practices. Because these disclosure channels are declared separately, they may present inconsistent representations of app data practices, creating uncertainty for users and regulators. In this work, we conducted a large-scale empirical study of disclosure consistency across 6,051 Android apps. Using an LLM-based extraction framework and a unified schema over 14 Google Play data categories and two operations (collection and sharing), we measure per-app and per-category consistency and introduce a sensitivity-weighted risk score that emphasizes high-risk data types. We find that misalignment disproportionately affects sensitive categories such as personal information and device identifiers, with sharing disclosures exhibiting lower consistency than collection disclosures. Elevated privac risk is concentrated in app categories associated with persistent monitoring and communication. Overall, our findings highlight structural gaps in current disclosure mechanisms and underscore the need for stronger verification and greater transparency in platform-level privacy reporting.

Figures

Figures reproduced from arXiv: 2607.14442 by Aisha Ali-Gombe, Lamine Noureddine, Mst Eshita Khatun, Sideeq Bello.

Figure 1
Figure 1. Figure 1: Cross-layer privacy disclosure analysis pipeline [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overall agreement vs. misalignment rates between [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: PPD vs DSL kappa score by data operation scope [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figure 6
Figure 6. Figure 6: Misalignment rates by data category in privacy [PITH_FULL_IMAGE:figures/full_fig_p008_6.png] view at source ↗
Figure 5
Figure 5. Figure 5: Misalignment rates by data category in Data Safety [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figure 7
Figure 7. Figure 7: ECDF of cosine similarity between privacy policies [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Distribution of apps across risk tiers. The visualization in [PITH_FULL_IMAGE:figures/full_fig_p009_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Risk scores across app categories [PITH_FULL_IMAGE:figures/full_fig_p010_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Distribution of app categories across risk tiers. [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: An Example of Data Safety Label B Data Safety Label Data Structure Example Listing 1: Data Safety label for the Bluesky app { "Bluesky": { "Data shared": { "App info and performance": "Crash logs, Diagnostics, and Other app performance data", "Device or other IDs": "Device or other IDs", "Personal info": "User IDs", "App activity": "App interactions and Other user￾generated content" }, "Data collected": {… view at source ↗
Figure 12
Figure 12. Figure 12: Rating Vs Risk Score [PITH_FULL_IMAGE:figures/full_fig_p017_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Download Vs Risk Score [PITH_FULL_IMAGE:figures/full_fig_p017_13.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

66 extracted references · 1 canonical work pages

  1. [1]

    AccuWeather, Inc. 2025. AccuWeather Privacy Statement. https://www. accuweather.com/en/privacy. Accessed: 27 October. 2025

    2025

  2. [2]

    Erfan Aghasian, Saurabh Garg, Longxiang Gao, Shui Yu, and James Montgomery

  3. [3]

    Mir Masood Ali, David G Balash, Monica Kodwani, Chris Kanich, and Adam J Aviv. 2024. Honesty is the best policy: On the accuracy of apple privacy la- bels compared to apps’ privacy policies. InProceedings on Privacy Enhancing Technologies, Vol. 2024. 142–166

    2024

  4. [4]

    Noura Alomar, Joel Reardon, Aniketh Girish, Narseo Vallina-Rodriguez, Serge Egelman, et al. 2025. The effect of platform policies on app privacy compliance: A study of child-directed apps.Proceedings on Privacy Enhancing Technologies 20253 (2025)

    2025

  5. [5]

    Orlando Amaral, Sallam Abualhaija, Damiano Torre, Mehrdad Sabetzadeh, and Lionel C Briand. 2021. AI-enabled automation for completeness checking of privacy policies.IEEE Transactions on Software Engineering48, 11 (2021), 4647– 4674

    2021

  6. [6]

    Amazon Mobile LLC. 2025. MX Player — Data safety. https://play.google.com/ store/apps/datasafety?id=com.mxtech.videoplayer.ad&hl=en_US. Accessed: 28 October 2025

    2025

  7. [7]

    2019.{PolicyLint}: investigating internal privacy policy contradictions on google play

    Benjamin Andow, Samin Yaseer Mahmud, Wenyu Wang, Justin Whitaker, William Enck, Bradley Reaves, Kapil Singh, and Tao Xie. 2019.{PolicyLint}: investigating internal privacy policy contradictions on google play. In28th USENIX security symposium (USENIX security 19). 585–602

    2019

  8. [8]

    2022.Declare your app’s data use

    Android Developers. 2022.Declare your app’s data use. https://developer.android. com/privacy-and-security/declare-data-use Accessed: 27 Nov. 2025

    2022

  9. [9]

    Android Developers. 2025. Terms of Service and data safety — Play Integrity. https://developer.android.com/google/play/integrity/terms. Accessed: 30 Oct. 2025

    2025

  10. [10]

    Irem Aydin, Hermann Diebel-Fischer, Vincent Freiberger, Julia Möller-Klapperich, Erik Buchmann, Michael Färber, Anne Lauber-Rönsberg, and Birte Platow. 2024. Assessing privacy policies with AI: ethical, legal, and technical challenges.arXiv preprint arXiv:2410.08381(2024)

    Pith/arXiv arXiv 2024

  11. [11]

    California Legislature. 2018. California Consumer Privacy Act of 2018. California Civil Code § 1798.100 et seq.. https://leginfo.legislature.ca.gov/faces/codes_ displaySection.xhtml?lawCode=CIV&sectionNum=1798.100 Also known as the California Consumer Privacy Act (CCPA), as amended, including by the California Privacy Rights Act of 2020 (CPRA)

    2018

  12. [12]

    Rupert Chadwick, Sophie Blundell, and Emily Prendergast. 2024. Assessments of the Privacy Compliance in Commercial Large Language Models. https: //doi.org/10.31219/osf.io/ugmfw Preprint. Accessed: 27 Nov. 2025

    work page doi:10.31219/osf.io/ugmfw 2024

  13. [13]

    Kai Chih Chang, Razieh Nokhbeh Zaeem, and K Suzanne Barber. 2020. A frame- work for estimating privacy risk scores of mobile apps. InInternational Conference on Information Security. Springer, 217–233

    2020

  14. [14]

    Elisa Costante, Yuanhao Sun, Milan Petković, and Jerry den Hartog. 2012. A machine learning solution to assess privacy policy completeness. InProceedings of the 2012 ACM workshop on Privacy in the electronic society. 91–96

    2012

  15. [15]

    European Parliament and of the Council. 2016. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC. Official Journal of the European Union, L 119, 4 May 2016, pp. 1–8...

    2016

  16. [16]

    You don’t need a university degree to comprehend data protection this way

    Vincent Freiberger, Arthur Fleig, and Erik Buchmann. 2025. " You don’t need a university degree to comprehend data protection this way": LLM-Powered Interactive Privacy Policy Assessment. InProceedings of the Extended Abstracts of the CHI Conference on Human Factors in Computing Systems. 1–12

    2025

  17. [17]

    2025.GlobeOne: Get More from Globe – Apps on Google Play

    Globe Telecom. 2025.GlobeOne: Get More from Globe – Apps on Google Play. https://play.google.com/store/apps/datasafety?id=ph.com.globe. globeonesuperapp Data Safety section

    2025

  18. [18]

    Arda Goknil, Femke B Gelderblom, Simeon Tverdal, Shukun Tokas, and Hui Song

  19. [19]

    Alejandra Gómez Ortega, Jacky Bourgeois, and Gerd Kortuem. 2023. What is sensitive about (sensitive) data? Characterizing sensitivity and intimacy with Google assistant users. InProceedings of the 2023 CHI Conference on Human Factors in Computing Systems. 1–16

    2023

  20. [20]

    2025.Provide information for Google Play’s Data safety section

    Google. 2025.Provide information for Google Play’s Data safety section. https: //support.google.com/googleplay/android-developer/answer/10787469 Accessed October 29, 2025

    arXiv 2025

  21. [21]

    Niharika Guntamukkala, Rozita Dara, and Gurdip Grewal. 2015. A machine- learning based approach for measuring the completeness of online privacy poli- cies. In2015 IEEE 14th International Conference on Machine Learning and Applica- tions (ICMLA). IEEE, 289–294

    2015

  22. [22]

    Shin, and Karl Aberer

    Hamza Harkous, Kassem Fawaz, Rémi Lebret, Florian Schaub, Kang G. Shin, and Karl Aberer. 2018. Polisis: Automated Analysis and Presentation of Privacy Policies Using Deep Learning. In27th USENIX Security Symposium (USENIX Security 18). 531–548

    2018

  23. [23]

    Akshath Jain, David Rodriguez, Jose M Del Alamo, and Norman Sadeh. 2023. Atlas: Automatically detecting discrepancies between privacy policies and privacy labels. In2023 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, 94–107

    2023

  24. [24]

    Rishabh Khandelwal, Asmit Nayak, Paul Chung, and Kassem Fawaz. 2023. Com- paring privacy labels of applications in android and ios. InProceedings of the 22nd Workshop on Privacy in the Electronic Society. 61–73

    2023

  25. [25]

    Rishabh Khandelwal, Asmit Nayak, Paul Chung, and Kassem Fawaz. 2024. Un- packing privacy labels: A measurement and developer perspective on google’s data safety section. In33rd USENIX Security Symposium (USENIX Security 24). 2831–2848

    2024

  26. [26]

    Disclosure Divergence: Measuring Privacy Policy and Data Safety Misalignment at Scale

    Mst Eshita Khatun, Lamine Noureddine, Sideeq Bello, and Aisha Ali-Gombe. 2026. Artifacts_PPD_DSL: Artifact for “Disclosure Divergence: Measuring Privacy Policy and Data Safety Misalignment at Scale”. https://github.com/Eshita66/ Artifacts_PPD_DSL. GitHub repository, accessed June 2026

    2026

  27. [27]

    Mugdha Khedkar, Ambuj Kumar Mondal, and Eric Bodden. 2024. Do Android app developers accurately report collection of privacy-related data?. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering Workshops. 176–186

    2024

  28. [28]

    Simon Koch, Malte Wessels, Benjamin Altpeter, Madita Olvermann, and Martin Johns. 2022. Keeping privacy labels honest.Proceedings on Privacy Enhancing Technologies(2022)

    2022

  29. [29]

    Konrad Kollnig, Anastasia Shuba, Max Van Kleek, Reuben Binns, and Nigel Shad- bolt. 2022. Goodbye Tracking? Impact of iOS App Tracking Transparency and Privacy Labels. InProceedings of the 2022 ACM Conference on Fairness, Account- ability, and Transparency (FAccT ’22). ACM, 508–520. https://doi.org/10.1145/ 3531146.3533116

    arXiv 2022

  30. [30]

    Renuka Kumar, Apurva Virkud, Ram Sundara Raman, Atul Prakash, and Roya Ensafi. 2022. A large-scale investigation into geodifferences in mobile apps. In 31st USENIX Security Symposium (USENIX Security 22). 1203–1220

    2022

  31. [31]

    Tianshi Li, Kayla Reiman, Yuvraj Agarwal, Lorrie Faith Cranor, and Jason I Hong. 2022. Understanding challenges for developers to create accurate privacy nutrition labels. InProceedings of the 2022 CHI Conference on Human Factors in Computing Systems. 1–24

    2022

  32. [32]

    Shuang Liu, Baiyang Zhao, Renjie Guo, Guozhu Meng, Fan Zhang, and Meishan Zhang. 2021. Have you been properly notified? automatic compliance analysis of privacy policy text with gdpr article 13. InProceedings of the Web Conference

    2021

  33. [33]

    Keika Mori, Daiki Ito, Takumi Fukunaga, Takuya Watanabe, Yuta Takata, Masaki Kamizono, and Tatsuya Mori. 2025. Evaluating LLMs Towards Automated Assess- ment of Privacy Policy Understandability. InProceedings of the 2025 Symposium on Usable Security and Privacy

    2025

  34. [34]

    Keika Mori, Tatsuya Nagai, Yuta Takata, and Masaki Kamizono. 2022. Analysis of privacy compliance by classifying multiple policies on the web. In2022 IEEE 46th Annual Computers, Software, and Applications Conference (COMPSAC). IEEE, 1734–1741

    2022

  35. [35]

    MX Media and Entertainment Pte Ltd. n.d.. MX Player Privacy Policy. https: //mx.j2inter.com/about/privacy-policy. Accessed: 28 October 2025

    2025

  36. [36]

    Razieh Nokhbeh Zaeem, Safa Anya, Alex Issa, Jake Nimergood, Isabelle Rogers, Vinay Shah, Ayush Srivastava, and K Suzanne Barber. 2020. PrivacyCheck v2: A tool that recaps privacy policies for you. InProceedings of the 29th ACM international conference on information & knowledge management. 3441–3444

    2020

  37. [37]

    Alessandro Oltramari, Dhivya Piraviperumal, Florian Schaub, Shomir Wilson, Sushain Cherivirala, Thomas B Norton, N Cameron Russell, Peter Story, Joel Reidenberg, and Norman Sadeh. 2018. PrivOnto: a semantic framework for the analysis of privacy policies.Semantic Web9, 2 (2018), 185–203

    2018

  38. [38]

    OpenAI. 2025. ChatGPT — Data safety. https://play.google.com/store/apps/ datasafety?id=com.openai.chatgpt&hl=en_US. Accessed: 28 November 2025

    2025

  39. [39]

    OpenAI. 2025. Privacy Policy. https://openai.com/policies/row-privacy-policy/. Accessed: 28 November 2025

    2025

  40. [40]

    OpenAI. 2025. What to Know About a Recent Mixpanel Security Incident. https: //openai.com/index/mixpanel-incident/. Accessed: 28 November 2025

    2025

  41. [41]

    Przemysław Pałka, Francesca Lagioia, R¯uta Liepina, Marco Lippi, and Giovanni Sartor. 2025. Make privacy policies longer and appoint LLM readers.Artificial Intelligence and Law(2025), 1–33

    2025

  42. [42]

    Jielin Qiu, Mengdi Xu, William Han, Seungwhan Moon, and Ding Zhao. 2024. Embodied executable policy learning with language-based scene summarization. 14 Disclosure Divergence: Measuring Privacy Policy and Data Safety Misalignment at Scale Proceedings on Privacy Enhancing Technologies YYYY(X) InProceedings of the 2024 Conference of the North American Chapt...

    2024

  43. [43]

    David Rodriguez, Joseph A Calandrino, Jose M Del Alamo, and Norman Sadeh

  44. [44]

    David Rodriguez, Akshath Jain, Jose M Del Alamo, and Norman Sadeh. 2023. Comparing privacy label disclosures of apps published in both the App Store and Google Play Stores. In2023 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, 150–157

    2023

  45. [45]

    David Rodriguez, Ian Yang, Jose M Del Alamo, and Norman Sadeh. 2024. Large language models: a new approach for privacy policy analysis at scale.Computing 106, 12 (2024), 3879–3903

    2024

  46. [46]

    Neetu Sardana and Arpita Jadhav Bhatt. 2023. iPDS: Computing Privacy Disclo- sure Score for iOS apps and detection of privacy-infringing apps using Machine learning classifiers. InProceedings of the 2023 Fifteenth International Conference on Contemporary Computing. 699–705

    2023

  47. [47]

    Kanthashree Mysore Sathyendra, Shomir Wilson, Florian Schaub, Sebastian Zimmeck, and Norman Sadeh. 2017. Identifying the provision of choices in privacy policy text. InProceedings of the 2017 Conference on Empirical Methods in Natural Language Processing. 2774–2779

    2017

  48. [48]

    Harsh Shah. 2022. Google Play Data Safety: What You Need To Know. https: //clevertap.com/blog/google-play-data-safety/. Accessed: 15 Nov. 2025

    2022

  49. [49]

    Sulayman Sowe, Tobias Kiel, Alexander Neumann, Yongli Mou, Vassilios Peris- teras, and Stefan Decker. 2024. The Design and Implementation of APLOS: An Automated PoLicy DOcument Summarisation System. In2024 2nd International Conference on Foundation and Large Language Models (FLLM). IEEE, 345–356

    2024

  50. [50]

    Chenhao Tang, Zhengliang Liu, Chong Ma, Zihao Wu, Yiwei Li, Wei Liu, Da- jiang Zhu, Quanzheng Li, Xiang Li, Tianming Liu, et al. 2023. PolicyGPT: Auto- mated analysis of privacy policies with large language models.arXiv preprint arXiv:2309.10238(2023)

    Pith/arXiv arXiv 2023

  51. [51]

    Damiano Torre, Sallam Abualhaija, Mehrdad Sabetzadeh, Lionel Briand, Katrien Baetens, Peter Goes, and Sylvie Forastier. 2020. An ai-assisted approach for checking the completeness of privacy policies against gdpr. In2020 IEEE 28th International Requirements Engineering Conference (RE). IEEE, 136–146

    2020

  52. [52]

    Liu Wang, Dong Wang, Shidong Pan, Zheng Jiang, Haoyu Wang, and Yi Wang

  53. [53]

    Shomir Wilson, Florian Schaub, Aswarth Abhilash Dara, Frederick Liu, Sushain Cherivirala, Pedro Giovanni Leon, Mads Schaarup Andersen, Sebastian Zimmeck, Kanthashree Mysore Sathyendra, N Cameron Russell, et al. 2016. The creation and analysis of a website privacy policy corpus. InProceedings of the 54th Annual Meeting of the Association for Computational ...

    2016

  54. [54]

    Shomir Wilson, Florian Schaub, Frederick Liu, Kanthashree Mysore Sathyendra, Daniel Smullen, Sebastian Zimmeck, Rohan Ramanath, Peter Story, Fei Liu, Nor- man Sadeh, et al. 2018. Analyzing privacy policies at scale: From crowdsourcing to automated annotations.ACM Transactions on the Web (TWEB)13, 1 (2018), 1–27

    2018

  55. [55]

    Justin Woodring, Katherine Perez, and Aisha Ali-Gombe. 2024. Enhancing privacy policy comprehension through privacify: A user-centric approach using advanced language models.Computers & Security145 (2024), 103997

    2024

  56. [56]

    In2025 IEEE Symposium on Security and Privacy (SP)

    A big step forward? a user-centric examination of ios app privacy report and enhancements. In2025 IEEE Symposium on Security and Privacy (SP). IEEE, 4210–4228

  57. [57]

    Le Yu, Xiapu Luo, Xule Liu, and Tao Zhang. 2016. Can we trust the privacy policies of android apps?. In2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 538–549

    2016

  58. [58]

    Razieh Nokhbeh Zaeem, Rachel L German, and K Suzanne Barber. 2018. Privacy- check: Automatic summarization of privacy policies using data mining.ACM Transactions on Internet Technology (TOIT)18, 4 (2018), 1–18

    2018

  59. [59]

    Shikun Zhang, Yuanyuan Feng, Yaxing Yao, Lorrie Faith Cranor, and Norman Sadeh. 2022. How Usable Are iOS App Privacy Labels?Proceedings on Privacy Enhancing Technologies2022, 4 (2022), 204–228. https://doi.org/10.56553/popets- 2022-0106

    doi:10.56553/popets- 2022

  60. [60]

    Yutao Wu, Kun Ran, Ming Liu, Adam PA Cardilini, Arif Nurwidyantoro, and Xiao Liu. 2025. CLEAR: Climate Policy Retrieval and Summarization Using LLMs. In Companion Proceedings of the ACM on Web Conference 2025. 2927–2930

    2025

  61. [61]

    Shikun Zhang and Norman Sadeh. 2023. Do Privacy Labels Answer Users’ Privacy Questions?. InProceedings of the Symposium on Usable Security and Privacy (USEC). Internet Society. https://doi.org/10.14722/usec.2023.232482

    arXiv 2023

  62. [62]

    Bluesky": {

    Sebastian Zimmeck, Peter Story, Daniel Smullen, Abhilasha Ravichander, Ziqi Wang, Joel Reidenberg, N Cameron Russell, and Norman Sadeh. 2019. Maps: Scaling privacy compliance analysis to a million apps.Proceedings on privacy enhancing technologies(2019). 15 Proceedings on Privacy Enhancing Technologies YYYY(X) Khatun et al. A Data Safety Label Example Fig...

    2019

  63. [64]

    Shikun Zhang, Lily Klucinec, Kyerra Norton, Norman Sadeh, and Lorrie Faith Cranor. 2024. Exploring{Expandable-Grid} Designs to Make{iOS} App Privacy Labels More Usable. InTwentieth Symposium on Usable Privacy and Security (SOUPS 2024). 139–157

    2024

  64. [2017]

    IEEE access5 (2017), 13118–13130

    Scoring users’ privacy disclosure across multiple online social networks. IEEE access5 (2017), 13118–13130

    2017

  65. [2024]

    Privacy policy analysis through prompt engineering for llms.arXiv preprint arXiv:2409.14879(2024)

    Pith/arXiv arXiv 2024

  66. [2025]

    Privacy Settings of Third-Party Libraries in Android Apps: A Study of Facebook SDKs.Proceedings on Privacy Enhancing Technologies(2025)

    2025