{"id":"ca41b094-449b-409c-9be8-9b5384c5eee7","arxiv_id":"2506.17317","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Automated testing of Google Workspace add-on APIs found 41 host APIs that allow permission escalation beyond the installing user's role.","lead":"A new automated tool called TAI tested hundreds of Google Workspace add-on APIs and found 41 that can let add-ons do things their human user is not allowed to do, like reading hidden spreadsheet data. The findings suggest Google's permission checks for add-ons are looser than the checks applied to normal users.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Pass/fail is 'no error message' (§IV-C3); the 21 E3 sharing-modification APIs are never checked for actual side effects, so silently no-oped unauthorized calls are counted as risky, inflating the 41-API claim.","rationale":"I read the paper in good faith. The authors build a real artifact, test in a controlled workspace with test accounts, disclose findings ethically, and manually filter 54 candidates down to 41 to remove null/encrypted retrieval false positives. Those are genuine strengths. The reader's CONDITIONAL verdict is appropriate because the artifact is not released and the execution-status criterion is fragile. My stress-test pass converges on the same weakest assumption but sharpens it: the under-specified point is not only silent no-ops for retrieval APIs, but unverified side effects for the E3 modification APIs that constitute the majority of reported risks (21 of 41). An unauthorized modification that is silently ignored would be recorded as a success, and the paper provides no post-condition check for these cases. The independent count inconsistency (17 E2 + 21 E3 = 38, not 41) is a smaller but real internal-audit problem: it means the headline number is not reproducible from the paper's own text, and the missing API list prevents any external recheck. Neither issue makes me think the central finding is false; both make it unverifiable from the manuscript alone. The proposed test—re-running the E3 candidates with pre/post state read-backs—would settle the concern: if the state changes, the concern is resolved and the paper's conditional acceptance is justified; if not, the count should be revised and the verdict should move toward REJECT or UNVERDICTED until the list and artifact are released. I therefore leave the verdict unchanged rather than escalating on speculation.","tokens_in":16129,"tokens_out":3492,"duration_ms":41198,"concrete_test":"Obtain or reconstruct the 54 candidate APIs. For each of the 21 E3 candidates, instrument the test add-on to (a) log the full return value and (b) read back the sharing configuration before and after the call under a viewer/commenter account, e.g., via DriveApp.getFileById(...).getSharingAccess() and getEditors()/getViewers(). Re-classify an API as risky only if a post-condition actually changed or a returned value exposes content the role cannot access. For the protected-range case, read back the target cell value after the add-on call to confirm the edit was committed, not merely that no exception was thrown. If any E3 candidate shows no observable state change, the 41 count should be reduced accordingly.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim of 41 risky APIs rests on the execution-status classifier in Section IV-C3: 'API executions that do not return any error messages are deemed successfully executed and pass the testing process.' The follow-up manual inspection described in Section IV-D covers only retrieval APIs ('verifying whether APIs designed to retrieve information return valid responses (as opposed to NULL or encrypted text)'). For the 21 E3 sharing-modification APIs, and for the protected-range edition case study, the load-bearing evidence is the absence of an error message rather than a verified state change. Google Apps Script can return without error while silently failing to commit a mutation when authorization is lacking, when the operation is a no-op, or when the invoked method is deprecated. If even a few of the 21 E3 candidates fall into this category, the headline count of 41 overstates the permission-escalation landscape. The reported breakdown also adds inconsistently: Section V-C states 17 APIs pose E2 risks and 21 pose E3 risks, which sums to 38, not 41, and no overlap is explained; without the list of the 41 APIs, the reader cannot audit which APIs are double-counted or whether the missing entries were false positives. Because the full API list is not released, the pass/fail criterion cannot be checked independently per API.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":16420,"tokens_out":6216,"duration_ms":72782,"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":[{"comment":"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":"Section IV-C3 and IV-D"},{"comment":"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.","section":"Section V-C"}],"minor_comments":[{"comment":"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":"Section II-B and Definition II.1"},{"comment":"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":"Section I"},{"comment":"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":"Section V-C"},{"comment":"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":"Section VI-A"},{"comment":"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.","section":"Section III and Table I"}],"recommendation":"major_revision","confidential_remarks":"The paper is within scope for a security venue and the tooling idea is timely, but the empirical claim needs to be supported by per-API release and side-effect verification. I would not accept the current version because the central 41-API count rests on a criterion that has not been validated for mutation APIs. If the authors can address the two major comments with an artifact and additional verification, the paper could be a solid contribution."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nThe 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.\n\nThere'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.\n\nNone 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.","headline":"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.","tokens_in":16920,"tokens_out":2192,"would_cite":false,"duration_ms":24435,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Add-ons can bypass Google Workspace role checks through 41 host APIs.","keywords":["team workspaces","add-on security","permission escalation","Google Workspace","host API testing","access control","OAuth scope","multi-user roles"],"falsifier":"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.","tokens_in":15970,"feed_emoji":"🔓","tokens_out":6025,"duration_ms":62322,"temperature":0.7,"pith_summary":"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.","feed_headline":"Add-ons slip past Workspace role checks via 41 APIs","feed_subtitle":"Automated testing of 4,523 APIs shows viewers can read hidden values and editors can edit protected ranges.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Prior manual security analysis of Google Workspace roles that this work formalizes and extends with automated testing.","marker":"[4]"},{"why":"User-perception study of third-party app access used to motivate the threat model.","marker":"[5]"},{"why":"Official Apps Script API documentation that TAI crawls to build the API hierarchy and test cases.","marker":"[9]"},{"why":"Analysis of app extensions in team chat systems whose flat REST API model contrasts with the hierarchical APIs TAI must handle.","marker":"[10]"},{"why":"Experimental security analysis of collaboration-platform app models that frames the same class of delegation risk.","marker":"[11]"},{"why":"The gpt-4o-mini model used to classify API permission groups and generate parameters.","marker":"[14]"},{"why":"Google issue tracker entry documenting that transferOwnership() is blocked, supporting the E3 finding that add-ons should not modify roles.","marker":"[19]"},{"why":"Bitsquatting study used to argue the placeholder-file replacement attack is practical.","marker":"[20]"}],"fun_headline_variants":["41 Add-on APIs break Workspace permission walls","Viewer add-ons read hidden data in Google Workspace","TAI finds 41 permission-escalation flaws in Workspace add-ons","Editors can edit protected ranges via add-on APIs","Workspace add-ons: 41 APIs bypass role checks"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["41 Add-on APIs break Workspace permission walls","Viewer add-ons read hidden data in Google Workspace","TAI finds 41 permission-escalation flaws in Workspace add-ons","Editors can edit protected ranges via add-on APIs","Workspace add-ons: 41 APIs bypass role checks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000648,"raw_usage":{"total_tokens":3015,"prompt_tokens":1026,"completion_tokens":1989,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":642,"completion_tokens_details":{"reasoning_tokens":1904}},"tokens_in":642,"tokens_out":1989,"duration_ms":15198,"temperature":1.0,"reasoning_tokens":1904,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T23:54:38.498798+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Is it safe to share your files? an empirical security analysis of google workspace,","cited_arxiv_id":null,"evidence_quote":"Prior manual security analysis of Google Workspace roles that this work formalizes and extends with automated testing."},{"cited_title":"Security and privacy perceptions of Third-Party application access for google accounts,","cited_arxiv_id":null,"evidence_quote":"User-perception study of third-party app access used to motivate the threat model."},{"cited_title":"Add-ons types,","cited_arxiv_id":null,"evidence_quote":"Official Apps Script API documentation that TAI crawls to build the API hierarchy and test cases."},{"cited_title":"Hazard integrated: Understanding the security risks of app extensions on team chat systems,","cited_arxiv_id":null,"evidence_quote":"Analysis of app extensions in team chat systems whose flat REST API model contrasts with the hierarchical APIs TAI must handle."},{"cited_title":"Experimental security analysis of the app model in business collabora- tion platforms,","cited_arxiv_id":null,"evidence_quote":"Experimental security analysis of collaboration-platform app models that frames the same class of delegation risk."},{"cited_title":"Models: Learn about the diverse set of models that power the openai api","cited_arxiv_id":null,"evidence_quote":"The gpt-4o-mini model used to classify API permission groups and generate parameters."},{"cited_title":"Api: Consent is required to transfer ownership of a file to another user [error=403],","cited_arxiv_id":null,"evidence_quote":"Google issue tracker entry documenting that transferOwnership() is blocked, supporting the E3 finding that add-ons should not modify roles."},{"cited_title":"Bitsquatting: Exploiting bit-flips for fun, or profit?","cited_arxiv_id":null,"evidence_quote":"Bitsquatting study used to argue the placeholder-file replacement attack is practical."}],"review_version":1}