"Search" unfortunately reveals all "hidden" pages, all hidden data

[Jean-Marie_FAVRE]

Hello everybody

I’ve just moved to the Team plan. I’m very surprised since I’ve realized that, even with the team plan, it seems that all pieces of data is always visible to all editors. That’s is, even so-called “hidden pages” can be really easily accessed through the “search box”. And this is exactly the same with all tables, all records in tables, etc. Even if a filter is applied on a table, in a hidden place, etc, coda will always reveal all data to anyone. See the figure below where a hidden page is shown, and the same with data.

This problem is very limitating indeed. For instance, using email adresses in a document means that all editors can see all email adresses. Disclosing all user data and email adresses is an issue. Similarily, all editors can have access to the salary of everybody, etc.

What is surprizing is the fact that some pages are “hidden”, that there are plenty of means in coda to filter data, etc. Plenty of really cool things to filter data, to hide it, etc. Apart the search box that ruin it all.

Is there a way to remove the search box ? Or even better, is there a “is searchable” checkbox on each table ?

Thank you for your help !

[Agile_Dynamics]

this is a MAJOR problem for all my clients.

there is no way to prevent this.

i got a call from a client yesterday who was very confused.

she thought the search box would help her find a value in her workflow, but instead it took her to a hidden page and a hidden table. she thought she could add a new row to the table to set the value she needed, so she clicked on a plus sign at the top of the table.

but that was the “add column” option, so now she is in a menu offering column data types, and all kinds of gobbdee-gook she does not understand!

it is impossible to “lock down” the workflow user interface to prevent this kind of “escape” from happening.

please coda, please fix this!

max

[Jean-Marie_FAVRE]

Yes, it’s a major problem. What is confusing is that Coda at the same time provides a button “hide” and a search button that show what is hidden. These two features are clearly inconsistent.

The biggest problem I see, is that some customers might hide some things, having some kind of faith in the product, and discover later, the hard way, some data leaks, due to coda. In some cases this could damage the confidence in the tool. Or this could be a “no go” if someone see this beforehand.

I hope a solution will be implemented soon (at least a tooggle to hide the search box).

In the mean time I’ll check how to write a pack to hide sensitive data, but honestly I now have the doubt about some features revealing pack content. Simply put, I think I’ve lost confidence.

Otherwise, Coda really rocks and this is a really great product.

Merry christmas !

BTW I know what I will put on my santa klaus wish list
The second bullet would be to show vertical lines in table. Some tables are really unreadable, so I have to move back to google spreadsheets. Just for readability issues. That’s a pity.

Coda

[Christiaan_Huizer]

hi @Jean-Marie_FAVRE ,

it is indeed inconsistent, I wrote a blog about it, asked Coda for feedback a few weeks ago, but no response so far.

Coda —a transparent doc

Happy holidays

Christiaan

[Jean-Marie_FAVRE]

Happy christmas to all of you.

Thanks @Christiaan_Huizer for you blog post.

Summing up, the search box that returns everything hidden was reported first in 2020, more than 3 years now. According to the message nothing has changed since then.

Not even the inclusion of a popup message “beware, whatever you try to hide will be shown to all users anyway”. A “hide” & “show” features dispute that stopped in the middle of the road in 2020.

Very happy to have seen this problem before an actual data leak as this can be VERY emabrassing.

No gift this morning under the tree this morning Let’s keep some hope. I will ask this next year again

[CleberSantana]

I think it was intentional. I’ve been using coda way long before “hide page” feature. When they launched it, they’ve stated in various places that hiding pages is not a security feature at all, but actually a way to get clutter out of sight. I think they still warn you the first time you try to hide a page.

And until recently, there were very few options to truly “hide” sensitive information inside coda (because of the way data doesn’t live inside a page, i think). I’ve been using this technique from The Coda Guy: https://www.youtube.com/watch?v=aft9wHI0zfQ. (I don’t know if it effectively hides info if you search for it)

I think maybe there are other options now with page sync.

But I agree it is very likely that newcomers may take it for granted that “hidden” pages are “hidden from everyone” and that’s a problem.

[Adrian_Labecki]

Can anyone from Coda comment on that?

[Jean-Marie_FAVRE]

Happy new year !

I guess that they are plenty of reasons from the past that could explain that “hidden” do not really mean “hidden”, etc. And may be we can explain that this is a product feature. I understand that Coda never claimed to be a top-level security tool. But I agree with @Christiaan_Huizer, if the claim is to have “a doc as powerful as an app”, then making all data visible to everybody is at least weird. An app, I guess, has the characteristics of showing to all stakeholders, just what they need. Coda shows everything to everybody, no matter what.

I’m new to this community, and in fact new to Coda So I cannot guess what the absence of official answer from Coda means. The problem was reported 3 years ago, according to the blog post of @Christiaan_Huizer.

Let’s be constructive. For this year, 2024, I wish to have at least a toogle to remove the damned search box. They are already toggles for the top and bottom “+/+new” buttons. This is very useful and powerful. So adding the remove-search-toogle should not be a huge development effort for 2024.

And in the same vein, a toggle to remove the “expand” row on the left of each row. There are various videos on youtube that desperately try to replace this standard button by other “expand” user-defined buttons. The problem is that the default button is still there, so some videos shows a message “do press this standard button”.

All in all, if there is no interest for Coda in synchronizing “search” and “hide” teams, there is still a cheap way to remove features (search field and expand buttons). I know that this will not solve the whole discoverability problem, but at least the most obvious path to data leaks will be eliminated. As pointed out by @Agile_Dynamics: there is a serious usability issues, with user being lost because of the search box.

Summing up my modest wishes for 2024 :

• a toggle to remove the search box,
• a toggle to remove the expand button

A secret extra-wish for 2024 : just like @Agile_Dynamics says “please coda, please fix this!:”

Best wishes for 2024, to all of you, and to the coda team !

[Agile_Dynamics]

there is a way to hide sensitive data in your document that is not uncovered by the search bar.
it takes some effort to implement this work-around.

(many thanks to @Nina_Ledid for documenting this technique as follows)…

• Create an Admin Table, listing anyone who will be able to see all the Sensitive Table
• Set up a control (eg: AdminAccessSelector), displaying “false” if currently logged in user is not listed within admin table
• Set the sensitive table to filter User=AdminAccessSelector.
  • So that, any user who is not an Admin will not see any results.
  • Set the sensitive table layout to display zero columns.
• Vitally Important: Its not enough to simply hide all columns.
  • You need to edit the main layout of the Sensitive Table, in order to ensure that the ”Hidden Column Link” toggle is set to is NOT-visible. Otherwise, any malicious user would simply need to click on “Show hidden columns” within row modal to see the sensitive data.
• On the Sensitive Table, insert a new column, type formula, set it to Display Column, and set the formula to a suitable error message like User().Name+" may not access this data"
• Lock the page containing the Sensitive Table and the AdminAccessSelector control.

This lets us hide the sensitive data from the search function and from users clicking on the table name at the top of a dialog-box. Any searches that result in hits to the Sensitive Table, will only show the formula column containing the error message.

But it is not totally hacker-proof - a knowledgable, determined user could use the developer-tools of their browser to delve into the internal structure of the document and uncover the hidden data.

So using cross-doc is the more secure solution.

[Rohan_Mitchell]

Adding a vote to the importance of this. It is one of the reasons that I have never taken Coda on as a serious tool. At present I am mostly just using it for gaming related purposes and while the ability to truly hide and prevent access to data would be nice, it is not critical in that context.

However, I am also trying to setup a doc for documentation for my software application, for my users to access, and this is now causing a problem. Again this isn’t critical data so I may well go ahead, but I don’t like the fact that it is very hard to prevent users from getting into the “engine” of the doc. Yes, there are workarounds, but that really isn’t good enough, especially given the number of years coda has now been around and has had to resolve this.

I found this thread because I was about to start my own regarding this -

The “Row from […]” is yet another way that users can get access to data. Also -

The user can open the chip, and then using the same “Row from” link gain access to a whole page of back end tables. The work around I am using for this is to create (yet) another column called “CategoriesList” and make it a formula (=Categories.ToText()) and show that column in the layout.

[Scott_Collier-Weir]

I actually reported this privately to Coda prior to 2020, and specifically requested at that time for a toggle to turn the search bar on or off.

Their response to me was one of confusion at the time, not seeing understanding its value or use case and commenting that it wasn’t likely that feature would ship because no one else has asked for it.

Clearly more people are asking for it now!

But to be honest - I’ve changed my opinion and I don’t necessarily think that the search bar should be toggled off.

“Hiding” data securely can only be done at the api level. Meaning that different data is loaded to the clients browser dependent on who they are and what data they are authorized to view. This is a fundamental principle when building web applications.

Coda was not meant to be a web app builder

In fact, their website doesn’t mention power like an app anymore excerpt for a few places, and then only farther down below the fold.

Can you make one as powerful and secure as an app? Sure! Filter at the api level which can be accomplished with Cross doc.

Or, build a doc truly as powerful as an app where security is not of any concern because it’s an app used internally by a trusted team.

Codas Headline Now

Your all-in-one collaborative workspace. Coda brings teams and tools together for a more organized work day.

Coda fits very neatly as a collaborative workspace bringing teams and tools together

So should we hide the search bar?

Now let’s all be honest - those in this thread are the minority - pushing coda to its limits in nearly every way.

Shoot - our team just launched the Xano pack to let you use Coda as your front end without any fear of out-scaling coda with row limits!

And there’s many times where I personally would still like that search bar gone. But I don’t know any longer if it should be a priority?

Right now, the best method is as @Agile_Dynamics explained - making sure the base table has all of its columns hidden, and you impose filters and locking. (And then follow all the principles of access tables as referenced earlier!)

The search bar exposes all display column items in your doc, and then when you hover over those items, it shows you the visible column information from the base table. So if you hide all columns in the base table - the search bar doesn’t expose actual cell data

Or you can actually hide the search bar if you publish a doc and use top level navigation.

All in all, I’d still like to hide the search bar but think it’s good to remember that **

hiding the search bar is just a band-aid in the quest for secure apps

**.

Secure apps only come by filtering at the api level - and cross doc is your only “coda” solution. There are other solutions but you must pair coda with other tools and that’s not always ideal.

Will coda one day launch this feature? No idea. But if they don’t or drag their feet hopefully that brings some context to possibly why.

[Agile_Dynamics]

@Scott_Collier-Weir

Coda was not meant to be a web app builder

i keep hearing this !
and it is such a pity.

coda is actually one of the BEST rapid development tools for web apps!
its almost complete in that regard.
there are just a tiny few things that get in the way (and this is one of them).

i can whip-up a fairly complex but very useful web app in a VERY short time using Coda.
my clients are AMAZED how quickly we can go from idea to usable app - and how quickly we can modify them to deal with business change.

ok, they are not REAL web apps - we call them “automated workflows”.
but they get the job done better than ANY of the competitors platforms.
especially if you are coming from the world of spreadsheet automation.

but i can see that Coda is positioning itself in the marketplace to exploit its unique abilities and distance itself from every other no-code platform.

so i am stuck with the tool being ALMOST perfect

sigh!

[Nate_Gerber2]

I’m with you on this on Xyzor…

[joost_mineur]

Hello @Scott_Collier-Weir ,

Thanks - but no thanks.

Coda is the one that talked about “power like an app” - perhaps they changed their mind, but we have invested a lot of time in Coda, partly based on Coda’s promotional wording.

I really feel that your opinion about security through API (Cross doc or otherwise) is missing the point - it is a work around. There are so many situations when using whichever API is at least problematic: if your main doc houses data for x separate entities (departments, clients…) you would have to build and maintain x separate API connected user facing docs. That is not realistic.

And, it is not all about security - it is also about data integrity and useability. Users generally need to update or add data - so 2-way syncs are required - and these updates need to be synced to other docs ass well, leading to a lot of complexity and other error prone (trans)actions.

Hiding columns in master tables is a joke ( although I guess some builders don’t think so):

1. a maker sometimes needs access to these hidden column and the only way to do that is
   a) have another hidden table somewhere (which is not hidden anyway)
   b) unhide temporarily those hidden columns, which is exposing everything while you are working on them and it is not very practical anyway.
2. type /table in any canvas field, open a view to the master table and do whatever you want with this table and data.

Sub 2) in particular makes it almost impossible to secure your data - not just against prying eyes, but against accidental changes, deletes or anything else you can think of. Even if data doesn’t have to be secure, that doesn’t mean you want it to be open and vulnarable.

Coda promised to solve some of these things and I really appreciate how complicated that is. I understand it takes time. I even buy it that Coda isn’t and won’t be the place to secure sensitive data - we all know the full doc is loaded to the users’ device upon opening it.

But, what I really don’t understand, is that so many hours and resources are used to add features and improve functions, while not giving us a couple of quick fixes for the time being. You seem to think that this only touches a limited amount of users eploring Coda to it’s limits, but I think you are wrong. These problems affect way more makers, the only thing is that they might not be fully aware of this (yet) - until they are (and if they share docs, they eventually will) confronted with corrupted data or unknowingly share data.

In my opinion there a couple of things Coda can do to solve this (for the short or perhaps even the longer term) - and I think these quick fixex are not all that complicated to incorporate:

1. let makers turn search on or off for other users (editors and view only users)
2. let makers turn hidden pages on or off for other users (editors and view only users)
3. make it more complicated to try to acces hidden pages by not allowing to find pages with “-” extensions
4. make canvas field behave like other fields if locking is used

I realize this doesn’t solve everything, but it is a start. We don’t want to build work arounds and we don’t want to connect through API’s and we don’t want to have to think about all the precautions for every (new) table and (new) page when we are building (new) docs. We want to set up a doc properly and think about what we want to expose to a (normal) user and then we want to start building beautiful, useful and useable docs.

Obviously - this is just my opinion. These days, Coda is what I use 90% of the time now and I will keep on using it for most things I do, but it would really help if a couple things would be fixed, even if just with a band-aid.

To all readers, if you made it to the end of this post - thanks for bearing with me and, I hope, for your support!

Greetings, Joost

[Christiaan_Huizer]

In my blog I argued that Coda is not consistent in her approach. Coda is free to make the application according her liking, but she cannot mislead users by suggesting filtering works while it does not when you use a search bar, but it works with AI.

Any user may expect the basics to work consistent in a doc.

As @joost_mineur argued certain interventions would make the problem less problematic.

[Jean-Marie_FAVRE]

Hi,
I agree with the fact that this is not only a data security problem.

The problem is also definitively about usability as mentionned by @Agile_Dynamics (the first message). For the sake of illustration, just look at the following example .

I started a couple of weeks ago creating a Coda page where students can register with their names, emails and choose a group, the table group being updated in real time thanks to coda relations. Really cool.

At that time I was still thinking that hidden meant hidden. When I realized that the emails fields and hidden pages would be seen by everybody, this was a data security issue. I’m not supposed to give to students personal emails of each others. Hence the very first message of this thread.

Anyway I then asked students to give their university email which can be easily computed with firstname.lastname schema, so this avoid the security issue, because these emails can be guessed anyway.

But I realized then that the search box is also a usability issues. The students registered and everything went well for most of them, but unfortunately some students arrived on hidden pages, with data such as mattermost and github registration. They didn’d realize that they were no supposed to be there. Some studentc started complaining about some data they did not understand, etc. Just because they used the search box… Just because they were using a page, and boom, they are on some other pages/tables. Coda is not helping on this.

This usability problem would have been avoided by removing the search button… There is absolutely no point to add a search button in this first landing page

A final consideration about 3 levels :

• a collaborative document : everybody can see everything, searching everything is cool and fun.
• the implementation of some processes : some people work on some pieces of data, search is not necessarily useful, you don’t want your users to be distracted during the process and randomly move from one place to any other. Let’s face it: search can be a problem.
• an app : every pieces of data and user interface can be carefully selected. In many case searching “everything everywhere” is a bad feature. No app make it possible to shows their internals.

According to what I understand on the one hand Coda considers the search “everything for everyone” as nice because Coda provide collaborative documents. In a wiki or with notion you are happy to search whatever you want.

But on the other hand it seems that some people actually use Coda to implement some processes. And in this context having “search and see all hidden things” is less than optimal. This leads to “usability” issues. Better said, the search everything box become a problem. Adding a button “hide search bar” would be an help. Some pages are process-oriented, some pages are document-oriented. Let’s the “search team” win for document and the “hide team” win for processes (it should win indeed, don’t show what is meant to be hidden should be the rule).

Finally a document as “powerful as an app” is probably not what coda really have in mind. Data security would require not loading all data in memory. This is a architectural problem to be solved.

Just to progress in the good direction, I’m suggesting at least to consider the addition of some toggles that remove the search buttons, open layout, next record, etc… They are already these kinds of “remove” buttons in Coda, and the ability to disconnect default features. This approach provides a powerful way for makers to take control over coda “do-whatever-you-want” and then to build their process implementations. Better said to move from documents to processes. Yes, this will not solve the core data leak problem, but at least this could improve usability. The cost of adding these buttons is quite low. So let’s dot it

(Obviously more would be better )

[Tamerlan_Kagarmanov]

Totally agree. The search bar is a big problem in Coda. All the power of interactivity and usefulness of Doc can be nullified simply because the user went to the wrong place. Certainly Coda as a whole lacks more ability to manage accessibility in Doc.

[Susan_M_Davis]

I’d like search to only reveal things that aren’t on hidden pages. Seems like the easiest fix. If you want to search across hidden pages you have to first UNHIDE those pages and that can only be done with certain access levels.

That would solve part of the problem but definitely not all.

What we really need is to be able to set more security levels across the board which I’ve seen discussed many times.

[Stefan_Stoyanov]

This discussion is going on for years. I remember one of my first chats with a Codan in 2017 about this, asking them when they would move from lovable to practical tool. The first requirement was/is to make coda more secure. And I don’t mean secure like non-hackable (nothing is), but rather dumb-user-clicked-the-wrong-link security level.

It’s so straightforward - 1. search only non-hidden content, and 2. get rid of the hyperlink to the main table which sits in the upper left corner of every opened row. That’s really all that is needed to make it “secure” in the sense that people don’t end up in places where they are not supposed to and start shouting “what did I mess up? I broke it!”

My first kid studied several encyclopedias and the second one learned how to read while Codans still haven’t learned this simple thing about the still-only-lovable Coda.

[Piet_Strydom]

Here is the latest information from Coda on the topic.

Sometimes something looks easy from an end-user perspective, but very complex from a technical perspective. Especially taking into account the total environment in which enhancements need to be made.

Launched: Sync pages and content sharing updates

all, Happy 2024 and I’m back to share another fun update with you all — you can now sync in a full doc as a sync page! This means that all existing and newly created pages from that synced doc will appear in the page list of the container doc, further breaking down information silos and allowing you to centralize and cross-reference your team’s most important docs. [Coda launch calendar] As is true for all sync pages, only users with access to the source doc will be able to…

As Ayuba points out in the message, they are working on step 3 of a four step solution.

Regards
Piet