Restricting users

Using a computer is mostly about executing apps, reading, writing and doing. But it can also be about not doing.

Confusing? Bear with me.

Imagine for a second that you are in an elementary school. The leadership is optimistic on exposing students to technology. They have set up big rooms with rows and rows of computers ready for their students to use.

Would you give complete permissions to these teenagers using the computers? Would you allow them to install and uninstall programs as they wish, access any website they feel like, use for as much time they want?

An elementary question

This is an intriguing situation to think about. At the same time that we want to restrict what the user can do — in this case, the student — we still want them to be able to get stuff done.

Thanks to Cassidy Blaede from the elementary OS team, this school-wants-to-limit-students situation was brought to the roundtable during the Parental Controls & Metered Data hackfest that happened during the second half of April.

The event itself was extensively covered already by Cassidy, and by Philip’s and Iain’s daily reports, and that is not going to be the focus of this article. I’m personally more interested in the design and technological aspects of what was discussed.

Apps or not apps

Naturally, when talking about user restriction, apps are probably the very first aspect of it that comes to our minds. Followed by browsers.

There is not a lot of controversy to the idea of assuming that administrators are likely to be the “supervisors”, and users without administrator privilages are the “supervised”.

At first, the use case we thought we were dealing was mostly about guardians or parents restricting what kind of contents, applications, or websites their kids would be able to access.

This is natural on systems that are heavily app-based. Smartphones have interesting implementations that are not only sane, but also technically feasible. But the traditional way of distributing apps via distro packages, and executing them without restrictions, makes that task incredibly hard, impossible dare I say. Unfortunately, the Linux desktop in general is not quite there yet.

Flatpak to the rescue!

Implementing app restrictions generically may be close to impossible on the traditional desktop, but it is actually very much feasible on newer technologies such as Flatpak.

If you have an OSTree-based immutable filesystem where all user-managed apps are installed via Flatpak, such as Endless OS or SilverBlue, app restrictions suddenly becomes even more realistic.

In fact, we at Endless have implemented something like that already, even if a bit rudimentary.

For the purpose of continuing the hackfest discussions, Allan managed to do a quick sketch about it:

An interesting aspect of the mockups is the “Supervisor Password”; a password that does not give full root permissions, and yet allows whoever is managing the system to assume the role of supervisor. Think of a teacher, without the administrator password, but still able to supervise students’ accounts.

But browsers…

Restricting websites, however, is remarkably tricky to accomplish. It is essentially impossible to whitelist websites, at least when implenting it outside the browsers themselves. In general, blacklisting is easier(ish) than whitelisting because we don’t have to deal with the case of websites accessing contents outside their domains.

I’m pretty sure this is a reasonably studied field though, and I simply lack the pre-existing knowledge.

What about me?

While discussing those aspects of restricting users, it quickly became clear that applying restrictions on yourself is perfectly valid. It is actually branded as “Digital Wellbeing” and similar on various mobile OSes.

Those who work in front of computers and have more control over their schedule will appreciate being able to restrict themselves and improve their health, focus, and productivity.

It is also interesting to see per-app usage:

It is not clear yet how a potential new Focus mode would interact with notifications.

Metrics

You might notice that those mockups require some sort of a metrics system that would monitor which app the user is using. This could range from a simple event logger to a sophisticated daemon collecting much more. Nothing is settled in this front, no decision was made yet.

Of course, privacy concerns were taken into account. There is absolutely no room for sharing this data. All data would be stored locally.

---

My attendance to the Parental Controls & Metered Data hackfest was proudly sponsored by the GNOME Foundation.