I’m currently at the Parental Controls & Metered Data hackfest at Red Hat’s office in London. A bunch of GNOME people from various companies (Canonical, Endless, elementary, and Red Hat) have gathered to work out a plan to start implementing these two features in GNOME. The first two days have been dedicated to the parental control features. This is the ability for parents to control what children can do on the computer. For example, locking down access to certain applications or websites.
Day one began with presentations of the Endless OS implementation by Philip, followed by a demonstration of the Elementary version by Cassidy. Elementary were interested in potentially expanding this feature set to include something like Digital Wellbeing – we explored the distinction between this and parental controls. It turns out that these features are relatively similar – the main differences are whether you are applying restrictions to yourself or to someone else, and whether you have the ability to lift/ignore the restrictions. We’ve started talking about the latter of these as “speed bumps”: you can always undo your own restrictions, so the interventions from the OS should be intended to nudge you towards the right behaviour.
After that we looked at some prior art (Android, iOS), and started to take the large list of potential features (in the image above) down to the ones we thought might be feasible to implement. Throughout all of this, one topic we kept coming back to was app lockdown. It’s reasonably simple to see how this could be applied to containerised 📦 apps (e.g. Snap or Flatpak), but system applications that come from a deb or an rpm are much more difficult. It would probably be possible – but still difficult – to use an LSM like AppArmor or SELinux to do this by denying execute access to the application’s binary. One obvious problem with that is that GNOME doesn’t require one of these and different distributions have made different choices here… Another tricky topic is how to implement website white/blacklisting in a robust way. We discussed using DNS (systemd-resolved?) and ip/nftables implementations, but it might turn out that the most feasible way is to use a browser extension for this.
Adam Bieńkowski joined us to discuss the technical details of Elementary’s implementation and some potential ideas for future improvements there. Thanks for that!
Today we’ve spent a fair bit of time discussing the technical details about how some of this might be implemented. Given that this is about locking down other users’ accounts, the data ought to be stored somewhere at the system level – both so the admin can query/set it, and so that the user can’t modify it. Endless’s current implementation stores this in AccountsService, which feels reasonable to us, but doesn’t extend well to storing the information required to implement activity tracking. Georges and Florian have been discussing writing a system daemon to do this, which the shell and (maybe) browser(s) would feed into.
More detailed notes taken by Philip are available here.
For the next two days we will move to talking about the second subject for this hackfest – data metering.