Currently unit users behave like super users and can do anything on the cell they have created.
But it is problematic for actual PDS Provider to be able to read the CONTENTS of PDSs provided for its customers.
Remedy Spec Draft Idea
[ ] Limit the default privilege of Unit Users so that they can only create new cells and bulk delete cells they created, prohibiting currently allowed operations of reading / wring cell contents.
Also use Unit User Roles to keep backward compatibility. More specifically, change the meaning of "unitAdmin" and create new Unit User Roles.
UnitAdmin
[ ] can search all the cells including ones which other unit users created.
[ ] can behave as other unit user with X-Personium-Unit-User header.
[ ] but cannot handle the contents
CellContentsReader
[ ] can read (get / search) the contents of cells created by the unit user.
CellContentsAdmin
[ ] can do any operations (write / send message .. ) against the cell created by the unit user. (Equivalent to current unit user's power.)
Importance
GDPR and other security/privacy authentication (ISO, PCIDSS, SOC2, etc.) compatibility.
In real use in the past, there were requirements against Unit Manager GUI to make it read-only. Some people feared to use Unit Manager against production environments and did not use it because GUI bug may break the production data.
SawamiWataru
commented
6 years ago
Background
Currently unit users behave like super users and can do anything on the cell they have created. But it is problematic for actual PDS Provider to be able to read the CONTENTS of PDSs provided for its customers.
Remedy Spec Draft Idea
Also use Unit User Roles to keep backward compatibility. More specifically, change the meaning of "unitAdmin" and create new Unit User Roles.
UnitAdmin
CellContentsReader
CellContentsAdmin
Importance