Original Poster

Serious confidentiality issue


It seems to have very important confidentiality issues in Google Docs :

Access rights and sharing definitions of sub-items are not any more inherited when sharing settings of a collection are changed ! 

This has lead to very serious confidentiality and security issues in our organization. Sensitive informations have been displayed to not authorized persons. We’ve spend several hours to change settings file by file and to check all our files and collections. And we had to warn all of our partners and our clients. This is not without any impact on our image of professionalism as you can imagine.

As far as I searched on the help forum, I found almost nothing about this. Thanks if you could lead me to more informations about this and what is done to fix it.


- - - - - - - - - - - - - - - - - - - - - - - - -

Type of account : Google Apps for Business
Stuff : 50% pc, 50% mac, windows 7, mac os 10.6, chrome, IE, safari.
Offline mode : not activated

First notice of the issue :
Two collections has been switched from “All the organization” to “Private”. Sensitive files have been moved to those collections. The next day an employee reports that all sub-items within the private collections were still accessible to all.

Testing :
We have proceeded to various tests including 1 hour break* and re-logging between steps. Tests have shown that there are no rules to this issue. Some times it works for all sub-items, some times not, some times only for some sub-items. But mostly it does not work properly at all.

Community content may not be verified or up-to-date. Learn more.
All Replies (10)
Google user
Google user
I would like this addressed as well, and in terms of functionality. If Google wants to make collaboration possible while still allowing users to preserve confidentiality, then Google needs to simplify the sharing function to prevent mistakes occurring because people are either getting confused at the outset, or confused by training. I think the reality on the ground here is that minds don't intuit the process you have developed. Also, it sure would be nice to have a link in the left nav pane that shows all and only shared documents and collections, or at least give us a specific search operator for that. Or am I missing something? Perhaps what is best is separate accounts for secured versus accessible docs.
Bas Braams
Bas Braams
There are two ways that I know to bring about a situation similar to the one described by Hanael. They are both predictable and reproducible and they reflect errors (my choice of words) in design or implementation of the sharing operations. An earlier related discussion is in [1].

Variant 1. Alice creates collection L0 and shares it with user Bob. Alice also creates documents doc0 and doc1 in her Home and moves them into L0; they thereby become shared with Bob. Bob assigns doc1 to his private collection M0, leaving it in L0 as well. (This action by Bob is invisible to Alice.) Now Alice removes Bob from the share on L0. It turns out that Bob is thereby removed from the share on doc0 as well, but he remains shared on doc1.

Variant 2. As before, Alice creates collection L0 and shares it with user Bob, and she creates documents doc0 and doc1 in her Home and moves them into L0 so they become shared with Bob. Now Alice removes the share permission to Bob on doc1 and then she restores the share permission to Bob on doc1. We imagine now that a long enough time elapses for Alice to forget about that action of first un-sharing and then re-sharing Bob on doc1. Once again, now Alice removes Bob from the share on L0. It turns out that Bob is thereby removed from the share on doc0 as well, but he remains shared on doc1.

In order to see why this is objectionable we need to expand the narrative a bit. Let us assume that L0 is at first shared with multiple people inlcuding Bob. At some point Bob is removed from the share and the items in the collection are going to be subject to further editing that should not be seen by Bob. The items, doc0 and doc1, will appear in Alice’s (and other viewers or editors) as shared items. If Alice and others trust that the share involves only the group that is shared on L0 then they are mistaken in the case of doc1.

Variant 1 reflects bad and erroneous design, in my opinion. Alice is the owner of doc0 and doc1. The sharing properties of these items should depend on actions of Alice and possibly on actions by others that have edit permission on doc0 and doc1. In variant1 Bob is just a passive recipient of those docs; they may have been shared with him view-only. It is not correct that Bob’s action of assigning doc1 to one of his own collections influences the effect on doc1 of Alice’s later action of un-sharing Bob from L0.

Variant 2 also reflects bad and erroneous design, in my opinion. Clearly some hidden variable is involved; it appears that each item carries a tag of some sort that determines if the sharing status of this item should follow (in some way) the sharing status of collections in which it is contained or if the sharing status of this item is a property of the item alone. The hidden variable is undocumented and its behavior is undocumented, which already reflects bad design, and the situation is sufficiently unreasonable that it must be considered erroneous.

More explorations under [1]. There are lots of problems with the GDocs file system and with sharing in particular. This is just one error out of many as may be seen in [2-6] and further references there.

Original Poster

I've got an answer of Google support team. I post it here in order to help other people on this case :

"I understand that you are having some issues with your collections and the sharing permissions of these collections not propagating for all of the docs that are in the collection.

This is actually an expected behavior of the collections feature. When you change the sharing settings within the collection, it will not change the settings of the docs within the collection, it will only change the sharing settings of the collection itself.

The docs will retain their original sharing settings. For example, lets say I have Document 1 set at 'anyone in the organization.' If I add document 1 to a collection, and mark that collection as private, document 1 itself will not be a private document, it will still be a 'Anyone in the organization,' document. The only differences, is that people will not have the permission to see my collection and whats in that collection. However, if they were to search for document 1 in their own docs account, that document will still show up.

The sharing permissions for the collection, is for the collection itself. It will not reflect the documents that are in that collection. If you want a document to be private, so that nobody in the organization can view it (except those you have shared it with), you will have to mark that document as private. However, the tricky thing here is, lets say document 1 is already marked as private and you did not add anybody to the sharing permissions list of this particular document. You then add it to a private collection, and share this collection with another user. If this collection is shared with the user, then they will be able to view this private document that is in the collection you shared."

Is the non-inheritance a quite new behavior ? I'm pretty sure that until weeks ago sharing permissions changes were pushed to sub-items. And the help resource still says so (but I read it now as ambiguous). Moreover, in the test we did (see my first post), on very few times, permissions changes are inherited by subitems.

Anyway, the correct behaviors are as describe above by the support team.

Bas Braams
Bas Braams
The answer from the GDocs support team that was quoted by Hanael shows a disconnect; the respondent doesn't seem to be aware of the actual behavior of the sharing properties in the GDocs file structure. As to the expected or intended behavior I think now that nobody, not even the coders themselves, know what is the intended or expected behavior; it is all undocumented. It might be derived after the fact from the actual behavior, and it appears to me that that is the way in which the GDocs team operates.

Specifically: <<When you change the sharing settings within [sic] the collection, it will not change the settings of the docs within the collection>>. The word "within" is a typo, the context tells me; it should have been "sharing settings of the collection", not "sharing settings within the collection". My earlier example here above of collection L0 containing documents doc0 and doc1 shows that the (edited) assertion is not correct in general. In that examples, both variant 1 and variant 2, when the sharing settings of L0 are changed then the sharing settings of doc0 are automatically changed as well.
Original Poster
Hello !

We have proceed to a lot of tests but finally we think we found the bug ! I'll tried to be as short as possible but to give every one a good understanding of the situation, I will start from the beginning :

The issue
Items and sub-items in a collection did not inherit anymore sharing settings of the collection when those change. This lead to confidentiality issues.

The tests
We did many many tests over several days. I won't explain all but just present important facts :
- Items and sub-items (like docs, spreadsheet ...) don't auto-populate when the collection sharing settings change. However sub-collections (at all level) do.
- Based on trick given by Google support team, we figured out that the only way to make things working in a collection was to set up all items and sub-items on "Private". And only then it auto-populates and follows the collection settings.
- We have noticed that (for a couple of time ?) all new collections are created as "Private" although our organization default visibility settings are (and have always been) "Any one in the organization". This is the key.

The bug
In "Manage this domain", we change the organization default visibility setting from "Any one in the organization" to "Private". Then we lead new tests and every thing worked perfectly and without any trick.

We don't know why, we don't know how, but we do know that in this case all works fine because all elements (both collections and other files) have the same settings at creation. In other words, all elements respect the organization default visibility settings at creation. We came to think that items and sub-items have to share at some point the original settings of the mother collection. Otherwise...

We guess that this issue exists only in the organization were the default visibility settings are "Any one in the organization". In those case, collections are still created as "Private" (thus not respecting the default settings) while other elements are created according to the default settings. In other words, in those case items and sub-items don't share at some point the visibility settings of the mother collection at creation.

- That's why sub-collections did auto-populate but not others files and sub-items.
- That's why we have first to change all items and sub-items to "Private" to make things work fine.
- That's why we discover this issue pretty late : sub-collections did auto-populate so it seems to look fine. However what was inside was still accessible to none authorized persons.

We demand the support team to transmit our hypothesis and we hope that technicians will lead tests on that as soon as possible.
If some of you guys could check out our theory, it could be great.


Hi Hanael,

If you change the sharing settings of a collection, the items within that collection should inherit those changes. There are exceptions to this, we've tried to list the intricacies of this here:

Sorry that you were told this was expected behavior, I'll look into where you received your response from, as we want to make sure that people receive the highest quality answers.

I was able to reproduce the behavior you were describing, so you have indeed discovered a bug. We'll look into it right away. One thing I noticed is that if I have the default setting for the domain as "Anyone with the link" and then change documents to private before adding them to a collection, they do inherit the changes in permission as expected. Sounds like you also already have a workaround for, which I'm glad to hear. We want this working better though, of course.

Thanks for posting,

Wow you found the answer and posted it on here for everybody else to see? Wow you are very nice as I can already tell by your name......:) But I had the same problem to and I than you for finding the answer and posting it thank you hansel. Thank you very much to everybody else who replied and said some answers for hansel to. :D

Original Poster
Hello guys,

We've notice that Google changed couple of things and collections are now created as "This organization" if the domain default sharing settings are so.

HOWEVER, it seems not to be working : sharing inheritance is a mess. We've some tests on two domains but if one of you has some time to waste, could he checks our results.

Here is a spreadsheet describing each test and the results : https://docs.google.com/spreadsheet/ccc?key=0Ap8AaDO56GjidHVvOXJfbFZmNFBHTVlaR1F2RXlrTVE (and sorry for the poor english)


Bas Braams
Bas Braams
@Hanael, would you mind to clarify some steps? I've read the spreadsheet, but I don't understand it. (I don't have access to an Apps account myself, but I think I'm familiar with the concepts anyway.)

In the first set of tests the default sharing settings are set to "This organization". That much I understand.

<<For each test, a collection is created and filled with an item, a sub-collection and an item in the sub-collection (sub-item). For all the tests with this domain default settings, there is no difference if item, sub-collection and sub-item are created via the "Create" button and moved into the collection or if they are created with right clic on the collection.>>

May I give them names? Collection L0 filled with the item doc0 and the sub-collection L1, and sub-item doc1 in L1; that is the initial state.

Test 1. Can you clarify what is done? I'm guessing that the sharing setting of L0 is changed to Private and you observe that doc0, L1 and doc1 remain shared to this organization. Is that a correct guess or is something else going on?

Test 2. Likewise my guess is that now (from the previous initial state) the sharing setting of L0 is changed to Public and it is observed that doc0, L1 and doc1 thereby become shared Public.

Test 3. I'm guessing: starting from the initial state, first L0 is set to Public and then it is set to Private.

Please clarify the steps.
Original Poster
Hello Bas,

Sorry for being unclear but all your guesses are correct (you do have to read further...)

Yes, we did two sets of tests :
- first with "This organization" as the default domain domain sharing settings.
- second with "Private".

<<Settings of the elements at creation>>
Here we check, as preleminaries, if elements (collections, docs etc...) are created with the correct default settings. We compare the actual settings at creation with the expected one (based on Google help docs or logical expected results). 

<<Test X>>
For each test we create a collection, a sub-collection, an item, and a sub-item using the "create" button (we notified when using the right clic make a difference). The structure is this :

At the initial state, you have Collection L0, item L1, sub-collection L1 and sub-item L2 in your "Home" window.
The final state after organizing elements is always this :

Collection L0
>> item L1
>> sub-collection L1
>>>>> sub-item L2

On some tests, we organize elements first and only then we change the sharing settings and check if elements auto-populate. On some tests, we change the setting firsts first and then organize the elements.

So to be clear if it is not for some folks, let me describe some tests with full words :

<<"This organization" default domain settings>>
<<Test 1>>
All elements are created. They all have "This organization" as default sharing setting.
Item L1, sub-collection L1 and sub-item L2 are moved into Collection L0.
Then the settings of Collection L0 are changed from "This organization" to "Private".

Results: The elements in L0 are still "This organization". They do not auto populate. Failure.

<<Test 4>>
Same as Test 1 except that the L0 settings are changed before moving item L1, sub-collection L1 and sub-item L2 into it. The results are the same as Test 1. Failure.

<<Test 9>>
All elements are created. They all have "This organization" as default sharing setting.
Collection L0's sharing settings are changed for what ever you want or not changed if you wish so.
Item L1, sub-collection L1, sub-item L2 are changed to "Private". (called as the tricky step)
Then they are organized into Collection L0.
After that Collection L0's sharing settings are changed for what ever you want.

Results: elements auto-populate ! OK.

NOTE : If we want that elements sharing settings auto-populate, we have to fix then at some point on "Private". But because elements do not auto-populate, you have to set on "Private" every elements, sub-elements, sub-sub-elements etc... Waste of time and lack of security. However, if the domain default settings are set on "Private", everything works perfect. 

In fact, we recommand to fix organizations on "Private". It seems to be the safest and fastest way to work. A new elements becomes visible to others only when the owner decides so or when he moves it into the organization's folders tree. The element will acquiere the sharing settings of the collection it is moved in.
 All companies have Once you've got the basic folder organization tree shared with your people, once you move newly created elements in 
Were these replies helpful?
How can we improve them?
This question is locked and replying has been disabled. Still have questions? Ask the Help Community.


Some community members might have badges that indicate their identity or level of participation in a community.

Expert - Google Employee — Googler guides and community managers
Expert - Community Specialist — Google partners who share their expertise
Expert - Gold — Trusted members who are knowledgeable and active contributors
Expert - Platinum — Seasoned members who contribute beyond providing help through mentoring, creating content, and more
Expert - Alumni — Past members who are no longer active, but were previously recognized for their helpfulness
Expert - Silver — New members who are developing their product knowledge
Community content may not be verified or up-to-date. Learn more.


Member levels indicate a user's level of participation in a forum. The greater the participation, the higher the level. Everyone starts at level 1 and can rise to level 10. These activities can increase your level in a forum:

  • Post an answer.
  • Having your answer selected as the best answer.
  • Having your post rated as helpful.
  • Vote up a post.
  • Correctly mark a topic or post as abuse.

Having a post marked and removed as abuse will slow a user's advance in levels.

View profile in forum?

To view this member's profile, you need to leave the current Help page.

Report abuse in forum?

This comment originated in the Google Product Forum. To report abuse, you need to leave the current Help page.

Reply in forum?

This comment originated in the Google Product Forum. To reply, you need to leave the current Help page.