Beyond the Scope: Security Testing of Permission Management in Team Workspace

Chuan Yan; Guangdong Bai; Haoyu Wang; Jin Song Dong; Kailong Wang; Liuhuo Wan; Mark Huasong Meng

REVIEW 2 major objections 5 minor 40 references

Beyond the Scope: Security Testing of Permission Management in Team Workspace

T0 review · 2 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read Add-ons can bypass Google Workspace role checks through 41 host APIs.

desk verdict A useful automated scan of Google Workspace add-on APIs with credible case studies, but the headline count of 41 risky APIs rests on an execution-status test that likely overcounts. read the letter →

arxiv 2506.17317 v1 pith:DSIMZMCK submitted 2025-06-18 cs.CR

Liuhuo Wan , Chuan Yan , Mark Huasong Meng , Kailong Wang , Haoyu Wang , Guangdong Bai , Jin Song Dong This is my paper · ORCID

classification cs.CR

keywords teamworkspacesadd-onsecuritypermissionescalationGoogleWorkspacehostAPItestingaccesscontrolOAuthscopemulti-userroles

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

Team workspaces promise that an add-on installed by a collaborator inherits that collaborator's limits. The paper argues this promise breaks at the API level: many host APIs execute successfully for a low-privileged user's add-on even when the same action is forbidden to the user. To show this, the paper builds TAI, a tool that generates and runs API test cases across Google Workspace roles, and it identifies 41 such risky APIs. If correct, this turns permission escalation into a systematic, findable property rather than a one-off bug.

What carries the argument

The central object is the two-level permission model $P_{addon} \subseteq P_{authen} \subseteq P_{user} \subseteq P_{owner}$, with permission escalation defined as a violation of that inclusion chain. TAI operationalizes the model: it builds an API dependency graph from official documentation, classifies each API into one of five permission groups using a language model, generates valid parameter values from tutorials, graph traversal, and a string attribute table, then executes each API under different OAuth scopes and user roles, pruning dependent APIs after any failure. The absence of an error message is treated as success, so the tool flags APIs whose execution succeeds despite the caller's role lacking the corresponding right.

What would settle it

Take the 41 flagged APIs, run each with a fresh viewer, commenter, or editor account, and inspect the actual returned value and the object state: for example, call Range.getCell() on a hidden sheet and check whether the returned value is the real hidden content, or call the protected-range editing API and check whether the cell value actually changes. Any API that returns null, an error, or an unchanged document is a false positive; if all 41 return real data or real state changes, the paper's central claim survives.

Watch

Extended reading notes

Core claim

On Google Workspace, the paper claims, permission escalation through add-ons is real and systematic. TAI crawled 4,523 documented APIs across seven host applications, pruned the space to 1,176 testable calls, and executed them under owner, viewer, commenter, and editor roles with different OAuth scopes. It flagged 54 potentially risky APIs, and after manual inspection 41 remained: 17 user-role escalations (E2) and 21 sharing-configuration escalations (E3), with zero OAuth-scope escalations (E1). The confirmed APIs cluster in Spreadsheets (15), Drive (14), Document (6), Slides (4), and Forms (2), with none in Calendar or Gmail. The paper demonstrates three concrete attacks with these APIs: hidden value leakage, where a viewer's add-on reads hidden salary data; protected range editing, where a common editor's add-on edits cells in a protected range; and modification of user subjects, where an add-on changes collaborator roles without the administrator. The paper also notes that OneDrive uses the same two-level model and is vulnerable to E1 and E2 but resists E3.

Load-bearing premise

The scan counts an API call as successful whenever Google returns no error message, so a silently ignored unauthorized call or an empty response would be recorded as a pass and could change the final count.

Editorial extensions

If this is right

A viewer's add-on can recover hidden spreadsheet rows, columns, and sheets that the viewer cannot see through the UI.
A common editor without privileged-editor status can edit cell values inside a protected range, even though ungrouping the range fails.
Twenty-one host APIs let an add-on modify sharing configuration, such as adding collaborators or changing roles, without administrator action.
OAuth permission scopes are enforced: none of the 41 risky APIs is an OAuth-level escalation, so the gap is in role consistency, not in the token grant.
Calendar and Gmail show zero confirmed risky APIs, and OneDrive is robust against sharing-role modification because it blocks add-ons from changing user roles.

Reading between the lines

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

Beyond the paper itself, the 41-API list is a snapshot; re-running the same scan on current Workspace would show which APIs Google has since patched, so the result doubles as a regression test for the platform.
Beyond the paper itself, the success criterion of 'no error message' means counts could shift if Google ever returns silent nulls; checking actual returned values for each flagged API would make the 41 a firmer number.
Beyond the paper itself, the placeholder-file replacement attack likely generalizes to other file-hosting platforms that copy sharing settings on version replacement, though only Google Workspace is demonstrated here.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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

Quick take: the paper builds TAI, an automated tester for Google Apps Script host APIs under different user roles, and reports 41 risky APIs. The tool's dependency-graph test case generation is a real step beyond the manual analyses in earlier work. The three case studies—hidden sheet recovery via Range.getCell(), editing protected ranges as a common editor, and silently modifying sharing roles—are concrete and, on their face, credible. Those demonstrations alone are worth a security reader's time.

The soft spots are in the measurement, not the idea. The pass/fail criterion in IV-C3 is absence of an error message. That's fine for retrieval APIs where the manual filtering in IV-D checks for null or encrypted responses, but for the 21 E3 sharing-modification APIs there's no check that the modification actually happened. If Google no-ops an unauthorized mutation without error, TAI counts it as risky. So the E3 subset, and therefore the headline 41, is likely inflated. The reported breakdown also doesn't add up: 17 E2 plus 21 E3 is 38, not 41, and the paper doesn't explain overlap or double counting. Without the full list of 41 APIs, a referee can't audit that discrepancy. The tool is not released either.

There's also a scope overreach: the evaluation is only on Google Workspace, yet the title and abstract say 'team workspaces' generally. OneDrive appears only in a high-level table, not in the testing.

None of this kills the paper. The core finding—add-ons can bypass role checks in ways ordinary users cannot—is supported by the case studies, which are direct experiments rather than definitions. The numbers just need to be tightened, and the E3 verification needs side-effect checks. I'd send it to peer review, but with the expectation that the authors provide the full API list, reconcile the counts, and either verify E3 side effects or downgrade those claims. The right audience is the cloud- and access-control community, and the paper deserves referee time.

Referee Report

2 major / 5 minor

Summary. The paper studies permission escalation by third-party add-ons in team workspaces, focusing on Google Workspace. It formalizes three attack scenarios: OAuth-scope escalation (E1), user-role escalation (E2), and sharing-configuration escalation (E3). It presents TAI, an automated tool that crawls API documentation, builds dependency graphs, generates parameterized test cases, and invokes APIs under multiple user roles to detect violations. The evaluation on 4,523 APIs reports 41 risky APIs across Documents, Drive, Forms, Spreadsheets, and Slides, with case studies on hidden-value leakage, protected-range editing, and sharing-role modification. The paper also discusses a file-replacement sharing attack and proposes countermeasures.

Significance. If substantiated, the result is a useful first systematic map of add-on permission escalation in a major workspace platform. The main contribution is the tool pipeline: handling the hierarchical API dependency structure, generating context-sensitive parameters from tutorials and graph traversal, and pruning test sequences. The concrete case studies, especially row.getCell() recovering hidden values, are plausible and demonstrate a real discrepancy between user-role checks and add-on API checks. The manual validation of permission categorization (99% on a 200-API sample) and test-case generation (100% for no-parameter/tutorial cases) is a positive sign. However, the paper's headline 41-API count is not yet fully supported: the execution-status criterion is 'no error message', the full API list is not disclosed, and the E2/E3 totals do not add to 41. These issues prevent me from treating the landscape claim as established at this stage.

major comments (2)

[Section IV-C3 and IV-D] The pass/fail criterion for the automated scan is that an API invocation that does not return an error message is deemed successful (Section IV-C3). This may be adequate for retrieval APIs, and the manual filtering in Section IV-D explicitly checks that retrieval APIs return non-NULL, non-encrypted data. However, the manual check is not applied to the 21 E3 sharing-modification APIs or to the protected-range editing case study in Section V-C. For mutation APIs, the load-bearing evidence of permission escalation is a state change (e.g., a sharing setting actually altered, a protected cell value actually written); absence of an error does not establish that the mutation was committed, because a silently no-op or deprecated call can also return normally. The paper should verify side effects after each mutation test, or provide per-API evidence that the state changed, before the 41-API claim is taken at face value.
[Section V-C] The reported numbers are internally inconsistent. Table V lists 41 risky APIs (0+6+14+0+2+15+4), but the text states that 17 APIs pose E2 risks and 21 pose E3 risks, with none classified as E1; 17+21=38. If some APIs are counted in both E2 and E3, that overlap should be stated; otherwise three APIs are missing from the scenario breakdown. In addition, the paper does not provide the list of the 41 APIs, their host applications, or their scenario labels, so a reader cannot audit the false-positive filtering or reproduce the classification. I request that the full API list be included as an appendix or artifact, with per-API evidence of the observed behavior.

minor comments (5)

[Section II-B and Definition II.1] The role set is written as S={O,E,C,V}, which has four elements, but the text says 'five user roles' (and Section III and Section IV-C2 refer to five accounts/profiles). Please reconcile whether the owner is counted as a fifth role and whether owner-role tests were performed.
[Section I] There are several grammar and capitalization issues throughout, such as 'We systematically test' beginning with a capital W after a comma and 'a add-on' instead of 'an add-on'; a careful proofread would improve readability.
[Section V-C] In the hidden-sheet case study, the sentence 'an attacker without proper permissions (editor in this case)' is confusing because the preceding text describes a viewer; please clarify which role is used to recover the hidden sheet.
[Section VI-A] The file-replacement sharing attack is discussed as a risk but is not produced by TAI and is not demonstrated in this paper; it should be clearly labeled as a hypothetical attack built on prior work, not as one of the 41 findings.
[Section III and Table I] The claim that Microsoft OneDrive is robust against E3 because it prohibits add-ons from modifying user roles is stated without direct testing or a citation to documentation; either add an analogous experiment or a precise reference to Microsoft's policy.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: TAI's 41-API finding is an empirical black-box result, not forced by the paper's definitions or by the [4] self-citation.

full rationale

The paper's central claim—that 41 host APIs enable permission escalation—is produced by executing 1,176 API test cases against Google Workspace and recording runtime outcomes, not by algebraic manipulation of the paper's own definitions. The E1/E2/E3 scenarios in Section II-C are threat-model predicates, while Section IV-C3 operationalizes 'success' as absence of an error message; this is an empirical oracle, and its weakness (e.g., silent no-ops or non-error placeholder responses) is a verification and correctness risk, not a circular reduction. The only notable self-citation, [4] (the authors' earlier manual study of Google Workspace), supplies motivation and a user-side baseline, but the paper independently re-derives the needed user-role permissions through an eight-hour manual review by two authors (Section IV-A), and the 41 risky APIs are then filtered from automated black-box tests plus manual inspection of returned values (Section IV-D). No uniqueness theorem, ansatz, or fitted parameter is imported from [4] or any other self-cited work. The internal inconsistency in Section V-C (17 E2 + 21 E3 = 38, not 41) and the non-disclosure of the full API list are auditability concerns, but they do not show that the derivation is equivalent to its inputs by construction. The derivation chain is therefore self-contained with respect to the paper's empirical methodology.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central claim rests on the authors' model of Google's permission system, the assumption that error-free execution equals permission granted, and the completeness of their three escalation scenarios. There are no fitted numerical parameters or invented entities; the tool TAI is a measurement instrument, not a postulated entity.

assumptions (3)

domain assumption Team workspaces enforce a two-level permission system: OAuth scope checking followed by installer role checking.
Stated in Section II-B and Figure 2; if this model is incomplete, the three escalation scenarios may miss or mislabel real enforcement failures.
domain assumption An API invocation that returns no error message is deemed to have succeeded and to have been permitted.
Section IV-C3 establishes the pass/fail criterion. Silent no-ops or suppressed errors would create false positives.
ad hoc to paper The three predefined scenarios E1, E2, E3 capture all relevant permission escalation risks.
Section II-C defines the attack model; Section VI-C acknowledges TAI cannot detect violations outside these criteria.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Beyond the Scope: Security Testing of Permission Management in Team Workspace." pith.science (2026). https://pith.science/paper/DSIMZMCK

@misc{pith2026250617317,
  author       = {Pith},
  title        = {Pith review of: Beyond the Scope: Security Testing of Permission Management in Team Workspace},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DSIMZMCK}},
  note         = {Machine review of arXiv:2506.17317}
}

read the original abstract

Nowadays team workspaces are widely adopted for multi-user collaboration and digital resource management. To further broaden real-world applications, mainstream team workspaces platforms, such as Google Workspace and Microsoft OneDrive, allow third-party applications (referred to as add-ons) to be integrated into their workspaces, significantly extending the functionality of team workspaces. The powerful multi-user collaboration capabilities and integration of add-ons make team workspaces a central hub for managing shared resources and protecting them against unauthorized access. Due to the collaboration features of team workspaces, add-ons involved in collaborations may bypass the permission isolation enforced by the administrator, unlike in single-user permission management. This paper aims to investigate the permission management landscape of team workspaces add-ons. To this end, we perform an in-depth analysis of the enforced access control mechanism inherent in this ecosystem, considering both multi-user and cross-app features. We identify three potential security risks that can be exploited to cause permission escalation. We then systematically reveal the landscape of permission escalation risks in the current ecosystem. Specifically, we propose an automated tool, TAI, to systematically test all possible interactions within this ecosystem. Our evaluation reveals that permission escalation vulnerabilities are widespread in this ecosystem, with 41 interactions identified as problematic. Our findings should raise an alert to both the team workspaces platforms and third-party developers.

Figures

Figures reproduced from arXiv: 2506.17317 by the authors.

**Figure 1.** Permission delegation demonstration To comprehensively evaluate the underlying permission escalation problem caused by the add-ons, We systematically test and analyze the add-ons’ capability to utilize host APIs for achieving permission escalation. Specifically, we develop a tool named TAI to automatically generate test cases and evaluate the add-ons’ capability under different permission scopes. TAI identifies 41 r… view at source ↗

**Figure 2.** Access control mechanisms in the current ecosystem Subjects. In total, team workspaces defines three types of subjects: (1) the owner of the object, (2) collaborators on the object (may be viewer, commenter or editor), and (3) add-ons that can access predefined objects. Permissions. We represent each permission in team workspaces using a tuple (subject, operation, object), which indicates who (the subject) can perfo… view at source ↗

**Figure 3.** Workflow of TAI IV. DESIGN OF TAI As shown in [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: An example of dependency tree of the APIs [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

**Figure 5.** Figure 5: Tutorial code snippets provided by team workspaces [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

**Figure 6.** Figure 6: The API testing phase 2) Test case execution: At the start of each testing cycle, we fetch the candidate test cases (to be tested) and update them into the project portal before execution. We use the Python library pyautogui [16] to simulate various hotkeys and mimic d…

**Figure 7.** Figure 7: Attack: hidden sheet recovery permitted to edit the unprotected ranges. Once the protected range is grouped, common editors are forbidden from editing or ungrouping the whole group. However, our experiment shows that in this scenario, even though common editors are una…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 39 canonical work pages

[1]

Google workspace marketplace,

“Google workspace marketplace,” 2024. [Online]. Available: https: //en.wikipedia.org/wiki/Google_Workspace_Marketplace

work page 2024
[2]

Apps and services,

“Apps and services,” 2024. [Online]. Available: https://www.microsoft. com/en-au/microsoft-365/products-apps-services

work page 2024
[3]

Google workspace user stats (2023),

“Google workspace user stats (2023),” 2024. [Online]. Available: https://explodingtopics.com/blog/google-workspace-stats

work page 2023
[4]

Is it safe to share your files? an empirical security analysis of google workspace,

L. Wan, K. Wang, H. Wang, and G. Bai, “Is it safe to share your files? an empirical security analysis of google workspace,” inProceedings of the ACM Web Conference 2024, 2024

work page 2024
[5]

Security and privacy perceptions of Third-Party application access for google accounts,

D. G. Balash, X. Wu, M. Grant, I. Reyes, and A. J. Aviv, “Security and privacy perceptions of Third-Party application access for google accounts,” in31st USENIX Security Symposium (USENIX Security 22). Boston, MA: USENIX Association, Aug. 2022, pp. 3397–3414. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity22/presentation/balash

work page 2022
[6]

Xss vulnerabilities in cloud-application add-ons,

T. Bui, S. Rao, M. Antikainen, and T. Aura, “Xss vulnerabilities in cloud-application add-ons,” inProceedings of the 15th ACM Asia Conference on Computer and Communications Security, 2020, pp. 610– 621

work page 2020
[7]

Post-gdpr threat hunting on android phones: Dissecting os-level safeguards of user-unresettable identifiers

M. H. Meng, Q. Zhang, G. Xia, Y . Zheng, Y . Zhang, G. Bai, Z. Liu, S. G. Teo, and J. S. Dong, “Post-gdpr threat hunting on android phones: Dissecting os-level safeguards of user-unresettable identifiers.” inNDSS, 2023. 12

work page 2023
[8]

Uncovering cross-context inconsistent access control enforcement in android,

H. Zhou, H. Wang, X. Luo, T. Chen, Y . Zhou, and T. Wang, “Uncovering cross-context inconsistent access control enforcement in android,” inThe 2022 Network and Distributed System Security Symposium (NDSS’22), 2022

work page 2022

Show all 40 references

[9]

Add-ons types,

“Add-ons types,” 2024. [Online]. Available: https://developers.google. com/apps-script/reference/

2024
[10]

Hazard integrated: Understanding the security risks of app extensions on team chat systems,

M. Zha, J. Wanget al., “Hazard integrated: Understanding the security risks of app extensions on team chat systems,” inNetwork and Dis- tributed Systems Security Symposium, 2022, pp. 24–28

2022
[11]

Experimental security analysis of the app model in business collabora- tion platforms,

Y . Chen, Y . Gao, N. Ceccio, R. Chatterjee, K. Fawaz, and E. Fernandes, “Experimental security analysis of the app model in business collabora- tion platforms,” in31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 2011–2028

2022
[12]

Don’t bite off more than you can chew: Investigating excessive permission requests in trigger-action integrations,

L. Wan, K. Wang, K. T. Mahadewa, H. Wang, and G. Bai, “Don’t bite off more than you can chew: Investigating excessive permission requests in trigger-action integrations,” inProceedings of the ACM Web Conference 2024, 2024

2024
[13]

Selenium automates browsers. that’s it!

“Selenium automates browsers. that’s it!” 2024. [Online]. Available: https://www.selenium.dev/

2024
[14]

Models: Learn about the diverse set of models that power the openai api

“Models: Learn about the diverse set of models that power the openai api.” 2024. [Online]. Available: https://platform.openai.com/docs/models

2024
[15]

Build google workspace add-ons,

“Build google workspace add-ons,” 2024. [Online]. Available: https://developers.google.com/apps-script/add-ons/how-tos/ building-workspace-addons

2024
[16]

Pyautogui,

“Pyautogui,” 2025. [Online]. Available: https://pypi.org/project/ PyAutoGUI/

2025
[17]

" if you can’t beat them, join them

H. Harkous and K. Aberer, “" if you can’t beat them, join them" a usabil- ity approach to interdependent privacy in cloud apps,” inProceedings of the Seventh ACM on Conference on Data and Application Security and Privacy, 2017, pp. 127–138

2017
[18]

Taintmini: Detecting flow of sensitive data in mini-programs with static taint analysis,

C. Wang, R. Ko, Y . Zhang, Y . Yang, and Z. Lin, “Taintmini: Detecting flow of sensitive data in mini-programs with static taint analysis,” in 2023 IEEE/ACM 45th International Conference on Software Engineer- ing (ICSE). IEEE, 2023, pp. 932–944

2023
[19]

Api: Consent is required to transfer ownership of a file to another user [error=403],

“Api: Consent is required to transfer ownership of a file to another user [error=403],” 2024. [Online]. Available: https://issuetracker.google. com/issues/228791253

2024
[20]

Bitsquatting: Exploiting bit-flips for fun, or profit?

N. Nikiforakis, S. Van Acker, W. Meert, L. Desmet, F. Piessens, and W. Joosen, “Bitsquatting: Exploiting bit-flips for fun, or profit?” in Proceedings of the 22nd international conference on World Wide Web, 2013, pp. 989–998

2013
[21]

More is less: On the end-to-end security of group chats in signal, whatsapp, and threema,

P. Rösler, C. Mainka, and J. Schwenk, “More is less: On the end-to-end security of group chats in signal, whatsapp, and threema,” in2018 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2018, pp. 415–429

2018
[22]

Under- standing and detecting file knowledge leakage in gpt app ecosystem,

C. Yan, B. Guan, Y . Li, M. H. Meng, L. Wan, and G. Bai, “Under- standing and detecting file knowledge leakage in gpt app ecosystem,” in Proceedings of the ACM on Web Conference 2025, 2025, pp. 3831–3839

2025
[23]

Exploring chatgpt app ecosystem: Distribution, deployment and security,

C. Yan, R. Ren, M. H. Meng, L. Wan, T. Y . Ooi, and G. Bai, “Exploring chatgpt app ecosystem: Distribution, deployment and security,” inPro- ceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 1370–1382

2024
[24]

Authscan: Automatic extraction of web authentication protocols from implementations,

G. Bai, J. Lei, G. Meng, S. S. Venkatraman, P. Saxena, J. Sun, Y . Liu, and J. S. Dong, “Authscan: Automatic extraction of web authentication protocols from implementations,” 2013

2013
[25]

{SSOScan}: automated testing of web appli- cations for single{Sign-On}vulnerabilities,

Y . Zhou and D. Evans, “{SSOScan}: automated testing of web appli- cations for single{Sign-On}vulnerabilities,” in23rd USENIX Security Symposium (USENIX Security 14), 2014, pp. 495–510

2014
[26]

Trends and lessons from three years fighting malicious extensions,

N. Jagpal, E. Dingle, J.-P. Gravel, P. Mavrommatis, N. Provos, M. A. Rajab, and K. Thomas, “Trends and lessons from three years fighting malicious extensions,” in24th USENIX Security Symposium (USENIX Security 15), 2015, pp. 579–593

2015
[27]

You’ve changed: Detecting malicious browser extensions through their update deltas,

N. Pantelaios, N. Nikiforakis, and A. Kapravelos, “You’ve changed: Detecting malicious browser extensions through their update deltas,” inProceedings of the 2020 ACM SIGSAC conference on computer and communications security, 2020, pp. 477–491

2020
[28]

Detection of inconsistencies in privacy practices of browser extensions,

D. Bui, B. Tang, and K. G. Shin, “Detection of inconsistencies in privacy practices of browser extensions,” in2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 2780–2798

2023
[29]

Are they toeing the line? diagnosing privacy compliance violations among browser exten- sions,

Y . Ling, K. Wang, G. Bai, H. Wang, and J. S. Dong, “Are they toeing the line? diagnosing privacy compliance violations among browser exten- sions,” inProceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, 2022, pp. 1–12

2022
[30]

On the quality of privacy policy documents of virtual personal assistant applications,

C. Yan, F. Xie, M. H. Meng, Y . Zhang, and G. Bai, “On the quality of privacy policy documents of virtual personal assistant applications,” Proceedings on Privacy Enhancing Technologies, 2024

2024
[31]

Unauthorized origin crossing on mobile platforms: Threats and mitigation,

R. Wang, L. Xing, X. Wang, and S. Chen, “Unauthorized origin crossing on mobile platforms: Threats and mitigation,” inProceedings of the 2013 ACM SIGSAC conference on Computer & communications security, 2013, pp. 635–646

2013
[32]

Cross miniapp request forgery: Root causes, attacks, and vulnerability detection,

Y . Yang, Y . Zhang, and Z. Lin, “Cross miniapp request forgery: Root causes, attacks, and vulnerability detection,” inProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 3079–3092

2022
[33]

Identity confusion in{WebView-based}mobile app-in-app ecosystems,

L. Zhang, Z. Zhang, A. Liu, Y . Cao, X. Zhang, Y . Chen, Y . Zhang, G. Yang, and M. Yang, “Identity confusion in{WebView-based}mobile app-in-app ecosystems,” in31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 1597–1613

2022
[34]

Some recipes can do more than spoil your appetite: Analyzing the security and privacy risks of ifttt recipes,

M. Surbatovich, J. Aljuraidan, L. Bauer, A. Das, and L. Jia, “Some recipes can do more than spoil your appetite: Analyzing the security and privacy risks of ifttt recipes,” inProceedings of the 26th International Conference on World Wide Web, 2017, pp. 1501–1510

2017
[35]

Practical data access minimization in{Trigger-Action}platforms,

Y . Chen, M. Alhanahnah, A. Sabelfeld, R. Chatterjee, and E. Fernandes, “Practical data access minimization in{Trigger-Action}platforms,” in 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 2929–2945

2022
[36]

Lazytap: On- demand data minimization for trigger-action applications,

M. M. Ahmadpanah, D. Hedin, and A. Sabelfeld, “Lazytap: On- demand data minimization for trigger-action applications,” in2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2023, pp. 3079–3097

2023
[37]

If this then what? controlling flows in iot apps,

I. Bastys, M. Balliu, and A. Sabelfeld, “If this then what? controlling flows in iot apps,” inProceedings of the 2018 ACM SIGSAC conference on computer and communications security, 2018, pp. 1102–1119

2018
[38]

Identifying privacy weaknesses from multi-party trigger-action integration platforms,

K. Mahadewa, Y . Zhang, G. Bai, L. Bu, Z. Zuo, D. Fernando, Z. Liang, and J. S. Dong, “Identifying privacy weaknesses from multi-party trigger-action integration platforms,” inProceedings of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis, 2021, pp. 2–15

2021
[39]

Skillscanner: Detecting policy-violating voice applications through static analysis at the devel- opment phase,

S. Liao, L. Cheng, H. Cai, L. Guo, and H. Hu, “Skillscanner: Detecting policy-violating voice applications through static analysis at the devel- opment phase,” inProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, 2023, pp. 2321–2335

2023
[40]

Investigating documented privacy changes in android os,

C. Yan, M. H. Meng, F. Xie, and G. Bai, “Investigating documented privacy changes in android os,”Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 2701–2724, 2024

2024

Pith tools

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

[1] [1]

Google workspace marketplace,

“Google workspace marketplace,” 2024. [Online]. Available: https: //en.wikipedia.org/wiki/Google_Workspace_Marketplace

work page 2024

[2] [2]

Apps and services,

“Apps and services,” 2024. [Online]. Available: https://www.microsoft. com/en-au/microsoft-365/products-apps-services

work page 2024

[3] [3]

Google workspace user stats (2023),

“Google workspace user stats (2023),” 2024. [Online]. Available: https://explodingtopics.com/blog/google-workspace-stats

work page 2023

[4] [4]

Is it safe to share your files? an empirical security analysis of google workspace,

L. Wan, K. Wang, H. Wang, and G. Bai, “Is it safe to share your files? an empirical security analysis of google workspace,” inProceedings of the ACM Web Conference 2024, 2024

work page 2024

[5] [5]

Security and privacy perceptions of Third-Party application access for google accounts,

D. G. Balash, X. Wu, M. Grant, I. Reyes, and A. J. Aviv, “Security and privacy perceptions of Third-Party application access for google accounts,” in31st USENIX Security Symposium (USENIX Security 22). Boston, MA: USENIX Association, Aug. 2022, pp. 3397–3414. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity22/presentation/balash

work page 2022

[6] [6]

Xss vulnerabilities in cloud-application add-ons,

T. Bui, S. Rao, M. Antikainen, and T. Aura, “Xss vulnerabilities in cloud-application add-ons,” inProceedings of the 15th ACM Asia Conference on Computer and Communications Security, 2020, pp. 610– 621

work page 2020

[7] [7]

Post-gdpr threat hunting on android phones: Dissecting os-level safeguards of user-unresettable identifiers

M. H. Meng, Q. Zhang, G. Xia, Y . Zheng, Y . Zhang, G. Bai, Z. Liu, S. G. Teo, and J. S. Dong, “Post-gdpr threat hunting on android phones: Dissecting os-level safeguards of user-unresettable identifiers.” inNDSS, 2023. 12

work page 2023

[8] [8]

Uncovering cross-context inconsistent access control enforcement in android,

H. Zhou, H. Wang, X. Luo, T. Chen, Y . Zhou, and T. Wang, “Uncovering cross-context inconsistent access control enforcement in android,” inThe 2022 Network and Distributed System Security Symposium (NDSS’22), 2022

work page 2022