1. 2019-03-18

What feature set do we care about implementing?

• Parental controls
  • Parent who has child at home: different levels of lockdown (child using the laptop with total supervision, unsupervised access, web filtering, access to install apps, parental auth to run apps)
    • Web whitelist: Richard’s child only has to access 3 websites (school homework website, 2, 3) — it seems a bit odd to even have an address bar in the Web app when this use case is happening
      • From the point of CDNs, etc., we might have to do integration directly with the browser rather than via a DNS blacklist or whatever
      • For a blacklist, we probably want to uses OpenDNS or something, as otherwise blacklist maintenance becomes a nightmare
        • Would need to prevent user changing DNS settings
    • Side note: Richard’s child has her own password?! Do we want passwords for kids? Or do we want to support something where the parent puts in their password to allow the kid to use the computer?
    • Common request would be to disable/prevent all social media integration in apps
    • Distinction between parental controls (restricting things) and a full-on user experience which is tailored for kids (comic sans, bigger font, different launcher, limited app list, etc.); this ties in with existing accessibility features
    • Time restrictions: limit by accumulated time, or limit by time of day
    • Do kids have their own device? In the Endless use case, the laptop ‘belongs’ to the child, with some initial setup step for the parent
  • You are an admin at a school: kiosk mode (very restricted)
• Digital well-being:
  • Time restrictions: when, how much
    • App *or* content based *or* categories-of-apps based
    • Or based on how much an app has notified you, or how much you have searched out an app
  • Self monitoring, ‘mindfulness’
    • Gentle reminder that you’ve been using an app for too long
    • ‘Dash board’ which presents an overview of which apps you spend your time in; allows you to see how long you’re using each app for, which can inform your decisions about time limits
  • ‘Wind down’
  • ‘Speed bumps’ for self management, to make some things a little harder for yourself
    • Blacklist websites; how do you override it
    • Impulse control
    • Android fades things to be black and white when you neeed to turn off your phone; make the restrictions adaptive
      • Ties in with the night light
  • Ties in with ‘do not disturb’ or ‘focus’ mode
• Note that elementary are going to ship their own UI for this regardless, so don’t need to converge with GNOME on that; only on the backend architecture

Trimming this down, which use cases do we want to support?

• Time restrictions
• Supervised vs unsupervised access of the computer
• Restricted access to installing apps
• Restricted access to running apps
• Website blacklist
• Content-based restrictions are desirable but not essential
• Do not disturb
• Gentle reminders and speed bumps from digital wellbeing

What do we think about adding dependencies, vs requiring flatpak, etc.?

• This has to work, at some level, for every distro which ships GNOME
• Call it ‘digital wellness’ (or similar) rather than ‘parental controls’ or ‘lockdown’ to manage expectations
• Lock down every place in the desktop where apps can be launched

• If a distribution does support AppArmor, or does predominantly use flatpaks, etc., then they can use distro patches to make it more bullet proof

• Argument: a 10 year old could just boot from a USB stick with a custom OS on and get whatever content they want; we’re not going to do Secure Boot, so this is all best-effort anyway
• We shouldn’t let this affect the UX significantly

Do we want to treat digital wellbeing and parental controls as the same settings?

• Supervised access is parental controls only
• Setting limits vs setting reminders is parental controls vs digital wellbeing (uncooperative user vs invested user)
• Disallowing app installation is parental controls only
• Supervisor passwords are parental controls only
• Some remaining question over whether parental controls is useful for someone who’s caring for (e.g.) a mentally disabled person; if so, should we call it something else? ‘Supervised account’?
  • ie. These controls are definitely useful outside parent–child relationships
  • But calling ‘parental controls’ does open the door to other child-friendly features, like bigger icons, friendlier font, etc.

What do we want to do for parental controls vs digital wellness? What kind of feature set can we support in GNOME, given the OSs we target? Open questions at the end of the day:

• Do we allow supervised users to additionally set their own digital wellness settings?
• What happens if you have a fluid schedule — e.g. my digital wellness settings would be based on when I’m at work and when I’m at home; but those periods aren’t strictly tied to wall clock hours

Monday timeline:

• Got the projector working
• Looked at use cases and high-level features

• We read https://www.theverge.com/2018/5/10/17333574/google-android-p-update-tristan-harris-design-ethics

• Looked at prior art from Android and iOS
• Started to pare down the feature list to what we want to prioritise
• Split up to work on and discuss things in pairs or so
• 16:30, had a call with Adam to discuss the elementary backend architecture, its current and future state
• Then discussed supervisor accounts vs supervised accounts, and what actually defines the role of an administrator

2. 2019-03-19

Tuesday timeline:

• Quiet individual hacking and conversations in the morning
• Philip talked to Florian about the gnome-shell patches which Endless have already
• Made a list of the various low-level integrations needed and worked through how to implement various of them

  • logind/pam_time integration to put time limits on sessions: https://github.com/systemd/systemd/issues/12035

  • Website filtering: we need to be able to provide feedback to the user, and to allow temporary override access to websites, so it has to be implemented as a plugin in the browser, rather than as a DNS resolver or proxy
• Lunch
• Allan gave a walkthrough of the design mockups he has just produced
  • We need to store application usage data in accounts-service, add support for append-only data to accounts-service; otherwise the supervised user can overwrite their usage data, or the supervisor user can’t read it out of the supervised user’s encrypted home

  • Need to respect org.gnome.desktop.privacy:remember-app-usage

  • Need a separate supervisor password (not just authenticating with a password from any admin) for the use case of a babysitter, or a teacher who doesn’t have local admin rights
  • Treat websites as high-level objects the same as applications, for blacklisting and scheduling and (if Web can be made to support it) usage monitoring
• More quiet individual and small-group hacking later in the afternoon

3. 2019-03-20

Demo of metered data:

• Allan wants to be able to disable automatic updates, even if not on metered data; wants control over when his computer is updated
  • Suggestion is to keep settings dialogue in gnome-software, and use it to measure the user’s global preferences, vs. the per-connection metered schedule
• Metered data is currently exposed in the interface as ‘automatic updates’ purely because that’s where we’ve implemented scheduling support
• What other applications do we want to pay attention to metered data by default?
  • Transmission
  • Evolution downloading attachments
  • NextCloud/Dropbox/OwnCloud
  • Large file downloads in the web browser
  • GNOME Music updates for podcast episodes
  • Builder downloading runtime updates
  • Backups doing networked backups

  • FeedReader doing feed updates

  • Contacts and Calendar syncing things
• Do we want to schedule OS update metadata downloads, or just do them unconditionally?
• Monitoring: how close am I to my bandwidth limit? How much is this download/action going to cost me? We can easily look at the per-connection bandwidth consumption so far, which already gives you
• Do we want system-level (shell) notifications for things that are in progress, such as downloads or file copies?
• Do we have data on what apps use bandwidth, and how much they use?
• In the case of large web downloads, the issue is not scheduling the initial start of the download, but the fact that the download could run for a long time, across several different metered/unmetered network connections
• Some questions about progress reporting and whether we could have a GNOME download progress API which reports the progress of all scheduled entries
• Start to look at control center UI flow, from the point of view of adding a new network connection and marking it as metered
  • Allan would like to look at redesigning the control center panel so it fits in better with the 3.32 network panel design
  • ‘Cap me at 4GB per month’ or ‘Cap me at 4h after I first start using the internet’
• Rob to hunt down and find Endless’ research on different network tariffs, and make that available
• Rob, Georges and Allan spent some time looking at Endless’ existing UI designs for the control center
• Difference in behaviour for downloads which are small on a metered connection vs downloads which are large; e.g. my e-mail client should ask me whether to download images in an e-mail if I’m on a metered connection, rather than putting this through the scheduler; the downloads are too small to worry about scheduling

Wednesday timeline:

• Demo of metered data and discussion about it in the morning
• Quiet individual/small group hacking
• Lunch
• Quiet individual/small group hacking
• Philip prepared a questionnaire to send out to try and gather more information about different common metered data connections and interactions
• Discussed review of gnome-software patches to support metered data

4. 2019-03-21

Discussion about time series logging of metered data, and signalling that you’re reaching your limit of data usage:

• What component should notify the desktop that you’re near your global cap for metered data (across all applications)? While the scheduler can prevent new big downloads from taking place, a small (unscheduled) download could tip you over the edge, and the scheduler couldn’t prevent that.

  • NetworkManager could emit a notification, since it already tracks the kernel’s global rx/tx limits; but that would mean it would have to access the accumulated total of those, since it currently doesn’t store that persistently

• Looking like a shared system time series data implementation would be useful
  • D-Bus activated system service which exits after a short period of inactivity
  • Logs time series data per app/user/connection/whatever other keys the caller provides
  • Allows unprivileged writes
  • Allows unprivileged reads by the same user
• Getting IP accounting working for session apps depends on systemd user sessions, which Iain has been working on over the last few days

Thursday timeline:

• Quiet individual/small group hacking in the morning
• Lunch
• Some discussion about time series logging
• Georges demoed (unrelated) work on profiling gnome-shell frame deadlines visually