We need to think about this topic with some granularity in mind. There are some private details that collective admins should be allowed to see, and some they shouldn't. In our current permission system, we have the following:

• canSeeExpenseInvoiceInfo: true for host admins, collective admins, accountants
• canSeeExpenseAttachments: true for host admins, collective admins, accountants
• canSeeExpensePayoutMethod: true for host admins, collective admins, accountants
• canSeeExpensePayeeLocation: true for host admins, collective admins, accountants
• canViewRequiredLegalDocuments: true for host admins, accountants
• canComment (and therefore see comments): true for host admins, collective admins

If the "legal documents" part is what's blocking OpenMined, we could allow that permission for collective admins too.

In the initial implementation of the latest expense flow, I initially tried to prevent collective admins from accessing the payout method details (see #2848). In a perfect world, I would love to enforce that behavior. If we define that hosts are responsible for the payment, then it's up to them to follow up if there's an issue with the payout method; it's not the responsibility of collective admins.

I think what's most blocking OpenMined is 1) not being able to see expense comments, and 2) not being able to see that an expense is waiting on the tax form.

The fact that a tax form is pending does not in itself reveal private info about the expense payee, so I think that's one thing we could let Collective admins see (just show them the yellow banner that the submitter and host admins see in that case).

@Betree from what you said above it seems Collective admins should be able to see expense comments already? Is that true? Because what Peter said implied he could not.

@Betree from what you said above it seems Collective admins should be able to see expense comments already? Is that true? Because what Peter said implied he could not.

Absolutely, collective admins (but not "core contributors") can comment and see other's comments on expenses already.

Hi,

I am one of the admins for @termux and we have our collective at https://opencollective.com/termux

Apologies in advance for the long comment. ;)

Based on history, #3935 via f7266286 enabled collective admins to see payout method, invoice and payee location, from the previous behaviour of not allowing it as per cc748aa6 and 84bec4e4.

I understand that in some collectives, the collective admins would require such info to be visible to them (OpenMined), and in some they don't want them to (Google Season of Docs). I am in the later group, under "normal circumstances", I have no need to know the birth identity name, BOD, email, address, country and bank details of any of my team members or admins who file an expense. I only need to approve expenses based on their verified pseudo identity they are using on github. A lot of our members (including me), work partially or fully anonymously, as would be the case in other collectives. Anonymous members and members belonging to at-risk groups would not want their identities revealed to all other collective admins to get payouts, and so may not file expenses they may deserve or need due to the resultant privacy loss may have too great a cost. I would rather my team members can get the money for their work and having to reveal their private info to me and other admins shouldn't be the reason for them to not get it.

I am fully in support of transparency, as long it doesn't compromise privacy or security of people, or needlessly exposes info to people who don't need it as principle of least privilege. With the current way, there are risks involved. In some collectives, relations might not always be good between all admins and contributors, and any admin may decide to dox someone else due to some internal fight/drama, and once such info is public on the internet, in most cases, can't take it back.

There are also issues related to how collectives evolve over time. At the time an expense is submitted, all the admins may be trusted by the member who submitted the expense, but in future, new admins/accountants could be added, who may not be trustable or have same ethical values, and they would get access to all private details of entire collective history. The member may not even know about new additions in case they become inactive or leave the collective, or have control of who can view their info in future since they may not have a vote on who can be added as an admin for the collective. Similar scenario in case project is sold off or transferred to some other company, etc and collective access is given to the company as well. Any member who is submitting an expense would have to worry about perpetual future risks as well. Filling an expense as an outside collaborator would have similar issues.

I propose that such control should be granular so that all cases are covered for each collective, however they may want to run it. The right design would need to be discussed. In my opinion, whoever is submitting an expense should have an option to open a privacy panel for that specific expense (not global). The privacy panel should have toggles to allow access for each item separately, something like shown below, the defaults are selected.

• The privacy panel must not be editable by admins and only by the one who created the expense, so that admins can't just change privacy settings and view the data they couldn't see before.
• The admin should still be able to edit other parts of the expense that are visible to them.
• If some admin is submitting an expense on behalf of someone else, they should already have required info and can optionally hide it from other admins.
• If some collectives require admins to have an item visible to them, like payout method, payee location, legal docs, they can just ask the expense submitter to change visibility as needed or reject the expense.
• Payout Method, Invoice Info, Payee Location and Legal Documents could possibly be combined into a single toggle to reduce complexity.
• The invoice generated should dependent on visibility of the role viewing it, in case collective admins don't have access.
• In addition to the expense itself, individual comments should have a privacy control too, in case some private info needs to be discussed between fiscal host admin and expense submitter that should not be visible to collective admins/accountants.
• An attachment that should only be visible to fiscal host admin and/or collective admins/accountants can either be sent in expense itself or a comment.
• Maybe a filter field can be added that allows expense submitter to specify one or more user ids of the collective admin or accountants they wish to expose info to instead of all of them, considering admins and accountants can be added in future as well or all may not need the info.
• Selecting Public should auto select other toggles. Possibly in real UI, the roles that always have access for an item should also have selected toggles shown that are just disabled to reduce confusion.
• The Expense Description and Expense Submitter could be used to solve incognito payouts issue (Incognito payouts #3422). Even if someone uses a real or pseduo identity account, they can hide all expense info from public and the collective team and can hide private payment and location info from collective admins.
• Will need to discuss backward compatibility for any changes. If privacy panel is added now, what about past expenses, should they still be editable? If yes, then admins who may have expected the data to be visible in future may lose access, but in my opinion they can ask the data to be made available to them since the expense submitters may not want data accessible to all current and future admins and having an option to go disable it for past expenses may be good for them. For new expenses, maybe not allow changes to privacy after expense has been paid out.

A simple implementation could have each item having an integer in Expense/Comment object and using bit wise operations to allow/disallow access for a role, but then there would be a limit on how many roles can be controlled due to limited bits 32/64, although that many roles may not exist in future either. More complex access control could be implemented too, there should probably be a library/plugin for it in node too. Maybe I can help implementing this once I am done with my projects release cycle in coming weeks, although I have very minimal experience in node, and only have it in ruby on rails from couple of years ago, and then there is of course the UI ;)

Let me know what you guys think. Thanks!

Related #4214

Expense Privacy Control

Expense Description (For Incognito Payout)

• Public
• Collective Core Contributor

Expense Submitter (For Incognito Payout)

• Public
• Collective Core Contributor

Payout Method

• Collective Admin
• Collective Accountant

Invoice Info

• Collective Admin
• Collective Accountant

Payee Location

• Collective Admin
• Collective Accountant

Legal Documents

• Collective Admin
• Collective Accountant

Attachments

• Public
• Collective Admin
• Collective Accountant
• Collective Core Contributor

• All Expense items are always visible to Fiscal Host Admin.
• Expense Description and Expense Submitter are always visible to Collective Admin and Collective Accountant.
• Enabling Public will allow everyone to view the item, who may not even be part of Collective Team or Fiscal Host.
• Payout Method, Invoice Info, Payee Location and Legal Documents can never be visible to someone who is not a Collective Admin, Collective Accountant or Fiscal Host Admin due to privacy reasons.

Comment Privacy Control

• Public
• Collective Admin
• Collective Accountant
• Collective Core Contributor

• All Comments are always visible to Fiscal Host Admin.
• Enabling Public will allow everyone to view the comments, who may not even be part of Collective Team or Fiscal Host.
• The privacy settings apply to comment attachments as well.

Reopening to address the new comment

@agnostic-apollo Thanks for sharing your concerns. As shared in #4729 (comment), I also think that payout method info should not be visible to collective admins. The fact that we're compromising the privacy of many groups because one of them has a special way of operating doesn't sound right.

I like the idea of a privacy control panel; it's a way to provide 100% clarity on what you're about to share, and with whom. My concern is that expense submitters often don't know the difference between collective/host admins, and they usually don't know who needs what to operate. If we let expense submitters in charge of this decision, we'll increase the load on admins. Plus, our expense form is already quite complex, I'm worried about how we could design this without making the form more complex.

I would therefore suggest:

1. That we implement sensible default permissions that are opinionated about what a healthy process is. E.g. If we define that hosts are responsible for the payment, then it's up to them to follow up if there's an issue with the payout method; it's not the responsibility of collective admins.
2. That we provide some settings (visible or not) to create exceptions to these rules for cases like OpenMined without impacting other projects. Would be great to have a call with them first, to see if they still need it and whether it's a legit request or just bad practices in the way they operate.
3. That we find a way to provide 100% clarity on the privacy of the info you're sharing. E.g. A tooltip on each field that says something like "This info will be shared with the fiscal host (OSC) admins" and/or a summary screen before submitting the expense to provide a condensed view (similar to your control panel suggestion, but not editable)

Thanks @alanna for reopening the issue and @Betree for responding.

The fact that we're compromising the privacy of many groups because one of them has a special way of operating doesn't sound right.

I agree as well. If private details need to be disclosed for some collective, it should be collective/expense specific and not global. I do think there are likely other collectives who may want or need access as well though, specially companies who may have to file their own tax or legal documents, so a way to provide exceptions for them should exist. The accountant role also exists for similar reasons. Moreover, collectives or companies, possibly with big budgets may require some kind of internal/offline management as well instead of completely relying on open collective for book keeping, specially in case "something happens to it", hopefully not though.

Contributors for such companies may likely be company employees and company would likely have some legal obligation to protect their private data too and would likely handle it with care and on who gets access, considering they could likely get sued if data is mishandled/leaked/doxed, but such protections may not exist for lot of community open source projects, and good luck suing someone from a country without a good legal system or whom you don't know the identity of either.

I like the idea of a privacy control panel; it's a way to provide 100% clarity on what you're about to share, and with whom.

Yes, that should be the goal. My panel looks big though, I know. Some items can be combined like I said, to simplify it, so lesser toggles. Issue is that there are a few cases to handle (collective admin requiring access, not requiring access, incognito payouts, optional public data or visibility for core contributors), so some items/toggles are going to be required. Also on thinking more on it, having separate Collective Admin and Collective Accountant may not make sense, since a collective admin could just add an accountant account to get access to the data that's only visible to accountant, so that should decrease even more toggles. I have added a simpler panel at the bottom of the comment.

My concern is that expense submitters often don't know the difference between collective/host admins, and they usually don't know who needs what to operate.

Well, submitters are giving their private data, they should be more careful on who they are giving it to and it should be clear/easily accessible on the site who is getting what. Maybe a simplified explanation can be given about each role to make things clear and telling them that collective admins normally would not require access. Maybe a link to roles docs and fiscal host docs. Not everyone may care about such info considering the data people put on the internet, but many would, so an option/info should be available for them.

Currently, the faq on the side while filing expense says.

Is my private data made public?
No. Only the expense amount and description are public. Attachments, payment info, emails and addresses are only visible to you and the admins.

It does not mention that collective and host admins are separate and they both get access, so not really user's fault if they don't know. Moreover, current This info is private tooltips don't mention private from whom either.

If we let expense submitters in charge of this decision, we'll increase the load on admins.

I am sorry, didn't fully get you. Do you mean will require admins to ask expense submitters to change default privacy settings in comments? If yes, then, many collectives may not require changing defaults, and they could provide visibility requirements for submitters filing expenses in their own docs or something. A better way may be for collectives to set their own expense privacy defaults in collective settings so that they don't need to be set every time and it reduces expenses filed with wrong privacy values, which would then require correspondence to fix.

Plus, our expense form is already quite complex, I'm worried about how we could design this without making the form more complex.

Didn't look too complex to me, have you received complaints/suggestions about it? Filling in the address, bank info, expense info and invoice details would be required in any case. Possibly removing two columns for Payee information and instead of having to fill address twice, there should be Payee Address and below that Billing Address that has the toggle Same as payee address. That convention is mostly used and should simplify/quickify filing a bit. I think that was discussed somewhere else too.

That we implement sensible default permissions that are opinionated about what a healthy process is.

I agree with having good defaults and collective admins not having access. Users should be warned too about consequences if some collective requires access.

If we define that hosts are responsible for the payment, then it's up to them to follow up if there's an issue with the payout method; it's not the responsibility of collective admins.

Would be great to have a call with them first, to see if they still need it and whether it's a legit request or just bad practices in the way they operate.

As mentioned above, there may be legitimate use cases and possibly other collectives as well.

That we provide some settings (visible or not) to create exceptions to these rules for cases like OpenMined without impacting other projects.

What did you have in mind on how these settings should look like? Suggestions from others would be great too.

That we find a way to provide 100% clarity on the privacy of the info you're sharing. E.g. A tooltip on each field that says something like "This info will be shared with the fiscal host (OSC) admins" and/or a summary screen before submitting the expense to provide a condensed view (similar to your control panel suggestion, but not editable)

The last page of expense filing would be ideal place for something like this, it shows all the items too, so user should be able to compare.

If not editable, where would above mentioned settings exist?

A smaller privacy control with fewer toggles can look like this.

Expense Privacy Control

Expense Description (For Incognito Payout)

• Public
• Collective Core Contributor

Expense Submitter (For Incognito Payout)

• Public
• Collective Core Contributor

Payee Info

• Collective Admin/Accountant

Legal Documents

• Collective Admin/Accountant

Attachments

• Public
• Collective Admin/Accountant
• Collective Core Contributor

• All Expense items are always visible to Fiscal Host Admin.
• Expense Description and Expense Submitter are always visible to Collective Admin and Collective Accountant.
• Enabling Public will allow everyone to view the item, who may not even be part of Collective Team or Fiscal Host.
• Payee Info and Legal Documents can never be visible to someone who is not a Collective Admin, Collective Accountant or Fiscal Host Admin due to privacy reasons.

Comment Privacy Control

• Public
• Collective Admin/Accountant
• Collective Core Contributor

• All Comments are always visible to Fiscal Host Admin.
• Enabling Public will allow everyone to view the comments, who may not even be part of Collective Team or Fiscal Host.
• The privacy settings apply to comment attachments as well.

I would like us to resolve the most important concerns of this issue. Based on #4729 (comment), I think we should start with the following steps:

I'm proposing to:

• Remove collective admin permissions for canSeeExpenseAttachments
• Remove collective admin permissions for canSeeExpensePayoutMethod
• Remove collective admin permissions for canSeeExpenseInvoiceInfo
• Remove collective admin permissions for canSeeExpensePayeeLocation
• Remove collective admin permissions for canViewRequiredLegalDocuments
• Introduce a new canViewRequiredLegalDocumentsStatus check, set to true for collective admin. This check will be used to know whether the expense is pending for a legal document, without allowing the collective admins to see the actual document.

Collective admins already see expense comments because they use the canComment permission, so there is nothing to change on that part.

Do you mean to add toggles for those or completely remove? There would be cases where attachments and invoice info would be required to be checked by collective admins to actually approve the expense. There should ideally be a per attachment item control, like say an invoice pdf attachment may not be private but some other attachment required by only fiscal host may need to be private from collective admins, although fiscal host specific attachments could be sent in a private comment too, so may not require a per item control for attachments in expense. And some collectives may require other infos as well for their own legal requirements and records, like mentioned before.

Do you mean to add toggles for those or completely remove? There would be cases where attachments and invoice info would be required to be checked by collective admins to actually approve the expense.

Completely remove, at least for the places where there's no ambiguity:

• Payout method
• Legal documents (aka. W9 tax forms)

There's no reason for collective admins to access them.

There should ideally be a per attachment item control, like say an invoice pdf attachment may not be private but some other attachment required by only fiscal host may need to be private from collective admins, although fiscal host specific attachments could be sent in a private comment too, so may not require a per item control for attachments in expense.

Yes, but this requires involving @opencollective/design on a multiple-weeks project with user testing that needs to be prioritized. I'm not against it, but in the meantime I'm not comfortable letting this privacy issue out there. We need to enforce good defaults and treat exceptions as such.

Completely remove, at least for the places where there's no ambiguity:

Seems reasonable to start with.

on a multiple-weeks project

Yeah, these changes would be time consuming. But I guess future additions should still be kept in mind during the initial code refactor to reduce future work. Although, if not adding the privacy panel now requiring design changes, could just remove access in backend.

And thanks for looking into this!

A few days ago, we pushed an update to expense permissions to reduce the scope of what collective admins can do/see. Namely, we don't want them to edit expenses and see payout details.

Some fiscal hosts quickly backfired as they were relying on this behavior in their process. That's my mistake: given how critical the expense flow is, I should have investigated and collected feedback in advance rather than taking the "break and see who complains" approach. That's good learning.

In opencollective/opencollective-api#8724, I'm adding a simple host.settings.allowCollectiveAdminsToEditPrivateExpenseData flag to restore the legacy behavior for negatively impacted hosts. I'll then follow up with them to better understand their processes and see how we can improve things in a more generic way.

Yeah, noticed it myself a couple of days ago while I (collective admin) tried to edit out expense description of one of our devs, but it didn't throw a permission denied error, and just redirected page to some random problem occurred page. So it would be better that any final changes are reflected in the UI with some proper error messages so collectives know what has actually happened.

Collective admins absolutely need to be able to edit expenses. We often ask them to fix problems. However that doesn't have to extend to payout details.

Then I'll rollback all the changes made so far; it seems we need more research & feedback than what has been shared in this issue.