I run YourDigitalRights.org where we help people delete their personal data, so this is kind of my thing. Meta is in the top 0.1% of companies in terms of how difficult they make it for people to delete their personal data. They are notoriously difficult, and we keep on playing cat and mouse games with them. They just don't want to delete any kind of personal information. In most cases, I recommend going to the regulator, which is almost all cases involved with Meta. In some exceptional cases, going to a lawyer is a viable course of action, especially when any kind of harm is involved. Imagine a case where someone is extorting you or defaming you, and you can't delete that data even though it refers personally to you. So yeah, it's a viable course of action in some cases.
If you were Meta designing this chatbot, would you plant hidden instructions for it in public pages, increasing the size of the page, and leaking what is internal info for everyone to see? Is this the natural design choice? Or would you give the chatbot its own API with the same text + the relevant instructions? Does not seem to me to be a sensible design choice. We are not in the days of using hidden HTML to communicate with internal subsystems.
Honestly, this is a clever way of doing this. It means the additional instructions are stored alongside the text they reference, which makes it easier for doc writers to keep in sync and it probably also makes it more effective since the bot is guaranteed to read it at the right time in the right context.
I doubt they actually send it with every request and hide it in CSS, it probably does some other kind of check (IP, user agent, token...). This also tracks with the fact it is now entirely gone - presumably they just fixed that if statement and it's again chatbot-only.
It still doesn't make sense. That pages are probably built from an internal repository/database where that information is in a human readable format (e.g. Markdown or some sort of CMS) that is then processed by a CI to produce the public static HTML pages.
It would be more efficient to give the chatbot context the source files, in a format that is more efficient for that (Markdown documents, for example) and that will of course contain the internal notes, that are stripped during the build of the public HTML version.
Why a chatbot should waste resources in parsing a public webpage for the same information that you have internally in possibly a more appropriate format?
Also having a check for user agent/IP to do so is still inefficient, because you can't serve static HTML/CSS/JS and thus you have to do processing work on each request, a thing that doesn't make a lot of sense for static content of this kind.
Nobody said it's efficient, welcome to the modern IT landscape. The docs are surely some SaaS with a WYSIWYG editor, access controls and analytics. Every page probably does a dozen database lookups and involves 3 mixroservices and 4 external providers minimum.
What? This is the most logical solution and the most likely one given the behaviour seen in the post. And even if they were sending every human reader the LLM content too, who cares? It's a few kilobytes at worst in a multi-megabyte page.
Given they probably need to go through layers of management, across teams, and go through relevant testing to adjust the LLM prompt, this was probably a nice quick and flexible way to create a "shadow" prompt.
Maybe? But it also doesn't necessarily belong into the prompt. The model probably accesses the help pages as a RAG knowledgebase, so putting it there makes sense.
that is exactly what they would do, otherwise it wouldn't pass any review. Unless this was generated and reviewed by AI during their experimentation phase, but I doubt it very much.
Not surprising. When privacy is a selling point on the enterprise plan regular users, even paying ones, are the product. OpenAI had this from day one, the writing was on the wall. We all knew it so let's not act surprised now.
> When privacy is a selling point on the enterprise plan regular users, even paying ones, are the product.
There's really no reason to think that enterprise plans are immune. While this analysis didn't test enterprise plans, and only focused on third party tracking, the people behind these companies have already demonstrated that they are willing to break the law to get what they want, are willing to lie to their users, willing to lie to the public, and even willing to lie to congress. Yet somehow people seem convinced that they'd never dare to lie to Random Corp LLC
Except they all depend on the OpenAI API. Cut that off and they all stop. Finding an alternative source of compute is not easy, and even once done it's easy to cut off.
Frontier models don't fit on a normal GPU. The datacenter architecture frontier labs use is not a commodity. What you're describing is beyond the state of the art, and if we go there then anything is possible.
Great job. Please consider turning on rotation by default (for those who missed it, it's in the parameters). The overwhelming majority of astrophysical black holes are expected to be spinning (Ker) black holes.
That option for rotating (Kerr) black holes generally works, but not on all devices in my experiences. Debugging on someone's phone is not that straightword, so I went with the most accessible experience by default.
Also note that the visual difference for the camera warp is really marginal between rotating vs non-rotating black holes.
reply