OpenAI CEO 'feels awful' about ChatGPT leaking conversations
theregister.com
theregister.com
OpenAI is a company that we are going to have a significant relationship with into the future, so it's worth understanding the characteristics of the leadership of that company.
A real leader would simply have said "we fixed it, sorry", instead of "we fixed it, but it was someone else's fault".
It reminds me of those "I deleted the production database and got fired" stories ..... I always think it's management to blame if it is possible to delete the production database, but management like to blame someone further down the tree.
Do you want full transparency or what? Jesus.
The DB equivalent is letting a drop table statement run against prod.
It’s where supply chain attacks occur.
Full transparency would mean opening their code, CI/CD pipelines; all their tech stack would be public. So yes, that is what I want. Not this South Park “we are so sorry.”
This all really should be openly available and accountable to public scrutiny if we’re going to call it the future of the internet.
I think it's better than just saying "we fixed it, sorry"
They do _not_ say, "here's a list of broad changes to our practices which will allow us discover similar issues before they reach production and touch customer data".
> we had a significant issue in ChatGPT due to a bug in an open source library, for which a fix has now been released and we have just finished validating.
[0]: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
The bug was discovered in the Redis client open-source library, redis-py. As soon as we identified the bug, we reached out to the Redis maintainers with a patch to resolve the issue. Here’s how the bug worked:
- We use Redis to cache user information in our server so we don’t need to check our database for every request.
- We use Redis Cluster to distribute this load over multiple Redis instances.
- We use the redis-py library to interface with Redis from our Python server, which runs with Asyncio.
- The library maintains a shared pool of connections between the server and the cluster, and recycles a connection to be used for another request once done.
- When using Asyncio, requests and responses with redis-py behave as two queues: the caller pushes a request onto the incoming queue, and will pop a response from the outgoing queue, and then return the connection to the pool.
- If a request is canceled after the request is pushed onto the incoming queue, but before the response popped from the outgoing queue, we see our bug: the connection thus becomes corrupted and the next response that’s dequeued for an unrelated request can receive data left behind in the connection.
- In most cases, this results in an unrecoverable server error, and the user will have to try their request again.
- But in some cases the corrupted data happens to match the data type the requester was expecting, and so what gets returned from the cache appears valid, even if it belongs to another user.
At 1 a.m. Pacific time on Monday, March 20, we inadvertently introduced a change to our server that caused a spike in Redis request cancellations. This created a small probability for each connection to return bad data.
This bug only appeared in the Asyncio redis-py client for Redis Cluster, and has now been fixed.
That requires 1:1 DB user to real user mapping + one connection to DB per users, it is entirely horrible performance-wise, which is why it is so rarely used for anything more than separating apps from eachother.
Instead of blame deflection, the communication users (and companies) want to hear is – "it was our fault, and we are overhauling our security and vendor audit process to make sure it doesn't happen again."
On the other hand if I understand correctly, the bug arises from an edge case from an error that was very common. I constantly receive these errors using the chat interface, and that’s an organization issue. There should be an SRE team or someone to notice them and try to fix them.
Sorry your account's been shut down, it must have been the silly algorithm/silly source code/silly engineers in the workshop again!
When you're making a tool that could quite likely change the course of how people use and interact with computers, these excuses don't fly.
Hope it doesn't happen again, but the old mantra of "move fast, break things, apologize later" seems to apply here just like with every other SV company.
I mean, obviously? They would not be able to ship things at this speed with so few employees if they were being conservative. No value judgement, just saying we should not be surprised.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.