However, in the past, I was able to go to the ‘Issues’ tab and click on ‘Test Settings’ in the top right corner and modify the fields letting the app know that I know that this is public and it is meant to be that way so it doesn’t show up as a ‘leak’. See images below:
In this way, I should be telling the system that we don’t need to mark these as a ‘leak’ right?
Anyways, I have been back and forth with the bubble ‘support’ team and it’s driving me insane. You guys know how it goes. Anyways, I want to see if anyone else remembers this or not. Let me know. Thanks!
This pretty much confirms my thoughts. Straight from Bubble documentation:
Data types
To decide which data types to include in a security check, consider whether they store information that should remain private or restricted. Data types containing sensitive or user-specific information—such as profiles, orders, messages, or internal records—should be treated as private. These are the types that benefit most from permission checks and secure privacy rules.
Some data types, however, are meant to be publicly accessible. For example, items displayed on a public landing page—such as blog posts, product listings, or marketing content—may not require strict privacy rules if they’re intended for anyone to view.
To keep your scan focused and avoid unnecessary warnings, you can exclude data types that are intentionally public. This helps the test concentrate on the data that truly requires protection.
I already said this in another post but they need to change the model that’s analyzing the field names/etc. It hallucinates really badly and I suspect it’s an old non-reasoning model or something.
I’ve seen this too. The security dashboard now flags anything returned by the privacy checker, even if it’s intentionally public. The old “Test Settings” override isn’t working the same way anymore. The key is to mark public data types explicitly as “no privacy rules” so the scan ignores them. For messages meant to be public, that should stop the false leaks from showing up.
I think if AI is involved in this feature, that’s just a waste, because why does AI need to be involved in a deterministic feature. Rules that instruct AI to know a field is to be ignored in scan can be ignored by AI, which is part of the unreliability of AI.
If there is a chance AI is used, it could be one of a few things. The flag to ignore certain data fields or even entire data types could just be non functional and AI doesn’t get the message, or message is received and AI prompt gets ‘improved’ and those flags are forgotten to be included or the AI gets message, has prompt correct but decides to be AI and ignore what it determines it can ignore.
Right now that document snippet speaks to entire data types and not specific fields.
The fields highlighted seem prompted where any related data types or dates are hard wired to be considered leaking as somebody somewhere thought they are ‘sensitive’ by nature.
I do see that screen shot of prompt window for selecting data types reading that can select fields.
Yeah. The part that I think is AI is the initial determination of whether a field should be public or private. It shouldn’t need to use AI for the test. It just checks if those fields are visible publicly or not. It just doesn’t look like it is updating for new tests for some reason. I’m pretty sure it’s a bubble bug but it’s just so hard to get past the first two to three layers of bubble support team to actually talk with someone that knows what they are talking about. @flusk maybe can give some details if this is a bug or not since they were originally the ones that made the platform.
Yeah flusk has been buggy since mid 2025. Taking forever to load. Timing out. Waiting for seconds after a click and not saving things marked as public. It really has no utility over AI which can be context aware of your prefs and app prefs and will fix it straight-up
