Privacy laws and data protection

Suggestion Box
1

To all Codans,

Although I have not read every post, I can’d find much about where Coda stands regarding privacy rules and regulation.

European (business) users have to comply with pretty strict regulations, one of them being where your docs are stored (if they contain certain kind of data), sometimes it has to be in Europe. As far as Coda goes, being hosted on AWS, I am wondering if this is (going to be) an option, or if you would consider allowing the user to have a choice (or make an automatic choice based on the residence of business that has the Coda subscription). A nice side effect would probably be that for your European clients, Coda would perform a bit better, although I am not sure if this would be noticable.

Another big issue I am running into is that I can’t find a way to really make sure some people can’t look at certain data. With locking I can protect data from being altered of deleted, but there seems to be no simple way to hide data and I don’t understand how this can’t be an issue for many users. I can hide pages, but that is no protection against prying eyes. For the long term, I have to be able lock and really hide pages (and tables) for groups of users, on the app and on the PC.
That said, we need to have a couple more options for sharing, right now there is only view, edit and comment, but only the editors can use the ‘apps’, but when you make someone editor, they have full access to everything right away. With locking this can be tuned a little bit more, but they have view acces to any table and collapsing does not do the trick. It would really help to allow for more groups of users (defined by us, the users, or predefined by you) and allow us to set per page (or better yet, per section) if they can see these pages (or sections) at all, and what their permissions are. Of course, the tables/functions should maintain their programmed access to the hidden/locked tables.

For the record, putting a lock on the page/section that holds subpages does not lock the subpages (and the links on the group page keep working, lock or not (I guess because the are just links and they are not stopped by any of the locks).

I was hoping to solve some of this with cross doc options, but considering the delay on (auto)syncs and the code required to do add/modify/delete this seems not to be a real option.

I know I am asking for quite a bit of things, but I am building a serious application and it requires serious data protection (location and functionality). I am looking forward to keep on working with Coda, even though still being a newbe, Coda allows me to do so many things so much faster then ever before…

1 Like
2

I’m not a Codan, but I keep seeing these and replying to these.

Regarding GDPR and storing data in the EU — valid point. Not sure though how having your doc in someone’s cloud in the EU cluster would differ from having your doc in someone’s cloud in the US cluster in terms of privacy. But I am not a lawyer, and I’ve never studied GDPR that closely to be able to comment on this though.

Regarding hiding, locking, filtering — these all are NOT security features. And Coda is NOT an app builder platform. I’ve said it many times, Coda is a doc (quite literally, Coda is “a doc” spelled backwards). Its closest rival is spreadsheets; it borrows some design choices from relational databases (tables) and app builders (buttons and actions), but in the end it is still but a doc. Think of sharing a Coda doc as the same as sharing an Excel or a Google Sheets file. It’s just as monolithic by design as an *.XLSX, and no amount of locking and filtering can prevent people whom you shared the doc with from accessing the entirety of it. When you load a Coda doc in your browser, you load the entirety of it — there’s no server-side processing of which portions to serve you and which to withhold. And I don’t think it’s ever going to change — the impact on infrastructure would be massive.

Using cross-doc or API/Zapier are indeed the only correct ways to actually restrict access to parts of the data from a doc. They come with their own drawbacks, but there are ways to minimize their impact.

Here’s another place where I say that again (funnily, to the same person asking).

My bottom line would be this: if you’re looking to build a serious application with serious data protection and also scale, Coda shouldn’t be your choice there. You’d be much better off with either using an actual app builder like Bubble with an actual database like MySQL on AWS, or going with an enterprise-level app builder, or even as far as developing a traditional web app.

Addition: too big or too serious.

5 Likes
3

@Paul_Danyliuk

Good morning Paul,

Thank you for your elaborate answer. It is not what I wanted to hear, but it is the way it is.

About cloud storage: to simplify the answer: some laws apply based on the physical location of the cloud storage. In Europe, the governments are really concerned about how the US government can force access to data stored in de USA. So it matters where the cloud is stored (and perhaps it matters which company manages this cloud). I am not an lawyer either, but in layman terms this is what matters.

About Coda as a doc rather than an app: these things become more fluid as time progresses. When I see at what speed a doc is synced across multiple devices, it seems to work like an app. I hope my questions will trigger the Codans to implement some if the wishes a lot of users seem to share. I have read through the other thread you are referring to and I do understand the current limitations, but I see a lot of things being implemented, so who knows, maybe an integration with an online database is possible in the future (I certainly hope so).

At this point we have something that works for us, but we have to limit access to people that are associated with our team and we still have to be careful about which data we store in these docs. Through an API we grant acces to third parties, because we seem to be able to control them accessing only their own data. The size limitation will be an issue, but maybe that will solve itself one of these days.

4

Good conversation here and good answers to where we are with the product at this moment. and Paul is right in that adding permissions to that extent is quite an undertaking and also that it’s not something you see in other systems of the doc style either.

Here is a link to our Privacy Policy and you’ll see more write-ups on security and terms of service there as well. We are GDPR compliant. As far as data centers all over the world, that’s something to be tackled when the company grows more. There are quite a few other areas of the business that are impacted as employees and data are located in various places and that requires a significant amount of overhead.

For GDPR and CCPA we are compliant and we’re also keeping our eye on others that are popping up all over the world as we speak.

5

I have been thinking a lot about these matters, and another one as well (maximum table size). I am pretty OK with the GDPR compliancy, the problem is not that CODA is not compliant, the problem is that we, developers/users are building ‘applications’ and adding different kind of users of our apps (to keep the discussion simple: team members, company employees and third party users) and that these apps can’t be made to be compliant to any regulation, because I think it is impossible to really protect access to critical data (at this point in time). Hiding pages is a start, but if someone happens to know the page url’s , everything is wide open. Even though I think it is almost impossible to guess these URL’s, access is granted to anyone who knows the URL.
This is a serious issue and it will keep a lot of people from using coda.

I have been going through a lot of messages in the forum and there are a couple of things that really worry me (my my user case): 1) coda must been seen as a doc and a doc is loaded in its entirety, 2) the tables in coda are not databases, but tables and 3) if it doesn’t work in a spreadsheet, it won’t work in coda.

I have been doing some testing and indeed, a 17,000 row table becomes pretty much unusable. I have spreadsheets with a multiple of that number or rows that perform really nice. I am wondering if a 1000 page doc will perform if it has to be loaded in it’s entirety? I haven’t tested that yet, but I am seriously worried if it has to be loaded completely every time you open a doc with that many pages.

I have build an real life real time application in coda over the last couple of months that would have taken me a year or longer to build with conventional tools. Not only that, but modifications are really easy to implement. I am 100% convinced that the things I am building in Coda right now would not have happend in any other environment I have tried to this date. I have gotten to love developing in Coda in the short time I have used it. That said, I know I will reach the 10K rows in one of my tables within the next 24 months and I am not looking forward to what will happen to my doc. I am also worried about the real time updates across our users when our docs and tables become bigger.

For me, what is needed, is an elaborate access scheme and for tables to be populated by database records, so our ‘tables’ can grow. I also think that pages should be database objects, or be other type of objects that are loaded in a background process or on an as needed basis, rather than be part of one doc that is loaded in it’s entirety - that concept is not going to cut it when a doc gets big.

Of course, I will respect the choice of the developers of coda. If the future development is along the course of making this a better document builder, people like me have to go look elsewhere. My expectations were to be part of a project that will tackle these things and I have some time to sit it out - if I know some changes are on the road map. Honestly, working in coda has some huge advantages, but if things like table size become a limiting factor (because tables are not being served by database engines), coda will only serve relatively small web-apps.

I am missing the voice of codans in these type of discussions, they could make it clear if it is worthwhile so sit it out or to move on (I’d prefer to sit it out). Someone pointed out (somewhere on this forum) that all the claims about unlimited this or that or a bit misleading. I am not going to make a statement like that, I understand there will probably never be such a thing as unlimited, but if 10K rows is a workable limit, it is a lot less than unlimited.

Again, I like what I can do with Coda, but for me, I need to be able to scale up, If I can’t, I have to move on in a hurry to make sure I am won’t be using a beautiful app that doesn’t perform. So please, tell us if this will change for coda or that we can only use coda for not to big projects, In my opinion, tables, in an app environment like coda, should be served by DB’s, not by smart doc’s.

Thank you for your consideration,
Joost

6

I think what’s being missed here is that Coda is a growing product and all of this doesn’t happen at once. When you say…

I am 100% convinced that the things I am building in Coda right now would not have happend in any other environment I have tried to this date.

That’s because of the focus on features and how the product functions. We can strip a lot of that away and only focus on performance, then you’re stuck saying that you need more features. In reality, both sides are seeing improvements and both features and performance will continue to get better.

The question is do you want a data repository or do you want a doc that functions like an app? If you want hundreds of thousands to millions of data points, you’re looking at a data repository. If you’re looking at thousands to tens of thousands, then a doc can work. Getting to the upper end of that will require efficient doc building and time for the product to get there. I also have a Coda doc that has ~10,000 rows and it loads in at 18 MB, so I still have a lot of room to grow here. It depends on your mix of features and data and engineering the doc to work for what you need. I’ve also crashed Google Sheets at 100,000 rows, so Coda really isn’t far off in capacity.

For sharing, I think you’re looking at a data repository with a frontend interface that has a lot of control over what is displayed and how it’s accessed. Coda is not an app builder, it’s a doc that is easy to jump into and create an app-like experience. If you need to keep some data more secure than other data, you can use Cross-doc to pull in only the relevant data and keep the other doc private.

It sounds like you’re describing use-cases of running databases and reaching for those types of functions. Coda might not be right for this particular use-case. All I can say is that it will continue to grow in both function and performance.

1 Like
7

Let me assure you I am not complaining. I understand what coda is and, as it goes with any tool, one tends to stretch it as far as possible. I realize there is a trade-of between performance and easy of use and features.

I also understand this is an environment in development and I am very interested to see where it goes. That said, there are a few things I had not anticipated, like performance issues with large tables and the pretty much open acces to my data. I do think this will be an issue for a lot of people and I hope some if these things will be addressed. For now I can do what I need to do and we have solved some of this by limiting access through the API, but when the tables grow we will run into some issues. Maybe Coda can handle larger tables in the future, maybe there will be an integration with a true database - I will wait and see.

If I don’t share my issues and comments nothing will happen for sure.

8

PS: Coda is being promoted as a (better) alternative to excel en SQL. For a lot of use cases it is, but not for all. I read somewhere on the forum that these type of statements are misleading. I don’t want to make a statement like that, but maybe a bit more information about the limitations prevent expectations that can’t be fulfilled.
Another thing that comes back in the forum is the need for a roadmap. So many new things are being developed, why not share with us what is coming…

1 Like
9

There are quite a few use-cases where Coda does offer significant advantages over other systems, especially for those looking to use something closer to no-code. It’s also good to remember that there is a very broad range of use-cases that Coda handles. As you get towards the extremes, yes, there will be some hurdles to cross, but in general, we handle a lot.

The community gives a somewhat skewed perspective of how most people are using Coda. Community groups tend to be more of the power-users of a product and those looking to push limits. When backing up and looking at overall stats, many times the community sentiment or popular use-cases here account for less than 0.1% of the overall customer base. We push limits here and we want to find solutions and keep pushing limits here, which is great, we just have to also know that we’re looking for the edges and playing on the edges in some cases.

It’s because of this enthusiasm and willingness to push limits on a product that we see so many creative solutions and ideas happen here. It makes it a place of extreme creativity and highlights possibilities that we may not have realized the product had until seeing it on the community. So it really is a place that pushes things forward at Coda. We’ll keep doing our best to grow, and we do that pretty well and pretty quick, just not instant.

As for the roadmap issue, there are several topics posted and I’ve tried to answer in a few. When I got to Coda I was absolutely blown away at this teams ability to work together. There are goals to aim for, but many times someone finds a way to work the code that gives benefits in a couple areas and this is a team that can react to it that day, shuffle projects to take advantage of the change, and turn around other features quicker, and in-turn, get to other projects quicker.

Being able to shuffle projects to take advantage of momentum and maximize efficiency is what keeps things moving quick here. That also means that roadmaps can be pretty loose guidelines. So we have an idea of what we’re working on, but keep a lot of room open to maximize opportunities that pop up. This is a workflow that we’re sticking with at this moment and we feel like a roadmap would detract from it. So for now the roadmap is keep making Coda easier and more fun for people to do more.

4 Likes
10

Hello :slight_smile:
i just wanted to add my voice in this thread :slight_smile:

It’s nearly 2 years that i’m working on the same doc here in coda, after trying every possible (not kidding) alternative and after a 4 month pause last year in which I had left coda for performance reason, i’m back, and i’m still working on that doc

That doc is made 100% to be an app
An app that my user will be able to change as they like, without being coder
Just to say my app is actually the most advanced animal nutrition managing tool available in the market (for people, not pet food industry)
I’ve managed to create it in 2 years but i could re-code it in a months now probably, my competitors (serious software house) are struggling to get what i’ve done (and in no way with mobile support, modern ui ecc), and also if they could, i could add new features in days

To sum up: when i will launch this CODA APP it will be always one foot ahead the competitors, and if a new crazy feature need to be there i can manually (one single man) and in less than a week add it.
Companies struggle to do those in longer period of time, with a cost, i just need some pizza and a coffe

I really feel this part of your message @joost_mineur

I’ve had been in the same exact situation, but i’m here after all!
The doc i’m working on is made to contains all of my users data in one single doc, making it huge (2-way cross doc please come here :smiling_face_with_three_hearts:)
And if user base is intended to grow i’ll reach the unlimited limits in a short time
I’m aware of all this limitations and my app is growing with them, solving one issue after the other thanks to tricky workaround and some help from the community!

I’ll never understand the coda love for the business management world, where you have to deal with sensitive data’s and business man all time, you find some serious business problems, like security and data protection.

I believe in coda as a tool that empower people, normal people with normal problems
And then communities, every community worldwide could create his own software (ok not every type of software but we are all aware of coda possibilities) changing the way they deal with data, giving those in their hands!

I really believe that coda IS able to birth apps
Just different from the concept of apps that we are used to :slight_smile:

I’d love to see some more love for the normal people out there, basically there are no pack intended for non-business related things and it seems that everything roll around meetings and kanbans and business managing oriented platform.

Normal people have data too you know?
We struggle to deal with those because we do not have commercial profits to build our own software and normally we do not code

Coda allowed us to create beautiful “data collecting and processing platform” (i’ll just call this apps) in little amount of time, no-code, mobile and user friendly manner from the first letter pressed.

And for the first time ever a complete random guy from nowhere with zero code skill have been able to put together the most advanced pet nutrition manager for people in a “little time” and completely by his own

This is where coda should go in my opinion, this is the real revolution, empower first people, then companies

In any case, also like it is now, and also if coda will become mainly a business organizer connector/platform i will always use it and love it

I just wanted to say my thoughts about coda future, and try to pull it in the people life side
Thanks for reading this long post, have a nice making everyone :blue_heart:

12 Likes
11

Hello Mario,

Thank you for sharing your thoughts. Let me assure you I am already convinced about the advantages of Coda. There are so many things that work so well, but no matter how nice the Codans are, I am sure they have to pay their mortgages and buy their groceries - and the money has to come from somewhere. I am perfectly happy if a bunch of users can live with the limitations of the free version or the lower priced plans, but I think those plans are supported by the higher priced plans. And for people to be willing to pay for software, the software has to grow with their needs.

My project is for a very low profit business and we are still willing to pay, but we don’t want to invest a lot of time to find out we are going to run into (to) many limitations. 10K Rows seems like a lot of rows for a to do list or a household budget, but for many professional projects you will reach this number of rows in a hurry. From what I understand Coda is at this point not really designed to handle that many rows, even though things like grouping and extensive filtering seem to be made for handling larger arrays of data - and that is exactly what power users want to do. Fine if you don’t need it, but great if it is possible, in particular with the easy one can build apps/docs in Coda.

There are work-arounds and you can split tables into smaller tables or export data, but that requires a lot of extra work and personally, I don’t like work-arounds, because it takes a lot of time to solve simple problems, eventually they tend to break and they are cumbersome to maintain.

As the platform becomes more mature, some of my issues will be solved. I hope that posting about the bottlenecks we encounter will help get these bottlenecks on the roadmap. A lot of things I ran into were possible from the start (but I didn’t know how to use Coda to address these things), quite a few new functions have been implemented in the last couple of months, there are some undocumented functions that deal with some of the issues I have had from the start (like displaying European times and dates).

So I have faith that items that more than a few users have run into will be addressed. Even if these are just the power users (at this time), everyone benefits from a better Coda - you don’t have to use features you don’t need.

I am surprised to see how easy it is to setup new tables and do fantastic things with the data stored in these tables. I understand it is quite a job to make the current tables into database tables, but if I see how excel and sheets and databases are ever more powerful to deal with the same problem (storing and manipulating data), I hope that at some point a database will be part of Coda - I am convinced it can be done and I am convinced Coda will attract a lot more (paying) users, which is good for all of us. Same for protecting data or sheets - it is already part of Coda, adding a few more options to the locking scheme (like an extra option that says: can/can’t delete rows <edit: has been implemented in 2022>) will take some effort, but it is probably not rocket science.
So as long as I see that Coda is being developed, I will post the things I run into in the hope some of it will be picked up.
I have read about how some people build cross doc solutions to solve some issues, but from what I have tried myself, that is not a long term solution. People are doing it because they like Coda so much (same for me), but it is not the real answer.
Having said all that, I repeat that I really like Coda, I will use it to the limit and I hope it will keep on getting better and better.
Greetings,
Joost

3 Likes
12

The only system I know that provides excellent user permission control is Quip, owned by Salesforce. It is more a doc with simple tables.

13

What is the current state in terms of GDPR compliance and Coda? I’m a german enterpreneur and I really want to use Coda extensively and everyone I’m shoing the tool here does the same. So would be amazing if german and European regulations are considered.