Page MenuHomePhabricator

Applications with Public permissions requiring users to login
Closed, ResolvedPublic

Description

There are some applications that require anonymous users to login, even if they are configured as "Public (no login required)". The ones that I found:

  • Audit
  • Calendar
  • People
    • Individual profiles require login
  • Owners
  • Tokens
  • Facts
  • Conduit
  • UIExamples
  • XHProf
  • PHPast

Maybe some cases do deserve a login (like the obvious "Settings") , but at least as a new anonymous user browsing Phabricator it feels random / buggy. Accessing to these applications as registered user, I don't see any reasoning for requiring login in most cases.

Just for the record, this is the original task in our project: http://fab.wmflabs.org/T115

PS: This is my first bug reported here! As a Bugzilla user I'm not even sure whether it is fine to add so many projects. Let me know if you prefer separate tasks, otherwise we can edit the descriptions striking out the cases resolved.

Event Timeline

qgil created this task.Apr 18 2014, 4:56 PM
qgil raised the priority of this task from to Normal.
qgil updated the task description. (Show Details)
qgil added a subscriber: qgil.
qgil updated the task description. (Show Details)Apr 18 2014, 4:59 PM

Some of these just haven't been updated yet, like the developer tools. A few have more specific issues:

Audit

See T4715.

Calendar
Facts

These applications are "Beta", and not expected to be fully operational.

People

Did you also set "Can Browse User Directory" to public?

qgil added a comment.Apr 18 2014, 8:58 PM

People

Did you also set "Can Browse User Directory" to public?

Oops, no, we hadn't. Now the list of users can be accessed anonymously, but accessing to user profiles still requires authentication.

epriestley edited this Maniphest Task.Apr 20 2014, 9:14 PM
epriestley edited this Maniphest Task.Apr 20 2014, 9:35 PM
epriestley edited this Maniphest Task.Apr 20 2014, 10:21 PM
epriestley edited this Maniphest Task.Apr 21 2014, 10:32 PM
epriestley edited this Maniphest Task.
epriestley edited this Maniphest Task.
qgil updated the task description. (Show Details)Apr 22 2014, 1:21 AM
mattflaschen added a subscriber: mattflaschen.

Another important one is Differential. E.g. http://fab.wmflabs.org/D1

The policy on that revision is "All Users" -- not "Public (No Login Required)" -- so it's expected that only logged-in users will be able to see it.

You can set the default policy in Applications -> Differential -> Default View Policy.

Changing the default does not change policies retroactively. You can Edit Revision -> View Policy to change the policies of existing revisions.

chad added a subscriber: chad.Apr 30 2014, 12:35 AM

D1 there is set to "All Users", not "Public". Differential supports Public visibility.

Thanks, my mistake.

qgil moved this task to Potential blockers on the Wikimedia board.Apr 30 2014, 3:13 PM

accessing to user profiles still requires authentication.

It looks like this is the only problem related to this task blocking our Phabricator Day 1. The rest is not urgent for us.

I think there's a bit of a policy question there.

Particularly, in the long run, I'd ideally like user profiles to feel somewhat personal and safe enough that users are comfortable listing their real names and adding profile pictures if they want. Making these accessible in general makes them googleable, etc., and generally reduces the safety of the space.

Generally, one hurdle we've had to overcome with Phabricator is shaking some of the negative associations technical users have with Facebook about it stealing all your data and selling it to the highest bidder on the black market, and so on. At the very least, I worry that opening up previously closed profiles is the kind of not-totally-thoughtful-about-privacy move that Facebook is frequently criticized for. It seems reasonable to me that some users, even on a public install, would not expect their personal information to be completely public.

There's also a class of information that we do not currently expose (or even collect in most cases) but might or will in the future, like email address, phone numbers (for SMS alerts), and maybe things like chat handles. I think these things should never be exposed publicly (unless the user explicitly wants that, maybe) but there is some utility in letting users share them privately or with others who they trust.

I'm not sure what the best way forward is here. One approach is just to avoid the issue:

  • What are the things you want logged-out users to be able to do on user profile pages?

If it's a small set of things, maybe we can create a simple logged-out page and tell users to log in to access most features, and then not resolve the rest of this for now.

If it's a larger set of things, we probably need to figure out a more concrete strategy for moving forward here.

qgil added a comment.May 13 2014, 10:03 PM

Public user profiles are ordinary in online communities and basically customary in open source projects. You follow contributions recorded publicly, you click the username of the authors, and you expect to access to their profiles. Wikipedia or GitHub are popular examples.

I worry that opening up previously closed profiles is the kind of not-totally-thoughtful-about-privacy move that

Sure, I'm not asking to open up the profiles here or in all Phabricator instances. The request is to allow Phabricator instances to have public profiles setting a policy for it.

There's also a class of information that we do not currently expose

Currently user profiles show the Name, Title, and Blurb entered manually by the user, and also offer links to the contributions of the user. There is nothing problematic about these fields. Emails are already defined through a different interface, separated from the profile.

What are the things you want logged-out users to be able to do on user profile pages?

The request is very simple: allow admins to set a policy to make the current user profiles public. Nothing else.

For instance, for Wikimedia users there is no reason to keep http://fab.wmflabs.org/p/qgil/ visible only to logged-in users.

btrahan edited this Maniphest Task.May 14 2014, 4:38 PM
btrahan updated the task description. (Show Details)May 14 2014, 4:40 PM
btrahan edited this Maniphest Task.May 14 2014, 5:00 PM
qgil edited this Maniphest Task.May 17 2014, 2:53 PM
epriestley edited this Maniphest Task.May 17 2014, 7:41 PM
epriestley edited this Maniphest Task.May 17 2014, 8:40 PM
epriestley edited this Maniphest Task.May 18 2014, 4:07 AM

I think there's a bit of a policy question there.
Particularly, in the long run, I'd ideally like user profiles to feel somewhat personal and safe enough that users are comfortable listing their real names and adding profile pictures if they want. Making these accessible in general makes them googleable, etc., and generally reduces the safety of the space.

If googlability in particular is a problem (though I'm not sure that is an issue, particularly with the limited profiles shown currently), that can be addressed separately with a NOINDEX directive (either robots.txt or <meta>).

epriestley edited this Maniphest Task.May 19 2014, 7:39 PM
qgil edited this Maniphest Task.Jun 12 2014, 5:00 AM
qgil moved this task from Potential blockers to Details on the Wikimedia board.Jun 17 2014, 7:19 PM
epriestley moved this task to Future on the Owners board.Jul 15 2014, 5:51 PM
qgil added a comment.Aug 29 2014, 8:45 PM

... and now we have a real use case where the lack of public user profiles affects us.

Thanks to the beauty of Dashboards, now we are testing a new homepage that is meant to become the homepage of the official Wikimedia Phabricator when we release it: http://fab.wmflabs.org/

It looks great when you are a registered user. Not so much when you are still anonymous. One main reason to include the profiles of the last three registered users is to show Phabricator as something human & approachable to newcomers. Basically, we are showing user profiles to those that cannot see them because of this policy limitation.

I also have learned that the custom avatars in Recent Activity will not be shown to anonymous users either... I still think that the decision of making user profiles public or AllUsers could perfectly be made by the admins of the Phabricator upstream.

I also have learned that the custom avatars in Recent Activity will not be shown to anonymous users either

Oh, this is just a bug. I can see most of them, but not @btrahan's -- I think because he hasn't changed his recently. I'll see exactly what we're missing, migration-wise. (@btrahan, you're the only repro I have, so don't change your profile picture!)

(@btrahan, you're the only repro I have, so don't change your profile picture!)

Broadly, this is T7879, and resolved by D12821, so you can change your profile picture freely again.

epriestley moved this task from Future to Dark Ages on the Owners board.May 26 2015, 7:11 PM

D13024 fixes this for Owners.

epriestley updated the task description. (Show Details)
chad added a comment.Jul 22 2015, 2:46 PM

Philosophically I'm fine making People "public". The main reason for me is that all the information on a Profile is already (in the most common cases) exposed in other "public" areas of the product (like hovercards). I do think though that when an install is public, we should have an additional reminder/note when someone goes to edit their profile as a reminder. With public profiles, I think we also need to be mindful of upcoming apps like oncall schedules, where some information might be actually private (and thus displayed in that individual app, like Calendar can) and not randomly exposed.

chad added a comment.Jul 22 2015, 2:48 PM

If there is a reasonable path forward that @epriestley will approve, I can do the grunt work and close this out.

Yeah, I'm mostly concerned about future changes (offhand: phone numbers, emails, messenger handles, oncall schedules, events/availability).

I'm okay with making profiles public for now, since we probably won't move on any of that for a while and probably need specialized policies around it anyway, and are likely to end up with some kind of public version of the page no matter what, and the more-modular direction we have on profile pages now generally lines up well with putting policy controls at that level.

chad updated the task description. (Show Details)Jul 22 2015, 4:34 PM
chad closed this task as Resolved.Jul 22 2015, 8:26 PM
chad claimed this task.
qgil awarded a token.Jul 27 2015, 3:39 PM