top | item 47118095

(no title)

integralpilot | 7 days ago

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...

discuss

order

anon84873628|7 days ago

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.

overfeed|7 days ago

> 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.

nfg|7 days ago

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!

coffe2mug|7 days ago

> 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?

danpalmer|7 days ago

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.

andrew_lettuce|6 days ago

>>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?