Page MenuHomePhabricator

Private tasks should have a placeholder on the workboard
Closed, DeclinedPublic

Description

Steps to reproduce:

  1. create a private task and add it to some project
  2. visit the workboard with a user who has the right to open the task
  3. visit the workboard with a user who does not (I just used incognito mode)
  4. compare

Expected results: the unprivileged user sees some kind of placeholder without learning the title or other details of the task

Actual results: there is no sign of the task existing. Even the story point total (on sprint boards) is different.

Pro: safer (one can't use workboards to learn that there is a security task, what projects it belongs to, how many story points it takes, what stage of completion it is at).
Con: sprint planning is somewhat confusing with different people seeing different things.

See also: T90239: A resolved, blocking, restricted task is not shown struck out but marked as resolved in the log

Event Timeline

Tgr created this task.Feb 26 2015, 1:22 AM
Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added a project: Phabricator.
Tgr added a subscriber: Tgr.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 26 2015, 1:22 AM
Qgil added a subscriber: Qgil.
Qgil added a comment.Feb 26 2015, 9:37 AM

Well, I'm not sure it is worth the hassle. Does an anonymous user really need to do the math with agile points?

Qgil moved this task from To Triage to Need discussion on the Phabricator board.Feb 26 2015, 9:37 AM
Aklapper triaged this task as Lowest priority.Feb 26 2015, 1:48 PM
Tgr added a comment.Feb 26 2015, 7:41 PM

Security bugs are invisible to most non-anonymous users as well; often only the developer who will work on it is given access and the rest of the team is not.

Robla just helped to verify this with a logged-in account and the security bug is indeed invisible and not counted towards the story point totals. I assume same goes for burndown charts etc. Given that PMs rarely get invited to security bugs, I think this can become quite confusing.

Tgr updated the task description. (Show Details)Mar 2 2015, 7:08 PM
Restricted Application added a subscriber: scfc. · View Herald TranscriptFeb 18 2016, 12:52 PM
Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptJul 2 2016, 7:33 PM

This should be brought to upstream and discussed there. We won't introduce a custom patch for this, and there likely are valid reasons and concerns when it comes to leaking information why to not display such placeholders, and to give more access rights to such "private"/restricted tasks instead to those people doing the Scrum/Points planning to allow them getting the full picture.

Restricted Application added a project: Upstream. · View Herald TranscriptOct 7 2016, 4:59 PM
mmodell added a subscriber: mmodell.Oct 7 2016, 7:17 PM

The main concern with security bugs is that they are only available to people under NDA to prevent leaking sensitive details to the public. With a WMF team PM, I can't imagine that they should be kept in the dark.

The solution there would be simply to CC the PM on security tasks.

Qgil removed a subscriber: Qgil.Oct 10 2016, 12:26 PM
epriestley added a subscriber: epriestley.

I think we're very unlikely to implement this specific change (placeholder cards) in the upstream. See also T187051#5191464 for a similar issue.

If we show a placeholder task and that placeholder task respects the filters on the workboard, an attacker or unprivileged user can discover most of the details about the task by executing different searches. For example, they can discover who the task is assigned to by searching for different assignees and seeing if the placeholder appears. They can discover other projects the task is in with a similar strategy, and can then use fulltext search to figure out a lot of details about the task.

If the placeholder doesn't respect filters, I suspect the behavior would be quite confusing/unintuitive.

Disclosing just the open/closed status of the task and nothing else can be dangerous on its own (see linked comment above for an example).

If this is really a problem ("PMs routinely have major difficulty estimating project timelines accurately because of the development cost of secret issues") I think we're more likely to find solutions by looking at approaches other than placeholder cards. For example, perhaps we could have a rule like "alice is the PM for project Q, so to add a task to project Q it must be visible to alice". But I suspect this is somewhere fairly far down the list of sources of timeline/forecasting uncertainty?

A possible caveat here is that some fact/charting stuff is likely to encounter difficulty fully respecting policy controls: we may not be able to render a custom burndown chart for each user with exactly their permissions in large projects. So it's possible that charts may show numbers which bypass policies, somewhat mooting this. This is undesirable and means we're leaking some amount of information so I'm going to try to implement charts which fully respect policies, but it may not really be practical without making an unacceptable performance tradeoff.

Aklapper closed this task as Declined.Jun 9 2019, 12:05 AM

Declining per last comment.