[beta] give me a URL and I'll visualize your entire database

Hello, this is Payam (pie-um, he/him), the director for platform engineering here at Bubble. I’ve previously introduced myself in this post when I joined in August. I have a background in platform engineering and security architecture at internet-scale public companies.

First, thank you all for raising this thread, and the robust conversation here around the contours of security, data privacy, and application design.

We did know that it is possible to retrieve all the data fields for a particular Bubble app. And we agree our system ought to be built in a way where it is possible to have both a private and public schema.

It is possible to retrieve these database fields because we have an interpreted language, and we send the definition of an application to the client side. The visualization tools in this thread are new, and seeing it in that format certainly feels different from having just seen unstructured JSON prior. It’s worth noting that getting that format is not an entirely trivial thing to do, and being able to use Bubble to build an app that validates Bubble itself showcases the power of the system and the inventiveness of our community - we welcome this!

We think about the open availability of the database field names in two ways: 1) as affecting data privacy and 2) a consequence of our interpreted language. Over the last few months, we’ve been shaping out how to make Bubble apps compiled artifacts, where the client-side only gets what it needs, performance and security are greatly improved globally, which would also enable Bubble apps to become more easily portable, e.g. across regions.

We agree there’s a valid argument to be made in the meantime that we should also look into obfuscating these fields, which would have solved several of the issues mentioned in this thread, such as apps discovered to be collecting data not elsewhere mentioned in a privacy policy. We will also look into whether we can prevent the display of hidden fields. Another direction we’re exploring is better tooling for visualizing your app’s public exposure, to make it easier for app builders to audit what information in their applications can be seen by anyone vs by authenticated users. There are already several tools in our ecosystem that help with this, and we’re interested in finding ways to get them in front of more users.

Our goal is to build a secure platform on which you can build secure applications with fine-grained control over your data. I’m very excited about our growth trajectory with respect to data privacy and security. We’re already in the habit of being responsive to privacy and security concerns raised by the community — for example, just a couple of weeks ago, the community raised a security vulnerability having to do with cross-site-scripting, which we worked on together on and promptly fixed. We have a robust risk register and are executing our engineering practices with security and data privacy in mind from the start.

As always, we welcome your feedback on the urgency of obfuscating these names, and any other feedback you may have!