How much data is exposed when selecting "Include all relation columns" in form view?

I must have this option checked, but I need to know if someone could potentially access other columns that aren’t referenced in the form?

Hey @Micah_Lucero! Your respondents will not be able to access the other columns or unhide any of those if they do not have access to the doc where the form lives. By using the “all relation columns” option they could potentially see data pop up in the form or users of the doc that you may have not wanted. That’s the basis of the warning. Let me know if that helps to clarify and if you need more guidance.

Thank you for the response.

I have a Team Database, and a public form with a relation column to the Team Database. The display column (what people select from) for that relation is the Team member’s name. However, that team member also has a pin on their profile. In the form, they have to enter the pin number that matches with the pin on their profile.

Here is a link to the form for reference. All data and names are fake. Try selecting the user ‘Deirdre Melosa Edney’ and use the pin ‘Password123’.

Notice how if you use another password, you can’t submit anything.

In order for the formula to run, I need to have all relation columns enabled.

However the Team Database also has things like the team member’s phone # and email, so I just want to make sure that there is no way someone can get that info from the form view

Hopefully this helps as well!

Here’s my answer for a similar topic, it still stands.

TL;DR: you’re exposing all of it. So you probably shouldn’t include formulas or relations in your forms, and should not enable those toggles.

Here’s your form shard. It exposes 12 tables.

There’s a table with 1002 rows of what looks like personal data:

There’s her password:

Should I continue? :slight_smile:

1 Like

Yes! This is what I was trying to do, but I couldn’t find where the data was being stored.

I knew how to do this in regular docs, but couldn’t figure out how in the forms for some reason.

This answered my question though, thanks!

It is the same: you basically find the biggest file that gets loaded (fui-* for docs, grid-something-shard-* for forms) and it’s a JSON file that has a subtree of objects. Each grid-xxxxxxxxxx is a table. The data is in that long string — it’s a Base64-encoded codabuf — a storage format (pretty nicely engineered tbh) that efficiently stores table data. Unlike the previous storage mechanism, this one introduced here actually allows for efficient random access reading — i.e. it doesn’t have to decode the whole thing to only read a subset of rows or columns. Some data is binary but text values (names, passwords etc) are stored in plain sight so you can search of simply visually scan for the occurrences of known text values in there. That’s how I’ve been doing it before; I only wrote a complete decoder for codabuf last weekend, and I’m going to use it in the Comments Pack.

It was quite an effort so I won’t share it though but use to my commercial advantage :slight_smile: But anyone is welcome to equip themselves with a good hex editor, developer tools, and a good deal of patience, and decode these themselves — Coda’s frontend JS code is all there.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.