As Phabricator allows a task to be part of more than one project, a user can create a ticket with 'Projects' set to 'Foobar' (as that's the codebase) and also 'Security' (as it's a vulnerability s/he reports).
We'd want to make sure that the access settings for 'Foobar' wouldn't "leak" the information in the ticket and that the access rules of the "more restrictive" project are applied to the task, I guess.

Trying to define the minimum feature set that would work for Wikimedia and your average open source project:

• Only admins can define private projects.
• Anybody can make a task private by assigning it to the corresponding private project.
• Only the members of the private project can make it public.
• The author and other users kept in CC can participate without joining the private project.

In more detail:

• Projects can be marked as "Private" by admins via applications/view/PhabricatorApplicationManiphest/
• When a task belongs to a private project
  • it is visible only to the members of that project, the author, and users CCed
  • can be commented by members, author and CCed
  • can be edited and modified (change status, reassign, CC, priority, change projects) only by project members
  • (regardless of public projects the task might belong to).
• The same principle applies when a task belongs to two or more private projects (unusual scenario).

Okay, having read through this I think this probably just maps directly to T3820.

The idea there is basically to introduce a new type of container (tentatively, a "Namespace") which is one-to-one instead of many-to-one. The only purpose of namespaces is to provide policy fences around groups of objects. By being role-specific and one-to-one we can avoid all the weird interactions between policies and projects that would arise by trying to have projects determine policies.

For example, with the outline above, it would be easy to add a task to two private projects with no intersecting members, such that no one had permission to edit the task or remove its membership in those projects. A mischievous user could do this intentionally, but normal users could do this accidentally. In the case where there are multiple private projects it would also be difficult to predict the set of users who could actually edit things.

Basically, if projects imply policies then the multiple projects case is very messy and complicated, and all solutions (allow it, limit to one "private" project, make the first "private" project controlling and others non-controlling) seem bad. Additionally, none of these approaches really provide a reasonable case for the "contractor/client" case discussed in T3820. The T3820 approach is to define a new concept to deal with all these cases, which is more focused on solving this class of problem and doesn't have any of the drawbacks that projects do when used like this.

In this case, things would work something like this:

• You set a policy so that only administrators can create namespaces (this would probably be the default).
• I suppose we have some kind of "drop box" flag on namespaces which says "this group of users can put stuff into this namespace even though they can not see stuff in the namespace" (not exactly sure?). I would assume this would be rare -- used for "Security", but not something like "Mergers and Acquisitions" (which would be totally opaque to the outside).
• You'd need edit permission on a namespace to remove it (maybe needs more nuances?).
• Existing policy exceptions would punch holes through namespaces (maybe only selectively?)
• You could override policy defaults within a namespace.

So it would look something like this:

• You create a "Goat Farm" namespace.
• You create a "Goat Farm Administrators" project? Or maybe you can just add members directly to a namespace?
• You set the "Edit Policy" of "Goat Farm" to "Goat Farm Administrators" (or to "Members of namespace Goat Farm"). This controls who can remove objects from the namespace.
• You set the "View Policy" of "Goat Farm" to "Goat Farm Administrators". This controls who can see objects in the namespace. Existing policy exceptions punch a hole through this rule.
• You set the "Add To Namespace Policy" of "Goat Farm" to "All Users". This controls who can put things into the namespace.
• You override the default task policies and set them to "Goat Farm Administrators", or maybe we give you a shortcut like "editors of object namespace". This lets you control who can adjust settings from within a namespace.

Obviously, big parts of this are still pretty fuzzy, but I think some form of this is the best solution to this class of problem. In particular, many other use cases (like installs that are approximately consulting firms and have clients who they want to give access to a subset of tasks) can't easily be solved by "private" projects, since those use cases need default-deny containers. Empowering private projects to handle that case would make the rules even more complex and confusing.

Namespaces seem like they present a reasonable solution to nearly all policy problems which aren't well resolved through the existing policy controls.

Yes, namespaces look like a good implementation for this need. I'm fine following up at T3820, or we could consider this task a dependent focusing in Maniphest only.

A couple of observations after reading your replies here and there:

• Tasks should keep their URL when moving across namespaces (unless you want to play with automatic redirects). The only difference for users landing to that URL would be to see the content or not based on their permissions. Usually the workflow of a security issue is: filed publicly, moved to private, disclosed back to public when it is solved.
• The reporter and the users CCed should keep their access to the tasks regardless of their specific permissions in a namespace (I guess this would be one of the policy exceptions punching holes?)