Protect the Share or Copy Doc function for the upcoming permission feature

Hi Codas,
Recently I came across a particular need from several potential “New Coda Customers”.
It turned out that sometimes it’s extremely important to protect data inside a doc and/or other times the whole doc itself. The reason is that the doc can contain several “sensitive” data and it should not be shared/copied around…

They are asking (and wondering) whether the possibility to prevent the copy/share a doc will come in the Permission Settings for the Team Plan…I think this is very important for companies/teams and permission should manage that!

@BenLee FYI… I don’t know if you are involved personally about this features about permissions but please share this to the right product(project) managers… :pray:

6 Likes

Hi @Francesco_Pistillo,

These are definitely items that we are thinking about and exploring ways to implement. For situations where there is data that cannot be shared in a doc, Cross-doc might be a good alternative. In the original doc, create a view of the table to be shared and hide any columns you don’t want to be visible in the new doc. Then in the new doc, when you sync it over, any hidden data in the first doc is not retrievable in any way.

Locking, permissions, and protection are difficult for a multitude of reasons and not really something a simple toggle can take care of. One example is thinking through what’s available through formulas within the doc if some data is there but shouldn’t be used.

Here is a better post explaining some of these items and the hurdles we need to consider while building this out…

I know this doesn’t answer everything for you as it is all still a work in progress as we explore the best ways to implement these solutions. Your feedback is definitely heard and we’ll keep moving forward with it!

Ben

1 Like

Connecting some dots :point_right: https://www.crowdcast.io/e/wsqiqgcs/ - Codans Jaime & Maria answer on this topic @ 25:15 to 28:00 & 43:15 to 47:00

@Francesco_Pistillo was the person who asked the question in the webinar @ 25:15

@BenLee hey is there a way to prevent a document from being copied? I want to invite someone to work on it but dont want them to be able to wholesale copy all the data. I am aware of crossdoc but that isn’t the solution to this.

1 Like

Right now we don’t have that feature. It’s something that’s being discussed though.

2 Likes

OK so I understand @BenLee - locking, hiding, view-only permissions - all of these still allow a user that has any access to a doc to duplicate the whole thing? Thanks for helping me it is easier for your advice than for me to try to gametheory and try out all the possible permuations.

1 Like

Hi there, any update on this essential feature?

A simple solution would be to add a feature in Settings / Locking (cf. screenshot)

Allow “Copy”: True, False

If false, the “Copy” feature in the menu is not shown.

Looking forward to your reply.
PS: Protecting your clients’ data should be one of your top priorities.
Thanks & Regards!

Remove Copy Feature|212x500

2 Likes

We definitely hear you, and you’re right, that would help prevent people from copying a doc. The difficult part is that the doc is still downloaded to a person’s browser so they can view it, and if they are particularly crafty, they can see all the info in the doc. So while you’re right that this strategy would hide the copy option, it wouldn’t be a true security feature.

If you do have information that you need kept confidential while displaying other information, the best option from a security standpoint is still cross-doc and only syncing over the information that is okay to be shared.

This is a topic that we discuss a good bit, and we have explorations going on to keep researching this, just don’t have a project centered around it yet. We’ll get there, but have more discovery to do first.

4 Likes

Hello Ben,

As you know I have been particularly concerned about this, even though it doesn’t stop me from doing amazing things in coda. I (think I) understand the concept of working with data in coda and since this is not a database, I realize it is very complicated to keep everything working and secure at the same time - to make it really secure it needs to work more like a database application, which is not what coda is.

That said, I have two suggestions, one for ‘immediate’ implementation and one for, maybe, later, although I am not sure the 2nd one is even feasible. My concern is shared docs, with the invited people being editors. I don’t want (some of) my docs to be published, just shared.

  1. with everything I know at this point I realize the full doc is downloaded to the browser. That said, there is a big difference between having a standard copy facility, which allows the user to look at a complete copy of the doc, without any filters and with the complete data structure in tact, or having to reconstruct all the dependencies from a source file. So, please, make the copy facility optional! This can’t be all that complicated to realize, since this option is taken out of published docs too.

  2. long term, we need a more secure way to present our data to our users. I see 3 possibilities, none easy, but something needs to be done at some point.
    a) make all tables a view of data stored in a database and filter/allow acces based on authentication - obviously this requires a complete rewrite of coda and templating and copying are a complete different animal from what they are today. But is solves the issue we are now writing about and it solves a lot of other issues too. Working offline might be complicated or not possible anymore, I guess the user has to decide if that is OK (for me it is, we have excellent internet just about everywhere.
    b) store the doc encrypted on the users computer and unencrypt only what is viewed. Not sure if this can be done though, it might open up a complete new market
    c) do some processing of the docs on the backend and only send to the users what is needed to build up the screen. This would not necessarily make the doc slow if the backend and internet connection is quick enough. I think I would like this best.

But please, start with my suggestion under 1) and give us at least a small barrier (no build in accessible copy command) against prying eyes. I realize this won’t protect real sensitive data, but it will help a lot.

Thank you for your consideration,
Greetings,
Joost

PS: in published editing mode this seems to be taken care of, but the doc is (partly) open to anyone with the URL - fixing that would already be a big help Just show a (custom) login page on that URL and nothing more (of publised doc in edit mode) would make me very happy!

15 Likes

Yes please! Thanks for sharing this @joost_mineur !

5 Likes

Thanks for your answer.

Maybe it does not entirely solve the problem, but it greatly helps.

The vast majority of our users are not techies and will not learn development languages to find solutions to circumvent this.

You should add a note to the admins that this solution is not entirely secure.

I am quite certain that your paid users will appreciate this patch until you find a better fix.

I hope you’ll implement it ASAP as it is greatly needed.

2 Likes

This is a good time to acknowledge the accomplishments that have materialized since the original start of this thread. Even though I can think of more fine grained authorization schemes, you can protect your work to a large extend at this point in time (June 2021) by combining locking pages and setting non-copy options.

I feel a lot more comfortable now sharing my docs with more people.

Thank you Codans.

5 Likes

Hi Joost

What do you mean with the below?

Is there some way to prevent people from making a copy of a document? Or are you talking about some other copy options?

Regards
Piet

1 Like

Yes! In the advanced options inside the share dialog you can toggle off the ability to copy a document.

It’s the little filter-toggle button thing in the top right of the share dialog after you select “share”

1 Like

That is indeed what I was writing about.

1 Like

Wonderful, thanks!

And some more characters to make it long enough…

1 Like