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.