“Privacy rules” are essentially Bubble-speak for row-level DB security. Without privacy rules setup, it would be possible for a bad actor to manipulate a Bubble session into spilling all rows for a given table. Most of the time, this is fine. But for tables with info sensitive to either your users (AKA their addresses/emails/etc) or any proprietary info that could ruin your business edge if it fell into the wrong hands, then you will want to install privacy rules for such tables.

Bear in mind, your DB model really should be designed with privacy rules in mind from the get go (useful to keep in mind for the next app ha) because installing the rules on certain tables can break the user experience and require re-modelling the DB in a more denormalized fashion to hide the sensitive info more easily while still making other queries run fine.

Example: you built a messagin app. You built a table to house all the threads between two users, like sending_user, recieving_user, last_active. Uh oh. Without privacy rules, it may be possible for someone to query the table to find out who’s been messaging who or find out the total number of threads going on in your app. You install privacy rule that states a user may only view thread rows for which they are either the sending_user or recieving_user. But now you just broke a functionality that allows erroneous users to find out any other user’s last_active time, so now you must remodel. See what I’m getting at?

3 Likes