Limiting downloading, copying and printing for EDITORS in Google drive - google-apps-script

I am looking to find out if it is POSSIBLE to restrict EDITORS from downloading, copying or printing a Google sheet or other documents in a Google Drive. We share sheets/documents with our customers so they can fill in the details. For that we need to make them EDITORS (so they can edit and even invite others to the party). I know that we can restrict COMMENTERS and VIEWERS from downloading, but in our case we need to prevent EDITORS.
We have a LOT of intellectual property in our sheets (custom formulas and approaches), and we would like to be able to prevent people from simply downloading it. As I understand it this SHOULD be possible using the Google Drive API, but I have not been able to figure out how to do it, yet. Looking at the API it obliquely says it MAY be possible, but it is not clear :-(
Direction, or sample code, would be VERY much appreciated.
TIA

It's not possible to restrict editors from downloading files. The documentation mentions that only commenters and viewers can be prevented from this. Then in the API docs concerning permissions and their definitions you will see that there's nothing controlling downloads either. This is just a UI change.
If you think about it, the reason is clear: Even if you manage to stop direct downloads, to anyone with at least read access to the file or API this is just a minor inconvenience. They can still read all the content and metadata from the API and replicate the file perfectly. Even viewers with copy disabled can still read the formulas from the formula bar. Sharing the Sheets file is inherently unsafe if you have confidential data in it, since a determined attacker can still get all your trade secrets easily. You're only supposed to share these files with trusted users.
My suggestion is to take a different approach. Do not share the Sheets file at all and use something else as intermediary to request data from your customers. For example:
Create a Google Form to save the responses to a Sheet. Your customers will only need to fill out the form and the sheet will be filled with data that you can handle on your side.
If you need the users to also view some information in the Sheet before filling out their info you can build an Apps Script Web App that displays only the plain data that you need to show them. With this you can hide the formulas and other sensitive information. Using templates and server functions you can allow the users to interface with the Sheet data similarly to how they do it now, but with a more restricted view. You could even allow them to edit only the data you want them to. This requires more work and is starting to delve into web development, but It's much easier than a fully fledged website since the hosting and interfacing with APIs is handled by Apps Script.
You could just create your own application and use the Sheets API to read and write data from the Sheet. This is pretty much the previous suggestion but much harder, though in the end it will give you more flexibility.
The bottom line is that sharing your Sheet in any way is akin to giving your users full database read or write access, and there's no single setting that can prevent that. Your best bet is to avoid sharing these files and use a different method to request user data.

Related

How do I avoid Google Drive API audit? -- Only Read access is needed to list files from folder and to download them

The product I'm working on currently uses the scope "https://www.googleapis.com/auth/drive" (which is now "restricted" by Google), which gives full read and write access to a user's Drive account, including app metadata. But we only need read access to list all files and folders inside a specific folder, and we need to be able to download those files, that's all.
Google Drive API will soon apply the new "restricted" scope policy (https://support.google.com/cloud/answer/9110914#restricted-scopes), which will require us to go through a very expensive audit (tens of thousands of dollars...). Is there a possible workaround to get 'read-only' access on a specific folder, and avoid the audit (note that https://www.googleapis.com/auth/drive.readonly is also a restricted mode)?
I'm aware of the "https://www.googleapis.com/auth/drive.file" scope (which is "recommended" by Google, so no audit required), which almost solves this problem. But we have thousands of users bringing in data from multiple Drive Folders, and pushing new files daily. This scope would introduce a manual step for a client each morning to have to "approve" every new file, and this would be a big scalability/usability problem.
Ideally, I would like Google to add a new scope, like a read-only access to anything inside a folder, before they go forward with their audit... but i doubt that this will happen soon.
Does anyone know of a better option?
[EDIT] For reference, here is the list of scopes and we can see which ones are "restricted", "sensitive" and "recommended" : https://developers.google.com/drive/api/v2/about-auth
Solution
Hi! So after taking a better look at this it seems that restricted scopes do NOT require any paid audit. The main difference is that they will have a wider access to user's data and thus it requires you to go through a restricted scope verification process.
You can use these restrictive scopes (the one that best fits your application) without the need of paying any audit. See more information about how to implement restrictive scopes here.

Sharing google sheets udfs with coworkers and how to tell if your company uses google apps for work

I read this:
https://developers.google.com/apps-script/guide_libraries
and
Distributing Google Apps Scripts for Sheets in your company network
I have a simple udf for google sheets that I'd like to share with a couple other people. Whenever I need it for a new sheet, I just copy and paste the code into the script editor and run a smaller function in debug mode. Then the computer asks if I give permission to my little script to run and I say yes. If other people want to use my udf, I can't expect them to do the same thing because they're not programmers. Well, I'm not either, but I try. Anyway, is there a way to share it without publishing an add-on or that domain admin sequence of events or anything involving long authentication strings or oauth2.0. all of this is too overwhelming for me as I'm not a real programmer.
Also, is there a way to share the udf without sharing the code, because the code is constructed embarassingly and more importantly, there is some info I'm not sure I'm allowed to share.
Speaking of things I'm not sure of, I'm not sure if this counts as an app for work because we use the app for work, but it seems like your company has to pay for something to be considered an app for work even though these apps seem like they're for free.
Apparently there is an open issue regarding Protect Google App Script. It would be best to follow this ticket to be update on how you would be able to protect your apps script code. Migrating your code to an external script and make it as a library would protect your code from editing but not from viewing.
Creating an app for your company may not be considered as an app for work. According to this document:
Google Apps for Work adds business-specific features such as custom email addresses at your domain (#yourcompany.com), at least 30 GB of storage for documents and email, and 24/7 phone and email support.

Drive Realtime API typing for Drive docs?

I want to create an app that "types" into a text document in Drive. The goal is to have a document which is publicly viewable, if not editable, and a program which enters text into that document as though it were being typed by a person. If I use the following Drive API endpoint PUT https://www.googleapis.com/upload/drive/v2/files/fileId
will a viewer see the edits taking place a character at a time? (assuming I upload each version with one character difference). Or is there a function which would allow me to programmatically "type" each character?
My perusal of the Realtime API makes it look like this is what I want except that it involves setting up a separate page, where what I'm looking for is just the ability to write to a doc in Drive, in real time. Am I looking in the right place?
If you just want a background script that writes to a file, you probably don't need the realtime API. This is more designed for multiple users making changes at the same time.
However, it may be possible to accomplish what you want using the import/export functionality.
Use realtime.get to get the contents of the file as json. Then use realtime.update to post a modified version of the contents. This will cause the diff of the get and the update to be applied to the realtime model. Any active clients will see the changes come in as some new characters added to the document.

Real-time Changes to Google Document / Spreadsheet / Presentation

Is it possible to get a real-time notification (without extensive polling) for changes made to a Google document (document / spreadsheet / presentation)? If so, what is the model structure (if that makes sense)? Any pointers to documentation or samples would help!
The documentation at https://developers.google.com/drive/manage-changes gives an API call that returns instantly and tells you whether there have been any changes since the last one. However, this is useless you want to know almost as soon as a change has been made -- you would have to make back to back API calls every second or sooner and churn a lot of resources. The Drive Real-time API in contrast gives a way to be instantly notified of any changes without extensive and frequent polling. It does this with an HTTP call that "hangs" until there is a change ready (or a timer expires). This is a classic long-poll technique.
My question is whether such a facility exists for Google Documents / Spreadsheets / Presentations. Or is it available only for custom app-specific files other than these standard ones. If it is not available, are there any plans for making them available?
Thanks in advance!
In my knowledge - the answer is "NO". I have tried this before and could only do it with the timed polling. The API is limited to tell you only when you ask, not when something happens.
I thought of a code that is embed into document and does a self broadcast to a specific URL or some listener. My experiments were with Google App Scripts. Detail idea is to create a custom function that gets triggered on the 'Save' event. But I could go no further as there is nothing enough in documentation as per me to achieve this specific goal.
On the timelines for this availability, there are questions in the scripts forum on this, but none replied on these lines.
It looks like it, see https://developers.google.com/drive/v2/reference/changes
it has examples too
edit:
https://developers.google.com/drive/manage-changes
more info about tracking changes
The answer, I'm afraid, is no. There is currently no way for you to be notified by email when a change is made to a Drive text document. This function is available for spreadsheets, but not for text files. If your document is public, you ccan subscribe to its RSS feed to view changes, or use the Tools -> Revision History function in Drive.
There is one downloadable program, googledocsnotifier --information--, which emails you when edits are made and allows you to open the doc that was edited, but it appears that it only works when you are online. You can download it here.
Hope this helps!

Calling a Google Drive SDK from Google App Script application

i have been going around in circles here and have totally confused myself. I need some help.
I am (trying to) writing an application for a client that in concept is simple. he want a google write document with a button. the google drive account has several folders, each shared with several people. when he drops a new file in one of the folders, he wants to be able to open this write file, this file is the template for his email. he clicks the button, the system calls the changes service in the Google Drive SDK https://developers.google.com/drive/manage-changes, gets the list of files that have been added since the last time it was checked, then pull the list of people that the file has been shared with, and use the write file as a template to send that list of people an email saying their file is ready.
SO, easy enough, right?
I started by looking at the built in functions in the Google App Script API. I found this method, https://developers.google.com/apps-script/class_docslist#find in the DocsList class. problem is the description for the query simply says "the query string". So at first i tried the Drive SDK query parameters, which are
var files = DocsList.find("modifiedDate > 2012-12-20T12:00:00-08:00.");
it didn't work. that leads me to believe it is a simple full text search on the content. Thats not good enough.
That lead me into trying to call a Drive SDK method from within an App Script application. Great, we need an OLap 2 authentication. easy enough. found the objects in the script reference and hit my wall.
Client ID and Client Secret.
you see, when i create what this really is, a service account, the olap control in apps script doesn't know how to handle the encrypted json and pass it back and forth. Then when i tried to create and use an installed applications key, i get authentication errors because the controls again, don't know what to do with the workflow. and finally, when i try to create a web app key, i can't because i don't have the site host name or redirect URI. And i can't use the application key ability because since im working with files OLap 2 is required.
i used the anonymous olap for a while, but hit the limit of anonymous calls per day in the effort of trying to figure out the code a bit, thats not going to work because the guy is going to be pushing this button constantly thru the day.
i have been pounding my head on the desk over this for 5 hours now. i need some help here, can anyone give me a direction to go?
PS, yes, i know i can use the database controls and load the entire list of files into memory and compare it to the list of files in the database. problem being, we are talking tens of thousands of files. bad idea.
I wouldn't use DocsList anymore - DriveApp is supposed to be a more reliable replacement. Some of the commands have changed, so instead of find, use searchFiles. This should work more effectively (they even use a query like yours as an example).