Possible to change app permissions to "less invasive"

[GoogleCodeExporter]

(Not so much an issue, but more of a request)

Saving requests is great -- recently the app updated itself and reset the local 
database, deleting my saved requests, and unfortunately I did not have them 
synced to Google Drive.

Currently the app requires "view all metadata" permission for Google Drive in 
order to save requests, which makes sense in that you allow users to choose the 
folder to save requests too.  Offering control to the user is nice.

But, "metadata" is a pretty wide range of information beyond just title and 
folder -- it includes thumbnails and indexable text, among other things like 
location, etc.  Some of this could be sensitive (i.e. controlled by other 
restrictions).

Is it possible to remove or reduce this permission?  Much like the suggestions 
in this thread: 
https://groups.google.com/forum/?fromgroups#!topic/shiftedit/-oc3LhjzEP4

Potentially, like Google Scratchpad, where it creates a single folder and all 
information is saved to that folder, thus the app doesn't need to look outside 
that folder?

Original issue reported on code.google.com by jeremys....@gmail.com on 7 Jun 2013 at 8:42

[GoogleCodeExporter]

Just saw your applicable blog post -- 
http://restforchrome.blogspot.com/2013/02/google-drive-permissions-why-app-need.
html

As I mentioned, I understand wanting to provide a folder picker for UX, but 
from my perspective I'd rather set the default folder once and not have to 
choose the same folder over and over.  Since your app already organizes things 
into projects, I'm even less likely to need multiple G-drive folders.  If 
available permissions let your app create the folder, great, but I still think 
it would be better even if you ask users to type in the name of the folder 
they've created.

Original comment by jeremys....@gmail.com on 7 Jun 2013 at 8:51

[GoogleCodeExporter]

Good point. Thanks for your valuable input.

As for a data access. Yes, the app can read metadata. It include file 
description (I think you mean this as a indexable text), document's thumbnails 
and probably location (are you referring to images location? I can't find any 
reference to this point).
However I'm still not convinced. Let me describe my POV. 

You said that the app should create some default folder and there it should 
keep all files. But regarding a user experience it is a mistake. When You save 
your file, you should know where the file is. If the app create a folder for 
itself it is not obvious to the user where the file was stored. Of course I can 
show the user a dialog "Your file is saved in XXX folder" but still it is not 
good experience. Maybe someone wanted to save it under any other folder (for 
example project's folder). 
So. Now we are dealing with security vs convenience. I think that in this fight 
convenience is winning. For me it is a simple list of the pros and cons. Value 
of giving you flexibility is grater than not in order keep the app more secure. 
Especially when we are not talking about very important data like document's 
thumbnail (it is impossible to read any content from such thumbnail) or 
description. And the project itself is open source and at any time you can 
check source code. Or event extension's source code (part of the code 
responsible for Google Drive integration is not minified so it is readable).

Taking this into consideration I prefer not to change scope of the permissions.

If you're not convinced or your company's security policy do not allow use a 
tools with such permissions you can checkout a working copy of the project and 
alter behavior regarding saving/opening files on Google Drive.

P.S.
I need to re-design opening/saving files on/to Google Drive because not it is 
not always working. Maybe the output will be changing the permission's scope 
but I can't tell this now for sure.

Original comment by jarro...@gmail.com on 8 Jun 2013 at 1:36

[GoogleCodeExporter]

Thank you for giving my suggestion your consideration.

I'm not sure if you saw my second reply, so just for the sake of discussion 
I'll reply to your points and leave it up to you -- not trying to argue.

0. You've released the source code, and as you point out the extension is 
inspectable, so the security isn't really so much a concern (which is why I 
tagged this low priority).  For me it's more the principle -- it feels wrong 
when apps "ask for too much".  But you never know if something else combined 
with this app creates a security hole, that stuff is beyond me, so I feel like 
it's better to play it safe.
1. Metadata -- from these two links (https://developers.google.com/drive/file) 
and 
(http://stackoverflow.com/questions/12093934/google-drive-add-meta-data-to-file)
 the implication is that "indexable text" (which is different than the 
description) is automatically scanned content from the document itself, and 
assuming this is available as metadata it potentially means this permission 
would allow you to see at least some document content, hence my concern.  
Additionally, location data + image thumbnail could be revealing -- just to 
illustrate my point, I've seen cases when people have uploaded cropped 
headshots to image sharing sites that included a thumbnail version of the 
original image in the EXIF metadata, which turned out to reveal nudity they 
never intended to share (google "exif metadata thumbnail nudity" - couple 
examples linked from this site http://www.rlvision.com/exif/).
2. Regarding user experience (and this is just my opinion) needing to 
constantly browse for the same folder is less convenient than having the app 
save to the same place every time (which is technically a different request).  
But, are your saved files intended to be opened with anything other than your 
app?  If not, why would they need to be saved to a different location, as users 
would never need to find it outside of your app?  And finding things in the 
easily searchable Drive isn't really that hard even if you hid things 20 
folders deep.

Again, I appreciate your consideration.  Maybe you'll change your mind later, 
but if not, still a great app.

Also, good point about forking a copy, I might just to learn more about app 
design.

Original comment by jeremys....@gmail.com on 8 Jun 2013 at 3:00