Google Drive Has No API For Declining a Share

This started as a personal annoyance, not a security investigation: a Google account with years of accumulated "Shared with me" clutter from old jobs and one-off collaborations, where "Remove" in the Drive UI never seemed to make anything actually go away for good. That behavior has been reported publicly since at least 2019, usually described as "Remove only hides the item, it still turns up elsewhere." The question here was simpler and more practical: can this be fixed properly, for real, with a script, instead of clicking a button that's historically been unreliable?

Scope and Objective

Target: the public Google Drive API v3, specifically whatever mechanism exists for a user who does not own a file to revoke their own access to it: the API-level equivalent of declining a share.

Objective: build a small tool that calls the correct, documented API operation to do this properly, test it against a real account's real backlog of old shared items, and confirm it actually works, rather than assuming it does.

Method: OAuth-authorized access to a real personal Google account via a purpose-built Desktop-app OAuth client, tested against that account's own live "Shared with me" list, a handful of old shares from past freelance/contract work, nothing sensitive, no other account or person's data read or modified at any point. Every claim below was run, not inferred.

Findings

1. permissions.delete(fileId, permissionId='me') does not work as commonly described. Several secondhand guides describe 'me' as a valid special value for permissionId when removing your own access to a file you don't own. Calling it directly returns a flat 404:

HttpError 404: Permission not found: me.

Not a permissions error. Drive is looking for a permission object with the literal ID "me" and failing to find one. Whatever is true in other API surfaces, this isn't valid here.

2. permissions.list and permissions.get are both blocked for a non-owner, including for your own entry. The natural next step (enumerate the file's permissions, find your own entry, delete that specific ID) fails before it starts:

HttpError 403: The user does not have sufficient permissions for this file.

This held even for permissions.get(fileId, permissionId='me'), which several API discussions describe as a self-lookup exempt from the ordinary access requirement. It isn't, at least not as of this account's current API behavior: a plain viewer cannot read its own permission record back.

3. capabilities.canTrash is false regardless of role, including on an item with edit and share rights. Tested across seven real shared items spanning viewer and editor-level access:

Swim week -> {'canDelete': False, 'canEdit': True, 'canShare': True, 'canTrash': False}

An account with edit and share rights on a file still cannot trash it through the API. Every other item, all viewer-level, showed the same canTrash: False. Zero exceptions across the full set.

4. No file in the set carries a parents reference, so there's no folder-removal workaround either. Full metadata (fields=*) on each item showed no parents array. These were never added to "My Drive," so files.update(removeParents=...), the usual trick for unlinking an item from your own folder tree, has nothing to act on.

Root cause

There is no combination of currently-documented Drive API v3 calls that lets a non-owner revoke their own access to a shared file. Every lever, permission deletion, permission lookup, trashing, parent removal, is either rejected outright or structurally unavailable, independent of whether the share grants viewer or editor rights.

This explains the multi-year pattern of "Remove doesn't really work" reports better than assuming a single stale bug: the web UI's own "Remove" button is necessarily calling something outside the public API surface, because the public surface doesn't expose the operation at all. That also means the behavior it's been getting is as good as it gets. There's no stricter API call sitting one level deeper that a script could reach for instead.

What actually happens when you click Remove

Confirmed directly against the real backlog this investigation started from: the button hides the item from the "Shared with me" view. It does not revoke the underlying permission. This matches the oldest public reports of this behavior, unchanged as of this writing.

Mitigation

None available from the recipient's side. The only parties who can actually revoke a share are the file's owner, or Google, neither of which a script or the receiving account can act on.

What this piece is not: a claim that this is a newly discovered security hole, or that anyone's data is at risk. It isn't exploitable, it doesn't expose anything you don't already have legitimate access to, and it doesn't let you touch anyone else's file or permissions. It's a documented, now independently re-verified gap in a sharing-permission model between three systems (sharing, trash, and "remove from view") that were never fully unified, leaving ordinary users with a UI button that quietly does less than it appears to.