Private sharing between a team and an outsider

[lig]

There is an option for sharing folders with two accounts like user1,user2. One of the uses for that is sharing data with an app or a service, like sharing user's website data with a hosting provider.

With the introduction of the teams feature there could be some use cases for app developers. Say, there could be a team's wiki service which data could be updated by any team (subteam) member. It could be really useful to be able to share a folder between a team and a service provider for such a case.

Update: team to team sharing would be also very useful for this case and for some other cases like cross-team data sharing, i.e. customer.managers,vendor.clients

[junderw]

I have done this, assuming myteam and hoster are the team and user.

1. create subteam myteam.hoster
2. invite all members of team that should be able to edit the files to the subteam as writers.
3. invite hoster to the subteam as reader.

/team/myteam.hoster/* is now able to be shared to hoster.

we use the git feature, and the hoster just needs to run git pull.

[lig]

@junderw I thought about that way but it looks kinda hacky to me. And I'd prefer to just share a file system without the need to include provider's user to any team.

[junderw]

I find it much easier, because it gives me the ability to remove users from our end / add users on their end... whereas private share folders are always bound to the combination of users separated by commas.

[lig]

@junderw that is my original point. Something like myteam.subteam,provider would be nice to have for sharing. Two-sided user management looks like overkill to me.

[junderw]

Two-sided user management looks like overkill to me.

Well, it exists. So overkill or not, you can use it now without waiting.

myteam.subteam,provider

I've had multiple occasions where the person in charge of our account left/got promoted or something and they gave us a new guy.

1. Go into team member page
2. Click remove old guy
3. Type in account of new guy and hit enter
4. Done. Data doesn't move, old guy no longer has access (though he could have copy pasted the folder for all we know, but that goes for anything like this)

With your proposed method it would be:

1. Copy over files from myteam.subteam,provider to myteam.subteam,provider2 (which could take a while and a lot of bandwidth depending on data size. You have to download all the data from the first folder (if it's not in your local cache), decrypt it, then encrypt it with the new folder, and upload it all again.
2. Old guy still has access unless you delete the data (easy to forget)

Also, fun fact. the private folders system was actually completely removed, and the current private folder system uses invisible "implicit teams" in the background with nerfed capabilities (no member management etc.)

[junderw]

Which means that your idea would probably be easy to implement.......... (since private folders are just teams on the backend now)

So it all comes down to if they feel the feature is worthwile enough...

In the meantime, the subteam method is very useful (I love it. Life is so much easier now with it)

[lig]

@junderw I never presumed that provider is a personal account in any way. It could and should be a service account being used by an actual service provider (usually accessed via oneshot paper key authentication internally) or even a team on the other side like myteam.subteam,provider.clients.

Sharing team's data with a provider employee's personal account is a bad idea in general in my opinion.

[lig]

@junderw Including a foreign account into a team looks clearly as a workaround for me as this is not consistent with the person,provider sharing for personal accounts.

[junderw]

so right now there are two things:

• teams (and subteams)
• users

It sounds like "service provider" is referring to a user in this context, since teams don't have paper keys and you mention oneshot.

Could you provide a detailed explanation of the use case you envision, along with whether each actor in the scheme should be a user, team, or some new entity. If a new type of entity, explain how that entity would work.

I am having a hard time following what you're asking for.

Including a foreign account into a team

members of subteams cannot see or know anything about the team tree above their subteam, and only admins can know of teams below them.

So if you invite bob to myteam.sub1 bob does not know the existence, membership, or anything about myteam.sub56 etc. or even myteam.sub1.subsub5

but if you make bob an admin of myteam.sub1 he will then be able to see myteam.sub1.subsub5 and will be an admin in that team too if he decides to add himself. Solution is to make him a reader or writer. If he doesn't need to write to the folder reader is fine.

[lig]

members of subteams cannot see or know anything about the team tree above their subteam, and only admins can know of teams below them.

I don't want to share with a provider account who belongs event to a subteam which is allowed to communicate to the provider.

[lig]

The ultimate workflow looks as follows:

1. ann is an admin of alpha team.
2. alpha team needs to share data with rho provider.
3. rho provider instructs alpha team to share data with them via rho.clients subteam.
4. ann creates alpha.rho_managers subteam.
5. ann adds her and bob to alpha.rho_managers team.
6. ann creates a share with the alpha.rho_managers,rho.clients name.
7. bob puts the data alpha team needs to share with rho team into alpha.rho_managers,rho.clients share.
8. rho team has user rho_clients_service added into rho.clients team.
9. rho_clients_service uses oneshot paper key auth to retrieve/host/massage data from the alpha.rho_managers,rho.clients share.

[junderw]

ok, this is the best explanation I could come up with, let me know if this is correct.

New features:

1. allow two private teams to share a folder.
2. do not allow the two teams to know the members of the opposing team.
3. The current workaround requires users from corp A to know which users from corp B are in the team (since team members can see each other) which is bad for this model somehow.

Is that close?

Keybase is not very good with hiding identity. Any suggestion about hiding identity in the slightest usually gets ignored or opposed... just a heads up.

[lig]

Keybase is not very good with hiding identity. Any suggestion about hiding identity in the slightest usually gets ignored or opposed... just a heads up.

A lot of demand in such a manner has already come up and will continue so for teams.

Is that close?

That's very close except this should include a team to an account sharing.

allow two private teams to share a folder.

open teams count as well

do not allow the two teams to know the members of the opposing team.

that's right but the starting idea was to unify provider to consumer sharing extending "consumer" in this context from an account to account or team.

[dlumma]

Mature electronic file collaboration products like Dropbox, Box, Google Drive, OneDrive/ Sharepoint, all have this type of capability.

Advanced Users and Groups configuration (including support for individuals outside of the Team/ Organization) and sharing will be a critical feature set of any team that is using this product for every day work.

Another set of features needed is refined access control, eg: read, write, comment, share.

Really sophisticated ECM products also include using file metadata and policy definitions to drive access control and sharing.

Happy to chat with your Product Management team on these topics if there is any interest.

Thanks!