Why do we hide object permissions when user has no write perm?

[leplatrem]

kinto/kinto/core/resource/model.py

Lines 278 to 282 in 7ca4ab4

	# Permissions are not returned if user only has read permission.
	writers = permissions.get('write', [])
	principals = self.prefixed_principals + [self.current_principal]
	if len(set(writers) & set(principals)) == 0:
	permissions = {}

If the history is enabled this user could still see them anyway...

OH, and BTW this doesn't seem to be explicited in the docs.

[leplatrem]

@Natim proposed this in #123 and I implemented it :)

[leplatrem]

Maybe because we didn't want to expose the blocklist permissions to the whole world? Expose which emails are allowed to modify certicates blocklist entries for example.
https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates

[glasserc]

Hmmm. This might be an acceptable use case, but I'm not sure it makes sense here. After all, the public bucket is only editable by a very few people in ops -- it's not the staging bucket, for instance. I don't think it's dangerous to leak that information, but maybe I'm wrong. Even with the staging bucket, I kind of wonder what the value is in keeping that information secret. Mozilla "works in the open". Anyhow, I think there are lots of use cases where a user who doesn't have write permissions ought to be able to see something about the object's permissions. For example, let's say I'm looking at a record that I have read permissions to -- right now I don't even know what permissions I have on that object. I think it makes sense for me to be able to know whether my friend has read permissions to it as well. Google Drive, for instance, lets anyone with any level of access to an object see who the owner of the object is and who else has permissions on the object.

I think what makes this feel unsafe is the fact that it's an email address rather than a semi-opaque user name. Maybe this is a good use case for the accounts plugin? Then we could at least hide the email address behind a semi-opaque userid. (Of course, that userid is only one step away from an email address, but still...)

[Natim]

I don't think it's dangerous to leak that information, but maybe I'm wrong.

In the case of kinto-signer setup we don't have this issue for sure but globally as a Kinto user, when I am using Kinto on a shared collection I don't want to see the email addresses of people that added things into the collection.

Google Drive, for instance, lets anyone with any level of access to an object see who the owner of the object is and who else has permissions on the object.

Are you sure about that?

what makes this feel unsafe is the fact that it's an email address rather than a semi-opaque user name

When we designed this, we decided it was easier to use a email address when using a shared collection because you could guess the name of the user from it without having to rely on something that would map email addresses and users ID.

Today we have the account plugin and we could have an endpoint that maps email addresses to user ID.