Restrict downloading and copying data

[anaisconce]

Restrict viewers of publicly shared, embedded, or even privately shared documents from downloading or copying and pasting data.

[dumblob]

Hm, why actually?

Anyone can make a (series of) screenshot(s). OCR is one click away on all windows installations.

So what's the point of making any such restrictions? Shouldn't we rather emphasize in documentation that public information is forever public disregarding format? That's the essence of the internet, right?

Btw. this is not hypothetical. I've been involved in large international military projects and guess what - OCR from screenshots was used on daily basis just because involved parties thought if they send a scanned document or photos of some data, the receiving parties can not copy them. Well, everybody did.

Legally once the data leave your internal circle and appear on the internet, if only for a second, it's considered as publishing them (unless it was obvious that it was a mistake on the publishing end in which case the court additionally investigates the intentions of the receiving party which copied the data).

[dsagal]

You are right that it's not a security feature, and we should be careful not to present it as such. It is, however, a frequent request. There are several possible motivations:

• Create enough friction so that "taking" the data would not be worth the hassle for most people; primarily because doing so would require time and technical expertise (like using OCR or even just the browser console).
• Clarify intended restrictions; e.g. if data is copyrighted and its author publishes it but intends to disallow copying, having a working option to make a copy would be misleading.
• In the same vein, reduce "crimes of opportunity"; if data isn't to be copied, saving a copy would require some intentional circumvention.

In other words, it's like locking a bike with a cable lock -- it won't stop someone intent on stealing it, but it's still a good idea in a range of situations.

[dumblob]

You are right that it's not a security feature, and we should be careful not to present it as such.

:+1:

It is, however, a frequent request.

From my experience such requests are motivated solely by lawyers. In other words it's your point 2 - Grist shall have the functionality to explicitly show a given portion(s) of data is not intended for copying. Note however that every lawyer will tell you this does not require any technical copying counter-measures.

• Create enough friction so that "taking" the data would not be worth the hassle for most people; primarily because doing so would require time and technical expertise (like using OCR or even just the browser console).

This is exactly what's 100% superfluous. If I tell you clearly up front (e.g. by a red triangle with an exclamation mark as e.g. some wiki systems do) you'll break law on many points if you'll copy the data. Then it does not matter at all how skilled the person is.

So again, such request from Grist customers is too noisy to understand what the layer somewhere behind actually has meant. Grist should educate customers about this - Grist is about data and this understanding is as fundamental as understanding relational model of data or understanding the permission model around CRUD.

Btw. removing a "Copy" button and implementing technical measures to create friction has generally zero meaning at a court because there is always a plausible "path" for the visitor how to copy it with "good intentions" (usually as a byproduct of something - imagine web testing etc.). So you anyway must implement an explicit way of telling the visitor to not copy the data (e.g. a banner with the red triangle) - but in that case when you already ensured the customer knows she must not copy anything, you realize there is absolutely no point in implementing any technical measures against copying.

• Clarify intended restrictions; e.g. if data is copyrighted and its author publishes it but intends to disallow copying, having a working option to make a copy would be misleading.

:+1:

• In the same vein, reduce "crimes of opportunity"; if data isn't to be copied, saving a copy would require some intentional circumvention.

I agree, but this does not mean implementing any copying counter-measure. I'd rather focus on stamping the data to make it clear it's an unwanted copy. Imagine one selected and copied a certain part of a table - then I'd randomly prefix many cells with some short warning statement like you're breaking law.

This is insanely more effective than disallowing every common method of the Ctrl+C operation (because then comes me who won't even notice it's disallowed because I use vim-like navigation in my browser and yanking uses some low-level operations which will happily copy the data - same happens to me every now and then visiting pages like Instagram where I just scroll using the vim-bindings without noticing scrolling is disabled due to me forgetting to confirm some "Cookie banner").

Look at picture & video sharing web sites - they understood this very well.

In other words, it's like locking a bike with a cable lock -- it won't stop someone intent on stealing it, but it's still a good idea in a range of situations.

As explained above, this doesn't work in the digital world as it does in the physical world (hehe copying is not stealing :laughing: - feel free to reference this from Grist doc). In digital world it's much better to somehow stamp or taint or otherwise slightly devalorize the data itself (the bike itself) instead of preventing the stealing (the lock).

[bamboowonder]

Any technically proficient person can take/steal/borrow whatever they want. But the reality for many small business owners such as myself, is I don't want to my staff to have a 1-click button to download the entire database in sqlite format. Or download everything in a pretty xls format. I know they cans screenshot or go into the devtools or any number of other things. I just want to limit the "noise" of a nice big button saying "download the company database, I don't mind". Having the option to download/export completely negates the access rules feature.

[paulfitz]

@bamboowonder I agree with what I think you are saying, but just to be clear for others reading: for a document with granular access rules, users without permission to read all the data are not permitted to download the entire document (in any format).

[bamboowonder]

A workaround I was considering, is to separate out sensitive information into a separate table, and then create pages where to see sensitive data, you would have to choose a specific record. But the problem with this is that the permissions are based on the base tables, not any page views/dashboard. So as long as someone can even read a table, it seems like they can download csv of the full table. Or like you said, any table they have access to. I'm highlighting this, because I think you have a fantastic, incredibly agile tool that I'd love to roll out to our small team. But I just can't do it until there is an ability to restrict data download by users with limited permissions.

[dumblob]

@bamboowonder after reading your comments I'm pretty sure you want something different than "restricting data download by certain users". You actually want a specific permission-like setting disallowing "explicit batch download" of the data.

Such permission setting would not disallow copy&paste or whatever. It'd simply hide any existing batch-related features of Grist (e.g. any buttons "download whole table") for the given user/group.

Note though that this is IMHO still does not necessarily need to exist as a separate setting as this should be automatically done if you selected "Warn that copying of the available data is legally prohibited" setting (which doesn't seem to exist yet :wink:) as I suggested above in https://github.com/gristlabs/grist-core/issues/91#issuecomment-1055253947 (the banner with red triangle).