User data can be divided into 3 categories, by accessibility required for normal function:

1. User name (and photo), as is displayed when the user is the author of public content. Other users have no data in this category. Should be publicly accessible when the user has authored public content, in the display of that content, otherwise not.
2. All other user data. Should be accessible to the user themself and those who have read access to the User content. Except...
3. Password hash, should be accessible to no-one except the code that validates passwords.

Currently, when someone is granted read access to User content, they can access all of these (to be verified) through the API. On the other hand, if they don't have this access, they can't see who is the author of public content, unless special measures has been taken for this, like fetching it with sudo(), or cloning the author info into a separate content, or field in the public content. This is not ideal.

If any site admin gives anonymous users access to read User content (in order to make it easier to display content authors) then they are opening up a major security hole - the API might then allow anyone to harvest user emails, physical location / home address if that's registered, possibly even password hashes. It's the responsibility of the site admin not to do this, but is the current API encouraging this bad setup?

Can we make the access more granulated, so that it works more like expected?

• First priority would be ensuring that password hashes cannot be read by anyone.
• Second priority would be making author profiles accessible without read access to the content - though this is a major task, it means overriding our content security system and could open up new security holes. Or it can be done with field-based permissions, if we develop that. Can it be resolved with good documentation of sudo and other approaches, instead?

CC gggeek gg andrzej.longosz@ez.no andre.romcke@ez.no