Privacy laws and data protection

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