"Default Permission Limits"

"Default Permission Limits" - Help page

Sun, 13 May 2018 19:15:45 +0200

via

I'm not sure I understand what are the "Default Permission Limits" as explained in the help page. Are they the ones that are created according to the channel role we choose?
For example, the help page says "The limit applies to any published thing you create which has no privacy or access control. For example if you publish a photo and didn't select a specific audience with permission to view it, we apply the limit". What limit? The one that is created according to the channel role we choose?

I think the answer is yes to my two questions, but I want to make sure.

permission

show all 14 Comments

Sun, 13 May 2018 21:00:48 +0200

You are correct. I tried to build up the concepts in a logical order starting with the fundamentals in my article Understanding the Hubzilla permissions system, but I didn't do as well as I wanted to. Hold on tight; this is going to get pedantic:

You start with identities (i.e. "channels") that each own data and want to share that data with other identities in a private way.
An identity (i.e. a "channel") can share an item with another channel with whom they have "connected" and control access to the item using an Access Control List (ACL) specific to it. This determines the first "limit" on who can access the item.
There are a set of default permission limits that apply to all items shared by a channel. These permission limits can come in pre-configured sets according to the channel permission role you have applied to your channel. For example, if you choose the "Social - Public" role, then your default permission limits set your posts to be public whenever you neglect to set an ACL for that post. This is also true if your channel permission role is "Social - Private"; however, if you choose "Social - Private", a default ACL will be applied to posts that restricts access to your "Friends" privacy group, which you may choose to change to Public for specific posts. I point this out because in both roles, the default permission limit for a post is Public; the only difference there is that one role adds a default ACL for you to avoid accidentally sharing something publicly.
As this demonstrates, channel permission roles are primarily a way to reduce the complexity of setting all the default permission limits, but a permission role defines more behavior than just that.
A third layer of access control that is applied is the connection permission limits you can apply to individual connections. These allow you to customize the permission limits for individual connections, although the permissions that you can customize depend on the permission role you have chosen. For example, you can typically grant or deny permission to individual channels to send you their posts such that they will automatically appear in your "network stream". This is why we have to talk about default permission limits, because we must distinguish the permission limits that apply to all connections and the connection permission limits that apply to specific connections.
Finally (yes, there is more; there is always more...), there are permission categories that are simply a way to store a set of permission limits for convenience. For example, there is a predefined "follower" permission category that denies the ability of a connection to send you their posts. You could choose this permission category as the one which is applied to new connections by default if you are the kind of person that does not want to clutter your network stream with the posts of all your connections and instead prefers to visit the channel pages of your connections individually to read their content. You can always edit specific connections and adjust the connection permission limits as you like, within the flexibility allowed by your channel permission role.

Sun, 13 May 2018 23:37:14 +0200

Permission limits:
    Can the viewer do this action?

ACL:
    *If* the viewer can view my photos, can the viewer view *this* photo?

This is critical for "write" permissions because there is not yet an ACL for the thing being created. So we need a configuration to check if the viewer can even do this action. It isn't usually as important for "read" permissions, but there are cases like "can view my connections" where individual connections don't have an ACL, so we need a global limit for who can do this.

The limits are normally set automatically by the permission role you selected at channel creation time, but in the custom/expert role you have complete control over each aspect of the permissions.

Mon, 14 May 2018 13:16:37 +0200

Thanks both for your really precise answers. It's much more clear now...

Tue, 15 May 2018 23:48:55 +0200

By the way, I just realized that permission categories are called permission groups in the settings, but the title of the page when you click on "permission groups" is "permission categories". May be worth to change that...

Wed, 16 May 2018 02:07:12 +0200 last edited: Wed, 16 May 2018 11:20:59 +0200

Here's a pull request: https://github.com/redmatrix/hubzilla/pull/1174
What do you think?

(edit: updated pull request link)

Wed, 16 May 2018 15:54:44 +0200

that was quick! Thanks a lot!

Wed, 16 May 2018 19:03:52 +0200

I have another question on the same topic: Are permission limits more important than ACL? So if the connection with Peter doesn't allow him to see your pictures, even if you use ACL to give him this permission, it won't work. Is that correct?

Wed, 16 May 2018 21:47:06 +0200

In the article I linked above, I tried to convey the idea that Hubzilla will take the most restrictive approach. If your permission limits for Paul grant Paul permission to view your photos, but you set an ACL on a photo that excludes Paul, then Paul cannot see that photo. If your permission limit for Paul is to deny photo viewing, and yet you include Paul in the ACL for a particular photo, he will still not be able to see the photo.

Wed, 16 May 2018 21:48:57 +0200

I'm restating Mike's concise answer above, by the way:

Permission limits:
Can the viewer do this action?

ACL:
*If* the viewer can view my photos, can the viewer view *this* photo?

Wed, 16 May 2018 22:11:45 +0200

Is that correct?

Correct. We always check "can Peter see your files/photos" before we check "can Peter see *this* photo". And if the first check fails you'll never get to the second.

Thu, 17 May 2018 09:20:22 +0200

Thanks again! Permissions are hard to understand at first, but the more you understand it, the more you realize how precise you can be with it!

Sat, 19 May 2018 01:12:14 +0200

Thorsten

thorsten@hochminuseins.net

I think I came a bit closer to understand permissions in Hubzilla, but one thing is still not clear to me.

Each permission of the permission roles can the following limit:

Nobody Except Yourself
Only those you specifically allow
Anybody in your address book
Anybody On This Hub
Anybody in this network
Anybody authenticated
Anybody on the internet

But for some permissions there is an additional restriction to the "friends" privacy group.

If you are in expert mode you can also definie a default privacy group. Would this default privacy group be active for all permissions? Or is the existing of a privacy group bound to one of those limits?

What I'm trying to do is to determine when this privacy group is relevant to a permission and when not. Is there a rule for this?
Sorry if I cannot make clear what my intention is.

Sat, 19 May 2018 01:41:50 +0200

I think we've previously covered the fact that permission limits are used in addition to ACLs.

Some permission roles create a default ACL which includes the 'Friends' privacy group and all new connections are added to this group.

There is a reason for this: to make a post public you don't have to mess with custom permissions and limits, you simply change the ACL and untick the Friends group. If you change the permission limit to accomplish this you've also changed the visibility of any existing posts/items which have no ACL. This could be a dangerous decision. For this reason all of the predefined roles default all 'read' permissions to public and control access completely with ACLs.

Many newcomers trying to use 'expert' permissions didn't get this concept and immediately set their 'can view my channel stream and posts' permission to something restrictive. What they didn't understand is that if they decide later to make something public they have to change the limit, and in so doing they make ALL their previous posts public, because they didn't have any ACL set. This is why we strongly recommend people use the predefined roles and leave the expert permissions for experts.

It idoesn't have to be this group, but we create a Friends group for everybody so it's the only one that we know should exist.

Sat, 19 May 2018 11:25:09 +0200

Thorsten

thorsten@hochminuseins.net

Some permission roles create a default ACL which includes the 'Friends' privacy group and all new connections are added to this group.

There was my thinking error. I thought that the "Friends" group is part of some individual permissions. But it's the default group for new connections and default for ACL. I didn't sleep well because I thought the whole night about that.

Thanks

I will try to sum up what I've learned this afternoon and see if I can write a small text for the documentation.

One of my professors at university said: If you think you understood it, try to explain it to somebody else.