Prevent 'transfer of ownership' of Drive files, without first acquiring consent from the recipient?

[s_K]

Hello all,

Is there any way to prevent a Google Drive user (within our Workspace domain), from using the 'transfer of ownership' feature?  Or at least some way of allowing the transfer to go ahead, only after the _recipient_ has given consent?

As the feature stands, there seems to be nothing stopping 'User A' creating a file in their Google Drive, sharing with and promoting 'User B' to Editor for that file, then initiating a 'transfer of ownership' - all without consent of the recipient / owner of the target Google Drive.

Essentially, 'User A' could create a document with nefarious or questionable content, and then transfer that document to the Google Drive of 'User B'.  Audit trail notwithstanding, the end result is that 'User B' now has a file that they did not create or have any responsibility for, stored in the root of _their_ Google Drive, with _them_ marked as the owner and using _their_ Drive quota!

In other words, User A has now dumped their (potentially inflammatory or incriminating) stuff in a Drive area that's supposed to be private only to User B, with no interaction from User B whatsoever.  At best, User B receives an email to say this has happened - but they do not need to consent, and a single email is easy to miss.

Ignoring for a minute that the 'file' could contain anything you wanted it to, it could surely also be any _size_ you wanted it to...  which if nothing else would get a fellow user in trouble with their IT team for using ungodly amounts of space!

I realise this is slightly paranoid thinking, but there is potential for bad actors here.  If not investigated with care in an eDiscovery situation, first impressions of metadata could potentially lay blame on the wrong doorsteps..?

Please tell me I'm missing something here...  Happy to be roasted!

Thanks in advance,

[sumamo]

We also have noticed similar problem, I think it'd be great if transfer ownership can have some kind of "consent" from the new owner that he/she agrees to become the owner of the file.

[icrew]

FWIW, when you look at the information for a file in the Drive UI, you can see both who created it as well as who owns it. That info is also easily via the API (and GAM). So I don’t think it’s likely for someone to be easily accused of owning something nefarious. It’s also protected by the fact that you can’t transfer files to anyone outside your Workspace instance.

[sumamo]

Some made up examples:
Let's say A belongs to OU "able to share files outside of organization". B belongs to OU "not able to share external". So let's say B wants to share files to external parties, B can assign ownership of the files to A. A will see the email from Google saying "B has transfered ownership to you" but during the time A hasn't realized, B could have shared to files to external parties.

In some cases, A might have ignored B's notification email because A is overwhelmed with so many emails and filter out notifications from Google. (seems like plausible scenario in our company hahaha).

Maybe B is not nefarious but just inept in their security awareness or sharing policy.

Granted there maybe other ways to get around this problem by having document classification properly implemented or using some other content compliance policy, but having someone consent to owning a file may be an easy solution for this example. 

I mean in real life, if I own a thing and I want to give it to someone else. I need to tell the other person to "acknowledge" that I give it to them. Certain cases like people transfering money to wrong recipient can cause issue with the police if they are accused of receiving illegal money (at least in some cases that I know in my country, some scammer actually make this as part of the scam operation)

[icrew]

In that example, if B isn’t in the OU that can share files outside the org, they can’t do so regardless of who owns the file. 

[sumamo]

they can actually.

I just tried it.

1.) B belongs to OU that cannot share externally. I asked B to share to her personal email and she was unable to. (see attachment)
2.) B then gave A (who belongs to OU that can share externally) an ownership of the file. So now the file belongs to A.
3.) B then share the file to her personal email and she was able to share the file. There was a warning dialog box but she can still share anyway.

Now the files is shared to this external parties see below

[icrew]

Huh. That one definitely seems like a bug. I’d suggest raising it as such with support. (And don’t let them push you back to the Feature Ideas section here…if an OU is set to “don’t share outside the org”, the owner shouldn’t matter….)

[sumamo]

It's alright we've been using the supposed bug as a "feature" now for various things. And some GCP Service Account behaviors are also tied in to that supposed bug. So I think fixing that bug may causes issues to a lot of people using it as a feature.

Anyways, just going back to transfer of ownership, would be nice for it to have "consent" (to mimic real life where you give something, the beneficiary should be able to reject it if they don't like it)

Even if this thread will never see the light of day, I just hope Google Workspace Gods out there may consider it.

[icrew]

You might want to post this to the Feature Ideas section here. Doing so will allow it to be upvoted by others and possibly considered as a future feature enhancement.

If you do not already have access, you need to request it first. See https://www.googlecloudcommunity.com/gc/custom/page/page-id/Workspace-Feature-Ideas-FAQ for how to do that.

Once you have access, go to https://www.googlecloudcommunity.com/gc/Feature-Ideas/gh-p/workspace-ideas-group . There, you can upvote and comment on any similar idea, or post a new idea.

If you are submitting a feature idea, be sure to explain the problem that you're trying to solve with the feature idea, not just the idea itself. For example, saying "when my users are trying to do 'A', they often get confused by the fact that the buttons to do 'X' and to do 'Y' look quite similar to each other, which leads to this unintended consequence" is far more likely to get fixed than a feature idea that just says "change the color of the button 'Y'".

Cheers,

Ian

[sumamo]

Thanks, will post it there.