I think the core issue here is reasonable to solve, I'd probably want to resolve it consistently everywhere though (not just Maniphest). It also is likely important to solve at the comment box level as well, since people may not remember the object's policy before commenting.

Strictly as described, this would also leave 99% of tasks on 95% of installs red. I do think we could do a better job of surfacing cases where the policy deviates from the default policy, though, without being meaningless for the majority of users.

In the description @qgil notes !public or !allusers, which is what I expect the default to be in most places. Though maybe "not default" is a more correct means of isolating changes.

Ah, I missed that part. I do still think that "not default" is the right thing to cue -- for example, a more-open Almanac service in a field of admin-only-by-default services would be desirable to call out, rather than calling out the majority of services which have a tightly locked default.

Some other general thoughts:

• A more tailored approach (e.g., highlighting the policy callout itself, instead of the entire page/object) might be sufficient.
• Spaces might provide some clarity here: if you have to actually context switch into a private space to see private stuff, that could serve as a stronger cue about expectations.

Publishing links, specifically, also shouldn't really be a risk:

publishing links to private tasks in public pages

Obviously this stuff is:

.. title of the task and even some comments ...

...but maybe part of this can be mitigated with improved integration in external tools? At least in the upstream, it's very rare for users to copy any of this data to other places because mentioning Txxx is sufficient, and these mentions also get the policy checks correct. Hard on email lists, but maybe doable in some other contexts -- basically, if pasting links is generally sufficient, users will tend to just paste links, which are less problematic from a policy enforcement perspective.

As a first pass, we could either go with something simple like text:

Public (Default)
Security (Custom)

Or maybe color:

My only concern on color is finding something to convey 'non-standard'. Red probably works, but it'd be interesting to note how often I come across it. Here, at least, we'd likely fix non-public Projects, Tasks much faster.

Introducing pure red text in the header could be a useful first step, yes. We would need to think of a solution that doesn't conflict with other plans to put more emphasis in task resolutions i.e. T6500: Duplicated tasks should be marked more visibly as duplicates.

@epriestley, the fact that users mostly refer to tasks using {TNNNN} in Phabricator diminishes the risk of involuntary leakages indeed, but the problem to solve is that users are always aware when they are looking at a private page. Also, other communities might relate a lot more in other supports. Wikimedia users public developer mailing lists a lot. Some companies seem to love email threads with ever-growing CC lists. Anyway, I hope we can find a simple solution in the interim, while Spaces and their design principles take shape.

also, could have similar differentiation in search results, workboards,
task lists on projects, feeds (i.e. side of front page), pages for
individual users with tasks changed by that user

another thing people may not realize is private: data contained on a public
take about a mention by a restricted task. I've noticed that mentions show
up if I can view the restricted task too; they disappear (not just
redacted) if it's a task I can't view.

We don't have any plans for that in vanilla Phabricator. T4863 covers customizing workboards, T418 covers customizing everything else. In general though T3820 is how we think installs should deal with mixed levels of permissions in a single install.

I assume this task just covers visibility policy?

I think this is a change we should probably pursue, and start with a color treatment as in T6787#88172. There are several technical challenges:

• There is currently no general way to get the default policies for an object: each application hard-codes default construction in initializeNewX(...) methods. So we don't have a universal call we can make to get the default policy.
• T6860 will probably introduce "template application policies", which mean that the default policy may not be exactly the same as the policy that actually ends up on an object, just be a description of that policy which has the same meaning.
  • It is possible we'll just add an "author" field to Passphrase and implement that use case as an object policy, which feels a little squishy but is dramatically simpler.
  • In fact, T6860 (as currently designed) makes this impossible, since we can't figure out if the policy is really the same without knowing the original author, which we currently discard, so we definitely need to throw away some part of the design if we're going to do this.
• Non-default policies are not necessarily more private; they may also be more public. Showing "red" for a more-public policy might not be helpful.
• The policy hint shown in the UI may now be a space policy instead of the object policy.

So I suspect this looks like:

1. Standardize the idea of default policies for an object. This is close to existing already, but needs a bunch of legwork to convert all the applications to use it.
2. Throw away the design of T6860 and just store authorPHID on passphrase credential objects, then implement a "Credential Author" object policy for Passphrase.
3. Have the UI look up the default policy and colorize the hint if the actual policy is different. Probably two states: one for more-open-than-default policies (e.g., this object is public and might be too open), and one for all other policies (e.g., this object is private).
4. If the space policy is stronger than the effective policy, just show it in a normal color since there's really nothing nonstandard happening.

I think this is ~2-4 hours of work, mostly in doing the application-by-application updates in step (1) to let us figure out what the object's default policy is in order to perform the check.

Feeling pretty confident that T6860 was a really bad idea, so I threw it away; my current plan is to do T5135 instead, as described above.