5 ms·

Interestingly, the ChatGPT Plugin docs [1] say that POST operations like these are required to implement user confirmation, so you might blame the plugin implem

Interestingly, the ChatGPT Plugin docs [1] say that POST operations like these are required to implement user confirmation, so you might blame the plugin implementation (or OpenAI's non-enforcement of the policy) in this case: > for POST requests, we require that developers build a user confirmation flow to avoid destruction actions However, at least from what I can see, the docs don't provide much more detail about how to actually implement confirmation. I haven't played around with the plugins API myself, but I originally assumed it was a non-AI-driven technical constraint, maybe a confirmation modal that ChatGPT always shows to the user before any POST. From a forum post I saw [2], though, it looks like ChatGPT doesn't have any system like that, and you're just supposed to write your manifest and OpenAPI spec in a way that tells ChatGPT to confirm with the user. From the forum post, it sounds like this is pretty fragile, and of course is susceptible to prompt injection as well. [1] https://platform.openai.com/docs/plugins/introduction https://platform.openai.com/docs/plugins/introduction [2] https://community.openai.com/t/implementing-user-confirmation-flow-in-chatgpt-plugin/190485 https://community.openai.com/t/implementing-user-confirmatio...

tharkun__ 3y ago
This might be an intentional interpretation of the plugin authors. Meaning they potentially took the reasoning "in order to prevent destruction actions" to inversely mean that non-destructive POST requests must be OK then and do not require a prompt. Plenty of POST search APIs out there to get around path length limitations and such. That is probably not the intended meaning but a valid enough if kind of tongue in cheek-we-will-do-as-we-please-following-the-letter-only implementation. And like the author found even creative a d not destructive actions can be surprising and unwanted. But isn't this what AI would ultimately be about?
- fieldcny 3y ago
  Why would it not be the intended meaning, if they wanted it to be all post requests they would have said so, the specifically scoped it “destructive actions”, their intention is in their words. POST as a verb can pretty much be used for anything retrieval, creation, deletion, updates, noops , it’s just code it does whatever we tell it to do.
  - kevincox 3y ago
    I think you are slightly misreading it. The rule is a requirement and an explanation. Requirement: for POST requests, we require that developers build a user confirmation flow Explanation: to avoid destruction actions I think you are reading it as if it said: > for POST requests, we require that developers build a user confirmation flow *for* destruction actions
wunderwuzzi23 3y ago
After I shared some POC exploits with Plugins OpenAI added this requirement it seems. However as far as I can tell, and most recent testing shows, this requirement is not enforced: https://embracethered.com/blog/posts/2023/chatgpt-plugin-vulns-chat-with-code/ https://embracethered.com/blog/posts/2023/chatgpt-plugin-vul... I'm still hoping that OpenAI will fix this at the platform level, so that not every Plugin developer has to do this themselves. It took 15+ years to get same-site cookies - let's see if the we can do better in here...
- reaperman 3y ago
  > It took 15+ years to ~~get~~ re-gain same-site cookies. IIRC, cookies were originally tightly locked to the domain/subdomain which set them.
creatonez 3y ago
Wow, not the kinda thing you'd want to be so precarious. Really surprising that more thought wasn't put into this.

tharkun__ 3y ago

This might be an intentional interpretation of the plugin authors. Meaning they potentially took the reasoning "in order to prevent destruction actions" to inversely mean that non-destructive POST requests must be OK then and do not require a prompt. Plenty of POST search APIs out there to get around path length limitations and such. That is probably not the intended meaning but a valid enough if kind of tongue in cheek-we-will-do-as-we-please-following-the-letter-only implementation. And like the author found even creative a d not destructive actions can be surprising and unwanted. But isn't this what AI would ultimately be about?

fieldcny 3y ago
Why would it not be the intended meaning, if they wanted it to be all post requests they would have said so, the specifically scoped it “destructive actions”, their intention is in their words. POST as a verb can pretty much be used for anything retrieval, creation, deletion, updates, noops , it’s just code it does whatever we tell it to do.
- kevincox 3y ago
  I think you are slightly misreading it. The rule is a requirement and an explanation. Requirement: for POST requests, we require that developers build a user confirmation flow Explanation: to avoid destruction actions I think you are reading it as if it said: > for POST requests, we require that developers build a user confirmation flow *for* destruction actions

wunderwuzzi23 3y ago

After I shared some POC exploits with Plugins OpenAI added this requirement it seems. However as far as I can tell, and most recent testing shows, this requirement is not enforced: https://embracethered.com/blog/posts/2023/chatgpt-plugin-vulns-chat-with-code/ https://embracethered.com/blog/posts/2023/chatgpt-plugin-vul... I'm still hoping that OpenAI will fix this at the platform level, so that not every Plugin developer has to do this themselves. It took 15+ years to get same-site cookies - let's see if the we can do better in here...

reaperman 3y ago
> It took 15+ years to ~~get~~ re-gain same-site cookies. IIRC, cookies were originally tightly locked to the domain/subdomain which set them.

creatonez 3y ago

Wow, not the kinda thing you'd want to be so precarious. Really surprising that more thought wasn't put into this.