By looking at the dependency tree in https://phabricator.wikimedia.org/T108557 I am unable to determine whether the 2 non-public tasks are still open or not. It makes a difference, being able to say "this is stuck on 4 things, including sensitive stuff" and "this is only stuck on what you clearly see open". (FWIW I am told they are resolved, but I shouldn't bother staff only to get this kind of information.)
I don't want to be able to see what's in those tasks: I just want to understand whether they are open, or resolved (by any value of "resolved"; I dunno that they could also show up as stalled).
The task you're quoting seems to be about what the wording of these very tasks should say, rather than whether they would offer any kind of information when showing up in the tree.
To me it doesn't make a difference if it says restricted or unknown, but I want a strikethrough if they are closed. :) HTH!
IMO it should say "Restricted Task" instead of "Unknown Object (Task)".
I just want to understand whether they are open, or resolved
That is legit but I can also imagine many situations when that's leaking info (e.g. dependencies which are security issues) so I don't expect upstream to implement that.
If it matters that security stuff isn't distinguishable from, say, legal stuff, I don't have a problem with that and you can use any wording you want. However, I don't understand what info would be leaked by displaying Unknown Object (Task) with a strikethrough after people are done with it, or similar?
We consider object open/closed status to be private information, so the upstream is very unlikely to make changes which expose it to users who can't see the objects.
I don't understand what info would be leaked by displaying Unknown Object (Task) with a strikethrough after people are done with it, or similar?
Here's a possible example: if we allowed users who can not see tasks to learn their status, a malicious user could repeatedly poll the status of a known or suspected security-sensitive task (by reloading the page, or by having a bot make Conduit calls, or whatever else). After they see the task has changed from "Open" to "Closed", they can review recent commits to try to identify the change which resolved the issue to reverse-engineer the vulnerability. Knowing the issue has been resolved gives them a narrower search window to try to find related information versus examining every commit for security impact.
This doesn't really reveal anything new, but could help an attacker react to a security issue before it could be fully disclosed.
Now, suppose disclosure occurs, some time passes, and the malicious user later sees that the issue has been reopened. This could allow the attacker to conclude with reasonably high confidence that the original fix was incomplete, and that the original vulnerability is still exploitable. Thus, they've deduced the existence of an unpatched, exploitable vulnerability from the "Open/Closed" status and have a pretty good idea of where to start looking for it.
This isn't a hugely high-impact attack scenario, but it's also just the first one I thought of. Generally, this is a slippery slope and most types of information we could disclose about restricted objects are exploitable in plausible scenarios, so we are unlikely to "declassify" any additional properties of objects.