Page MenuHomePhabricator

Figure out how to render external accounts in the UI
Closed, DuplicatePublic

Description

Offshoot from T3732. We now load handle data and present it in the UI in a not-broken way, but err on the side of caution on exposing identifying information and just show, e.g., "Email User" rather than "personal.email.address@gmail.com".

I think there are three major concerns here:

  • Identity: It's highly desirable to be able to figure out who an "Email User" is if they're a coworker, and this is basically required for grey accounts to be usable in most contexts.
  • Privacy: Especially on public installs, exposing full email addresses would be a major departure from how closely we guard them in all other contexts. Exposing things like Facebook accounts is potentially even worse.
  • Authenticity: Some solutions make it very easy to spoof an external user. This should be as hard as is reasonable.

Some possible approaches:

  1. Mutate email addresses ("a...n@gmail.com"). This seems relatively bad on all three dimensions.
  2. Show email names, but not addresses. For example, if you send email as "Abraham Lincoln <alincoln@gmail.com>" we'll display "Abraham Lincoln". This seems good for identity without a big hit to privacy. We could show usernames in other systems (facebook, twitter), which are somewhat identifiable but probably the best we can do.
  3. Make up a proxy username based on hashing things ("Glorious Fish Apple"). This is good for privacy and authenticity but not great for identity and probably confusing.
  4. Let installs customize it / let users customize it: we can probably get OK solutions here but at the cost of a lot of implementation complexity.
  5. Make up a proxy icon based on hashing things. This is probably a straightforward win on authenticity when an icon is shown, since it's fine if these aren't meaningful.
  6. Be restrictive when the user is logged out ("Email User") and more permissive when the user is logged in (show address or similar). This is okayish but I don't love it.

I'm inclined to start with (2) and (5), and give external accounts some sort of pseudo profile page that's linked, and see how far we can get with those, since they seem like the most reasonable approaches that don't involve major tradeoffs or require a lot of complexity.

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Auth.
epriestley added subscribers: epriestley, qgil, chad and 2 others.
epriestley edited this Maniphest Task.Jun 28 2014, 6:17 PM
J5lx added a subscriber: J5lx.Jan 14 2015, 5:00 PM
eadler added a project: Restricted Project.Aug 5 2016, 5:24 PM
urzds added a subscriber: urzds.Jul 12 2017, 11:13 AM
epriestley moved this task from Backlog to Grey Users / Nuance on the Auth board.Dec 12 2018, 8:36 PM

I'm going to merge this into T12738. Although that task primarily discusses Nuance as a Phacility support tool and we ended up building a standalone Support tool instead, I generally believe Nuance is the most likely pathway for interactions falling under the general "helpdesk" umbrella.

I think the most likely pathway on this particular task is that we completely compromise "privacy", render Abraham Lincoln <alincoln@gmail.com>, and use policies to control which staff have access to Nuance to see the full original interaction. Staff can redact or summarize appropriately when triaging helpdesk email into tasks.