Main idea

To get text out of a conversation and into a personal server, you can disguise a write as a read: instead of sending the data, you slip it into the address of a web page and ask the assistant to fetch that page. On the server side, the trick works perfectly — from a browser, from a command line.

It fails as soon as it is the assistant that builds the address from the content of the exchange and then fetches it. Its browsing safeguards block the operation.

The reason is that the safeguard doesn't bear on the form of the request but on who builds it and with what. Disguising the request changes neither of those two parameters.

Why it matters

This gives a criterion before investing in a workaround: what does the restriction depend on? If it depends on the form — a method, a type of call — disguising it may work. If it depends on the actor or on where the data comes from, no disguise will succeed, and the time spent will be lost.

The failure is coherent, besides: the mechanism targeted exactly what was being attempted, automatically pushing conversation content out to a third-party server.

Nuances and limits

The observation holds for the safeguards observed here, at a given moment. They evolve, and nothing guarantees they stay placed in the same spot.

And it says nothing about the legitimacy of the workaround: a personal use and an abusive one meet the same wall, for good reasons in only one case.

Open questions

• How do you identify, without trying everything, what a restriction actually bears on?