Privacy: Avatar public available

[gsantner]

Steps to reproduce

1. Get to know any username of an nextcloud instance
2. Get avatar image by using https://<domain>/nextcloud/index.php/avatar/USER/<size>

Expected behaviour

Configurable by admin

• User image
• Some default image
• require login / Show access denied

Actual behaviour

Avatar image is available to public

Server configuration

Nextcloud version: 12

[LukasReschke]

We don't consider the avatar a secret information as this is also required for other features such as federated cloud sharing etc.

But it may be worth to point this out to the user in a more clear way in the UI. Display names should be hidden and there's already an internal ticket about this.

cc @nextcloud/designers

[gsantner]

@LukasReschke
I already though about noting the use in federation also, but e.g. in our case it's not in use. And if so, a empty/default image would also be very enough.

[jancborchardt]

The personal details visibility settings should be respected of course. For the picture, the default is "Visible to local users and trusted servers" so it should not be public, right?

cv @schiessle

[jancborchardt]

(If blocked, the avatar placeholder algorithm with the letter-in-colored-circle should be used.)

[rullzer]

Starting with NC13 avatars will be generated. So we don't leak displayname etc.

[leonklingele-work]

@rullzer what exactly has changed since? This issue is still reproducible with v13.0.4.0.

@fancycode fyi

[go2sh]

I think its not about the display name (or username). Its about the avatar itself. Right now anyone can access every avatar by just knowing the username (or gessing).

[leonklingele-work]

Reopening as issue not resolved as expected.

[cmot-weasel]

Hi folks,

Just to throw in my tuppenceworth, this is still a thing as of NC16, and I'm beginning to get folk leaning on me with the install at work.

Avatars are pulled automatically from Active Directory (I believe enable_avatars is depreciated too), and displayed when folders are shared via link to external companies - our users are somewhat uncomfortable about this, and the question has been raised if this is a leak of staff's personally identifiable information.

My hacky workaround (apologies, I am not a developer!) was to pop the following inside the try/catch loop of getAvatar() in /core/Controller/AvatarController.php to prevent unauthorised (i.e., external) users from viewing avatars:

if (!\OC::$server->getUserSession()->isLoggedIn())
{
    $resp = new Http\Response();
    $resp->setStatus(Http::STATUS_NOT_FOUND);
    return $resp;
}

It works, but it's not ideal - possibly a system-wide or per-user setting that could be implemented though? I think this may be an issue that'll increasingly rear it's head in future.

[raqbit]

Still a thing in NC17, just discovered it myself and found this issue.

The avatar picture (At /avatar/<user>/<size>) is public despite the privacy setting (Public, Contacts or Local).

The privacy setting for the avatar is being ignored, which I think is a bug.

[Zocker1999NET]

Again a thing, see a4b2403, this commit reverted #17715 effectively. Now (tested with v21.0.2 and v20.0.10) profile pictures are public for the whole world again except when configured to the most restrictive setting "Private". But the descriptions still let the user assume up to "Federated" that the image should not be public (e.g. if federation is only allowed with other servers of the same cooperation/university/…

[nickvergessen]

It says "and guests" in the description on "Local".

[Zocker1999NET]

But then the other settings would make no sense, I think. Then, what is the real difference between "Local" and "Federated" as I understand the difference in that trusted third party servers should not be able to show the picture to their users but, effectively, the are able to do so. Then this setting is not a real protection but only security through obscurity/policy.

Also "and guests" feels kind of vague, because, in the context of my personal & family instance, "guests" are persons who have access to some files/data I shared with them, e.g. friends and colleagues (as I do not use this instance for real public shares). This still does not include the whole world.
Also in the context of a public reachable company instance: Usernames might be public available as these might be the same as their local parts of the email addresses (e.g. username@example.com), so public available. Employees now have the chance to upload a profile picture for their colleagues in Nextcloud, and configure it to "Local" visibility. "Guests" still can mean other people known to the company. Still a malicious attacker who gained knowledge about their mail address can also now see their profile picture IMO without consent and knowledge of the employee.

From a legal perspective: To publish a profile picture of a user you require consent (in the EU, see GDPR), but this is not consent-worthy in my opinion. So if big public Nextcloud instances have not modified the description there and have not explicitly informed the user in another way, this should be a violation of the GDPR for them. (I'm not sure about the legal issue here, but still it is too vague, I think)

[nickvergessen]

Maybe instead arguing randomly with different reasons you just describe your usecase and where this is a problem with the current settings not covering it.

[Zocker1999NET]

Okay, I made that more complicated than it should be. I'll try to describe my problem more structured and with a personal reference (which is okay for me).

User Behavior

User zocker on Nextcloud instance cloud.banananet.work uploads a profile picture and configures its visibility as "Local".

Expected Behavior

They expect, other cloud users and invited guests (share link recipients) can see their profile picture. They expect, outsiders cannot see their profile picture (even if Federated Cloud ID is known, here zocker@cloud.banananet.work).
Outsiders / GitHub users / third-parties (uninvited guests) see no picture profile or an anonymous profile picture (like the generated ones before).

In a nutshell: The implementation of #17715 did just that.

Actual Behavior

• With the knowledge of the instance domain cloud.banananet.work and one user name (here zocker), they can see the profile picture, even if they did not get a share link.
• One can brute force user names to gather more personal information, e.g. the look of someone (me?) they did not know.
• Knowing user name and instance domain (researching GitHub) allows third parties to see personal information (here the profile picture) as well.
• Example: https://cloud.banananet.work/avatar/zocker/64

Did I get my problem across?

[t-markmann]

A user just called me. This is dangerous and leaky.

Many organizations generate the usernames from real names. There are statistics about most used names in countries (take Müller, Meier, etc. for Germany) --> run a script and grab
[initial-letter]mueller ; [initial-letter].mueller ; mueller.[initial-letter] ; mueller[initial-letter]
Do this for 26 letters and the most used 100 names.

Most school homepages link their Nextcloud instance on their homepage and I bet there are public directories of Nextcloud instances. --> easy possibility to get many pictures and valid accounts in Nextclouds from GDPR protected people.

It does not matter if you think this is not privacy relevant. This is personal data regulated in GDPR.

[Scaenicus]

With the new Nextcloud Hub II (23.0.0) the profile page was brought up as an issue within my organisation.

Is it possible to have different default and/or enforced values for "Profile visibility" (like "Show to logged in users only").

[gonzalo]

I'm able to reproduce this bug on Nextcloud 25.0.7

User selects the "hide" option in avatar visibility inside its profile settings. In user public profile page the Avatar image is not shown https://nexe.ua.es/u/my_user (just the "Letter" default icon) but anyone, logged or not, can access to their avatar image using the direct link to a size version https://nexe.ua.es/avatar/my_user/512