Comment by anon84873628
9 hours ago
I don't understand step 1. OAuth client applications have to be registered in GCP, right? They have to request specific scopes for specific APIs, and there is a review process before they can be used by the public. Did none of that happen for the Open Claw client? How is it the users' fault for clicking a "Sign in with Google" button? And if there was a mistake, why not ban the whole client?
I could see a problem with logging into Antigravity then exfiltrating the tokens to use somewhere else... But that doesn't sound like what happened. (And then how would they know?)
I haven't used Open Claw, so what else am missing to make this make sense?
To my understanding, OpenClaw pretends to be Antigravity by using the Antigravity OAuth client ID (and doesn't have its own), and then the takes the token Google returns to instead use with OpenClaw.
When I first tried OpenClaw and chose Google Sign-In, I noticed the window appeared saying "Sign into Google Antigravity" with a Google official mark, and a warning it shouldn't be used to sign into anything besides official Google apps. I closed it immediately and uninstalled OpenClaw as this was suspicious to me, and it was a relatively new project then.
It amazes me that the maintainer(s) allowed something like this...
Ah, ok. I guess there is no way for Google to prevent this since desktop apps are public clients that use PKCE.
I imagine Open Claw must also have registered the Antigravity custom URL scheme in order to receive the redirect.
Remaining question is how Google determines that traffic is not actually coming from Antigravity.
> Remaining question is how Google determines that traffic is not actually coming from Antigravity.
Spiralling here: high volumes, and tool calls that are not typical for an agentic IDE.
If this is like the flow it uses for a codex / ChatGPT subscription it doesn’t even register a handler - the redirect opens as a 404 in your browser and there are instructions in copying the token from the query string!
> OAuth client ID (and doesn't have its own), and then the takes the token Google returns to instead use with OpenClaw.
Still surprised.
Client ID ok.
But openclaw needs the secret also?
Does it also mean Antigravity did not restrict to specific applications?
Antigravity runs on your machine, the secret is there for the taking.
This is true of all OAuth client logins in this way, it's why the secret doesn't mean the same thing as it does with server to server login, you can never fully trust the client.
OAuth impersonation is nothing new, it's a well known attack vector that can't really be worked around (without changing the UX), the solution is instead terms of service, policies, and enforcement.
>>it amazes me that the maintainer(s) allowed something like this...
Really? In today's landscape this is the part that surprises you? I'm seeing these types of decisions repeatedly and typically my only question is do they not know any better, or intentionally not care?