HTML syntax for granular permissions

[LeaVerou]

When Mavo started, we were only using flat files to store all Mavo app data remotely, and backends that were basically file stores. Therefore, there was no way of only being able to read/edit part of the data: either you were able to read/edit all of it, or none of it. The set of possible permissions were very small, and Mavo conveniently read it from the backend and applied it to the UI.

This works well for apps where the data is only managed by one person or a small team of people that trust each other, such as PIM apps and CMS-style applications. However, it makes several types of apps impossible, such as:

• Comments and ratings on collection items (read: public, write: own)
• Surveys (read: admins+own, write: own)
• Chats and discussions of any sort (read: *, write: own)

Thankfully, this restrictive assumption is challenged by new backends like Firebase. This means, there needs to be a way for Mavo authors to describe these granular permissions in their HTML. Ideally, the remote backend would read these permissions, verify them with the admin when they are logged, and set them remotely too. But even backends that require setting permissions separately need to reflect them into the UI somehow. Sure, the Backend could read them remotely, parse them and apply them, but that's an extra step that not all backend authors do.

We've already seen that backend authors tend to expect HTML authors to duplicate the permissions in their HTML, and have to invent their own syntax, which sometimes even goes against best practices:

• @valterkraemer’s Firebase plugin uses a mv-unauthenticated-permissions="read edit save" attribute
• @lizziew’s Firebase plugin expects keywords like public-read, public-write, user-write in the mv-app attribute (!).

Since this is a common need, we need to devise a syntax for it, and have Mavo process it, apply it in the UI, and expose it to the backends. This will also mean that backend authors are more likely to support granular permissions in that case, as it's much less work for them.

I will start trying to come up with a good syntax with some brainstorming:

Types of permissions

Currently, Mavo supports the following types of permissions:

• Read
• Add
• Delete
• Edit (also sets add + delete to true)
• Save
• Login (available only to unauthenticated users on backends that support authentication)
• Logout (available only to authenticated users on backends that support authentication)

Currently, Mavo reads these permissions from the backend, and exposes them on an mv-permissions attribute on the Mavo root. The mv-permissions attribute is read-only, and setting it doesn’t do anything.

User targets

The following scopes seem most useful, but perhaps I'm missing some:

• Nobody
• admins or specific named user group, for backends that support that
• logged in users
• creator of item
• everyone

The last three are probably the most useful, and should be included in even the tiniest MVP of this.
Possibly also combinations of the above, e.g. "logged in users except banned user group".

Potential syntaxes

1. We use one attribute whose value is a key-value list, like read: everyone, add: logged-in, edit: own, delete: own. If a permission is provided without a value, the implied value is "everyone".
   Name brainstorming for this attribute: mv-permissions, mv-can, mv-enable
2. We use separate attributes, e.g. mv-can-read="everyone" mv-can-add="logged-in" mv-can-edit="own" mv-can-delete="own". If an attribute is used without a value, the implied value is "everyone".

In both proposals, undeclared permissions would be inherited.

We need feedback about:

• Are the user targets above sufficient? Can you think of something else that you need?
• Do you prefer one or multiple attributes? Or perhaps you can think of a different syntax entirely?
• Any ideas about the names of the attributes and/or their values?

[valterkraemer]

Would there be defaults if no permissions are set?

Not syntax related, but if there are no defaults, the author has to set all permissions which would make syntax 1 a bit clearer. While if there are defaults, the user probably have to set less that would make syntax 2 clearer.

On a element with mv-multiple, would mv-can-edit="own" be equal to mv-can-edit="own" mv-can-add="logged-in" mv-can-delete="own"?

My vote go to multiple attributes, and mv-can-*.

To be consistent I think own should be owner and either of the combinations:

• everyone, no-one
• everybody, nobody
• all, none

[joyously]

Would the *nix system type of permissions fit this?
It's user, group, other having read, write, execute permissions each.
And would there be a fallback of local storage for those without permission to write? But that implies a different storage backend for each piece of data, which I'm not sure you were talking about.

[LeaVerou]

@joyously many of the common use cases I mentioned wouldn't be possible to define that way.

[LeaVerou]

@valterkraemer

To be consistent I think own should be owner

I think depending on the Mavo app, it may be confusing to think of the "owner" of each item as a concept, whereas "my own items" is pretty straightforward regardless of the schema.

[LeaVerou]

A different idea would be to have very very simple attributes (basically yes/no for each permission) and offload the complexity to expressions. Then, we would expose any information needed to implement common permission patterns via special properties in expressions, and update it accordingly upon login/logout.

The main drawback is that this would make it much harder to read this server-side and enforce the permissions, without requiring the author to specify them again. It would also make it much harder to automatically transform the permissions to whatever format the backend expects.

Attributes could be something like mv-can-view, mv-can-edit, mv-can-add, mv-can-delete

Special properties that need to be exposed in expressions would be:

• Info about current user: $username, $avatar, $name (these could also be used by the Mavo toolbar instead of the current custom code)
• Info about the user who first created an object ($creator?)

Then logged in becomes just $username, own items becomes just $username = $creator and so on.

[LeaVerou]

Issues that are blocking this:

• New special properties for currently logged in user #351 (to enable specifying meaningful conditions)
• Collections should be represented in the DOM #72 (to enable different permissions on collections and their items)

Anything else?

[LeaVerou]

Some more on this, from recent discussions with @karger and some more research.

Syntax

Attribute values

The two options are:

1. an expression-based syntax (e.g. mv-can-edit="post.owner = $username")
2. a more limited declarative syntax (e.g. mv-can-edit="own").

The obvious advantage of the former is flexibility, the main advantage of the latter is that it can more easily be compiled to various proprietary access control syntaxes of various backends. Perhaps a hybrid might be possible where common types of rules are specified via keywords, and expressions are also available.

In terms of common permissions, I did some very preliminary exploration by writing down what permissions that common types of apps need here and it appears that even a language as limited as:

• logged in
• own
• everyone
• nobody
• owner of ancestor object
• (and logical combinations thereof)

would cover a surprisingly large number of use cases.

Attribute names

It looks like the main permissions are: view, add, edit, delete, which can be specified via mv-can-* attributes.

add is certainly a permission that applies to the collection, and not the item, but it is unclear whether delete is an action that applies to the item or the collection. It seems more practical for it to apply to the item.

It is unclear whether we need a move permission. In most multiuser web apps in the wild there is no defined order, items are just ordered by date or some other property.

It seems convenient for these to inherit, though not clear if what should inherit should be the expression or the computed value.

Enforcing on the server-side

In terms of enforcing the rules on the server-side, there are two options:

1. compiling them to whatever proprietary access control language the backend supports, e.g. for Firebase it would be this
2. (@karger's idea) mirroring the app on our server and replicating the current user's edits to make sure they are not adversarial, then our app writes the data as a single privileged user. This would also allow granular access control on backends that don't support it, as long as they support user accounts, e.g. Github.

If we go with an expression-based syntax, 1 would be tremendous effort for even just one backend, while 2 is simpler to implement.
With a simple declarative syntax, 1 would be more feasible, but still a lot of work.

Note that granular access control can be still useful even if there is no backend (e.g. for localStorage), for better UX, so these attributes should still be available in those backends.

How do data actions behave?

Use cases:

• Restricted editing, with only specific data actions permitted. Then data actions override existing permissions
• Data actions as a convenience (e.g. add migraine, end current migraine). Then they need to follow existing permissions

Both are useful so both should be possible. I think the best solution is that data actions follow existing permissions by default, but we can have a special mv-can-trigger (or run, or execute...) permission that overrides existing permissions.

Special properties per node

To enable common types of rules, we need to store the object owner for each object, i.e. the logged in user that created each collection item, and expose it via a special property (e.g. $owner, $creator). Should we only store this if permissions are used or generally? If generally, it might be seen as too invasive (especially for collections of primitives), but if we only store it when permissions are specified, what happens with existing data?

Issue #590 is relevant here too.

To enable meaningful rules to be written, we would also need to expose user-related special properties, such as $user, $userid, $username etc. It is unclear how we should handle the issue of different backends supporting different properties, possibly we should have some standardized common properties (e.g. $username) and a $user variable that contains all properties the backend supports.

Misc

Some more thoughts and questions:

• According to a lot of the literature (e.g. [1]) access control gets confusing when rules can conflict. We should design our syntax in such a way that this is minimized, if not entirely avoided. The idea of specifying permissions only in terms of who is allowed to perform each action avoids this, though data actions overriding existing permissions can be confusing.
• There is a lot of repetitiveness in specifying these permissions. Both in terms of permissions for the same node (e.g. "whoever can edit, can delete") as well as across nodes (e.g. "in every collection, people can edit and delete their own items, and every logged-in user can add items"). Perhaps we should explore ways to minimize repetition. For the former, there could be shorthand attribute names (e.g. mv-can-edit|delete or mv-can-*), for the latter inheritance can help.
• It is unclear how default permissions can be specified, since they are typically backend-specific. Maybe we should take a leaf out of CSS' book and just have auto.
• It is also common to have access control that requires "permission" (e.g. ask to read, submit edit suggestion for approval etc). How would that be expressed?

[karger]

Even if "move within collection" is relatively unimportant because collection are often disordered, I expect there will be common cases for move between collections---e.g. moving a file to a different directory.

[LeaVerou]

Even if "move within collection" is relatively unimportant because collection are often disordered, I expect there will be common cases for move between collections---e.g. moving a file to a different directory.

Are there any cases where the permissions for that are different than the permission to delete from the first collection and add in the second?

[LeaVerou]

From discussion last week, @karger pointed out that there may be cases where you want to disallow delete, but allow move, to enforce that an item always has a parent.
However, we were unable to think of any real cases for that, and no existing AC system appears to have a separate move permission.

[joyously]

Would this be like Trello, where there can be multiple collections that hold tasks? You can move from one to the other, but only the board owner can delete.
Also, the concept of a forum, where topics can be moved from one to the other, but the user can't delete it. Only the moderator can move it, or delete (or hide).

[LeaVerou]

Thanks @joyously, these are excellent examples.

[LeaVerou]

Another issue: ratings and polls!

Ratings and polls are essentially collections (of votes) that have kind of odd access control characteristics:

• Logged in users can add a vote
• Everyone can see the total number of votes
• However, who has voted is not widely visible (someone should be able to see and edit/delete their own votes, but only admins should see all votes)

One way to describe this with our AC syntax would be to have a collection that can be edited by logged-in users, its items are visible to all but only editable by owner, and the items' individual properties are hidden to everyone but the owner, including the special $owner property. That way things like count() would work as expected.

E.g. something like this for a star rating widget:

<p>Average rating: [average(rating.value)]

<div mv-list="rating" mv-can-view="everyone" hidden>
	<div mv-list-item mv-can-edit|delete="own">
		<meta property="value" />
		<meta property="$owner" mv-can-view="own" />
	</div>
</div>
<div class="star-rating" mv-list="ratingWidget" mv-value="1 .. 5">
	<span mv-list-item mv-action="
		delete(rating where $owner = $username),
		add(rating, group(value: ratingWidget))">⭐️</span>
</div>

Note that in the code above the breakdown of votes is still accessible, it's only who voted that is hidden.
It gets even more complicated to hide the breakdown as well, and not sure if we can cover that.

However, I'm not sure if authors would be able to figure this out. But what alternative is there?
Perhaps some sort of privileged user storing an updated count, akin to database triggers? But no idea how that would work, or even whether it's more understandable.

It might be a good idea to just ask user study participants how they would do it, after they've experimented with the existing syntax.

[LeaVerou]

There are some patterns that keep coming up:

Possibly the most common one is a collection where items can be viewed by everybody, added to by logged-in users, but items are only editable by owner (and admins).

I wonder if we should have some sort of shortcut for common AC policies. Maybe an mv-can attribute that accepts keywords?

[DmitrySharabin]

Do you mean we could have some sort of presets? Something like chat, forum, rating, or whatever? From my perspective, such presets might be beneficial.

I'm not sure whether these names will be readable enough as the values of the mv-can attribute. What if authors could specify them this way: mv-permissions-like="chat"? And they can still use mv-can-* if they need more granular control.

[LeaVerou]

No, not like chat. Something that describes the actual AC rule. Not sure what that would look like.

[DmitrySharabin]

Ok. Got it.

[LeaVerou]

From yesterday's discussion with @karger:

What happens when default permissions are a superset of Mavo permissions? E.g. if using Github as a backend, with a certain user having commit permission. When that user visits the Mavo app, would they have permission to do everything or would the UI follow the permissions specified?

Often the mv-can-* attributes may be specified in liberal backends, just for UI purposes (e.g. in localStorage). That argues for following the attributes.
However, for security reasons, it may be better to expose the real permissions, so that the author can debug who actually has access to their data.

As often happens with these things, maybe we should pick a default behavior and have a toggle to switch to the other behavior.

[WebMechanic]

In the early days of my career I've been working with and administered Lotus Notes/Domino systems and databases. Notes is a NoSQL, document based database similar to MongoDB. Notes is the name of the client app, Domino the database servername.

They have the most flexible ACL I've seen so far based on hierarchical Names (LDAP) - explicit or implied - where access control is applied to "forms" or "views" used to

• create new data
• edit existing data
• view data (single items, lists)

I'll use some Notes terminology but you can easily adopt this to web forms and pages made from HTML.
I'll also describe how Notes handles things and what it utilizes to allow stuff to happen. Thid should give you a better picture how things interact in Notes, not how to implement them in Mavo or any of it's existing or future backend systems that require authentification. It may give you an idea of Notes' inner workings esp. with the LDAP background, and leverage a concept or two.

LDAP and hierachical Names

There's no concept of a "user id" in Lotus Domino thanks to the deep itegration of LDAP canonical names (there are binary .id files that provide encryption keys). If a backend requires such a thing as an "id", it's their responsibility to i.e. translate a "Notes Name" (a hierarchical and unique name like an e-mail address) that's been used in the frontend to authenticate. Being authenticated means that name will then be compared to other hierarchical names known by the app in parts or in full and looked up in groups and list that eventually have been given access privileges to perform predefined actions. Individuals dont have rights: the groups they belong to have.

Picture a system run by "acme-corp.net".
Any user with an email that ends in @acme-corp.net already has some implied access to that system; read only at least to some data. Somone (with any mail address) as a member of group-name@sales.acme-corp.net has a well defined set of access rights to stuff from the sales department, but different from the person with group memberships to support@it.acme-corp.net and mods@wiki.acme-corp.net etc.

Inheritance of access levels is implied by the hierarchical names of groups

• net.acme-corp.sales.management inherits from
• net.acme-corp.sales inherits from
• net.acme-corp

jane@sales.acme-cord.net has implicit rights to all things sales given her fully qualified user name, but no initial rights whatsover to wiki.acme-corp.net. However, her name might well be listed in the allstaff@acme-corp.net group that has read access to the Wiki.

Only Groups are given rights to perform actions.

Individuals (users) should never receive direkt rights in that system incl. the "Adminstrator" who's a default member of a group called adminitrators@acme-corp.net along with other personal names of staff.
It's that "administrators" group that has access to things @acme-corp.net.

You'd create a new ACL group, define what this group should or should not do to something, and put usernames and other groups inside it. The name of that ACL group is then assigned to the thing it should protect or display.

There are groups that by definition allow actions and groups that deny actions, but never both.
A "deny group" always trumps an "allow group". A deny group cannot create things. It prevents things from being created or edited or viewed/read.

The Depositor

Notes also features one particular access level: deposit that I never see in other systems despite it's simplicity and usefulness.
The most common example of someone being a "Depositor" with "deposition rights" is e-mail.
Anybody on this planet can virtually deposit an email is someone else's mailbox, w/o having any knowledge about where that physical mailbox files exists, if it exists, nor being able to read any of the mails store in it should it exit. As soon as they sent their mail they can neither read, move, or delete that very mail ever again. It became the property of the receiver and $Owner of the target mailbox who now has full access to data created by someone else "outside the system".

$Owner-ship has been transfered while the $Creator is preserved. This ownership transfer is implied in the business model of "sending and email". Every app can have similar ACL transfers implied by some action executed by an authenticated user.

Guest is also a User

A Guest is an unauthenticated user and as such can also have access privileges. If I visit any random website, I am usually the Guest with read access. The Guest is not equal to "everybody" or "world", both of which also include authenticated users.

A Guest can have explicit rights on their own to some part of an app existing users don't have: most obvious would be "Create new Account."
Existing users cannot (re)create their account as it already exists. They might change it and delete it (or mark it as inactiv), but they can't create it again using the very same name (at least under normal circumstances).

"Edit" never implies "Delete"

or create or add for that matter. Delete is a distict right on its own. An application may implicitely grant a user groups to delete what they "most likely" can also edit, but that descision is up to the busines model of the app or its administration.
The ability to create and edit something does not mean you can automatically delete it. Even if you're the $Owner.

Another example: If you hire someone to bulk add all your todos in yet another todo list, you don't want them to delete one of them without you knowing. No implicit delete right for the $Creator.

Third example: If somebody participates in a poll/vote, they can't "pull" their vote back out of the box, Although they created and then added that piece of data, they're not allowed to delete it. Just like you can't remove that stupid mail you sent from their mailbox.

Not all items in a system have to necessarily support all possible actions or access level defined.
Some actions might be performed by the system implicitely, not explicitly by something the user or group did, like creating a new log entry even if the user/group themself have no explicit access privilege to the actual log table/file.
It's the system task, process or daemon that writes log that has "create" access and if it's part of an API, it might as well have an ACL.

Any (billing) system that maintains a transaction and update log would also prevent an individual who's placing an order to delete this record. The ability to remove all contents from every field of such a record (using one of the edit "forms" that'd allow such a thing), does not imply that the whole item/record vanishes: at least its "record id" would remain in the system, so other data can still refer and link to that possivle buttload of emty fields.

Forms and Views

Another specialty of Notes are their "forms" and "views". Both contain the ACL that defines what a usergroup can do with the data and input fields a form contains or the fields and columns a view depicts. With Notes being a document database, each document contains a $Form field with the form name used to create the document. That form also defines what fields are stored in that document. A $View field can "suggest" what view should be used to depict the data of documents created with that form.

Whenever data is entered into the system (created, updated) it happens via some type of form with its own individual set of fields (properties) and it's individual ACL.
In most document databases the same kind of Records or Documents can have different fields from each other and they're defined globally in a collection/database but not individually for a specific "document type". Fields exist and Forms combine and store them together as documents; no space wasted by unused fields.

A form may define

• who can us it and what can be done with it
  • create a new thing
  • update an existing thing
  • delete the thing currently seen (read)
• "read only access" to fields like record id (it's present but the value can't be modified)
• "edit access" to the item's title
• allow to create new items using it (by showing a button labeld "Create" instead of "Update" or "Save Changes")

A view may define

• any Form/s used to create the data depicted by it (and the available fields/columns to expect)
• what colums are visible or
• what columns are hidden
• if and how items can be filtered or sorted (list of supported fields)
• who can delete items currently shown in that view
• who can create new items similar to those in that View using a (primary) Form associated with it

Different forms with different ACLs would be used to create a new item and edit an existing item where some fields might be "raad only" like the "created" and "last update" date fields, the item id, and other editable. Some fields might be changed in content but not become empty again (similar to a "delete field" privilege).
The form's ACL would define who can perform actions on its data by providing the names of groups and one explicit $Creator and an optional $Owner (despite the singular name this can be a list of groupnames).
Again: a deny group could prevent the $Creator from deleting an item s/he initially created using that form.

This is nothing new nor magical: we all use this schema just without thinking about it on such a granular level.

• input type hidden for the document's record id (no access)
• a span or code to show such id (read onyl)
• input type text for the title field (edit)
• buttons to "submit" the Form data (potential create/update)
• to the some backend URL/API ultimately performing the requested action

I hope this was somewhat useful.
It got a bit longer than anticipated 😇