User level protection. Sometimes protection live can be customized for a particular user.

I thought that this was limited to editing, and wouldn't affect reading. Did you see any per-user protections that would apply to reading?

Given the (typically) limited size of watchlists and reading lists, it might be worth considering downloading & caching the full list, and doing those checks client side. Another option (if size is a concern) could be serving a bloom filter, and double checking if that matches.

I'm not sure whether it makes sense to add this to the REST API. It wouldn't benefit from caching at all, and although we support logged-in calls, the actual authorization is based on the mediawiki API, so calling action API for this data would most likely be more efficient then wrapping it to the REST API

@GWicke @Pchelolo thanks, I added a new use case too that is further out, but still something important: highlights and notes. While highlights have other issues that need to be solved first (persisting across revisions) - it is a much requested feature.

I thought that this was limited to editing, and wouldn't affect reading. Did you see any per-user protections that would apply to reading?

Well this apples to Reading in that we have editing within the apps. Currently we can't display these permissions to users (like some users have access to edit protected articles)

I'm not sure whether it makes sense to add this to the REST API. It wouldn't benefit from caching at all, and although we support logged-in calls, the actual authorization is based on the mediawiki API, so calling action API for this data would most likely be more efficient then wrapping it to the REST API

Makes sense. I'm asking because we are getting our page content from MCS via Parsoid (all in RESTBase) so it seemed natural to get this info here as well.

Well this apples to Reading in that we have editing within the apps. Currently we can't display these permissions to users (like some users have access to edit protected articles)

I was just focusing on the per-user case, where groups are not enough. Regular page protection is group based.

Generally, I think there are two directions we could go with all this per-user stuff:

1. Make API requests for any page / view to determine context-specific user rights.
2. Ship a summary of a user's capabilities, per-page blocks, watchlist etc to the client, and evaluate each view against that.

There are pros & cons for both approaches. 1) is simpler for client code, and makes sure that the very latest information is used every time. 2) should perform better for typical users and operations by maintaining the ability to use caches for most operations, and makes it possible to use this information for other tasks like visual highlights of watched pages.

Generally, I think there are two directions we could go with all this per-user stuff:

Make API requests for any page / view to determine context-specific user rights.
Ship a summary of a user's capabilities, per-page blocks, watchlist etc to the client, and evaluate each view against that.

There are pros & cons for both approaches. 1) is simpler for client code, and makes sure that the very latest information is used every time. 2) should perform better for typical users and operations by maintaining the ability to use caches for most operations, and makes it possible to use this information for other tasks like visual highlights of watched pages.

@GWicke makes sense - and this was the breakdown in my head too.

One point that @Tgr brought up was mobile web clients. While caching is pretty easy in apps, web clients are a tougher situation. The mobile web may have a browser with a cache, it may not. Or a user may disable or restrict the cache size. In those cases getting the information for a page would be the ideal solution. Do you see any other way around this?

Do you see any other way around this?

The typical data size we are talking about here should be in the single-digit kb range, which should not be a problem for mobile clients. Even if localstorage / indexeddb was completely disabled, re-fetching this information once per session wouldn't be so bad.

Just to chime in on the edit permission indications in apps when using RB.
dl;dr: the check is done on the client side.

Like MW API output MCS provides an editable boolean flag for the page. Since in RB this is cacheable, non-user-specific page metadata, one should consider the editable flag in MCS output more as anon-editable (even though it's currently called just editable). When anon-editable === false the the page is consider semi-protected.

The Android app gets a list of the user's group memberships right after login. When a semi-protected page is encountered then it also checks if a user is logged in and if the user is in one of the groups that allow the edit action based on the protection array.