planetubuntu – bits and bobs

Canonical’s Desktop Team is hiring

edit: this post is fairly old now, and we’re well on the way with the rest of the process – if you didn’t apply yet, it’s probably worth waiting until next time

Some good news for anyone who might read this. In the Canonical desktop team we’re hiring a new Software Engineer.

More details in the job description, but if you’re looking for an opportunity that lets you:

work remotely
work on GNOME and related desktop technologies (both upstream and downstream!)
help to ship a solid Ubuntu every 6 months
work with smart people
have the opportunity to travel to, and present at, conferences and internal events

then please apply. You do not need to already be a GNOME or a Ubuntu/Debian expert to apply for this position – you’ll be given a mentor and plenty of time and support to learn the ropes.

Please feel free to contact me on IRC (Laney on all the best networks) / email (iain.lane@canonical.com) / Telegram (@lan3y) if you’re considering an application and you’d like to chat about it.

Parental controls & metered data hackfest: days 3 & 4

no nice picture this time, sorry 😭

Following on from the first two days, we in days 3 & 4 we moved on to talking about metered data. There’s some debate about whether this is the correct terminology to use, but that’s the title of the hackfest so I’ll stick with it for now.

This is a set of features to handle internet connections that have limited amounts of data in some way. For example, I’ve personally got a “MiFi” mobile hotspot that provides internet over the 4G mobile network. I bought a pay-as-you-go SIM card that provides 32 GB of data, and when that’s used up I’ll have to recharge it to be able to get online.

Philip provided a summary of the current implementation in Endless. You can also watch a YouTube video of a talk Philip gave on this topic at GUADEC in 2018. Briefly, this is an opt-in system. The system knows details of your tariff, some of which you can provide in Settings, but which may also come with the system – for example if it’s sold with a mobile network connection already provisioned. Applications ask a new component for permission to begin a large data transfer, and this component tells the application when it can begin the transfer. This could be immediately or later on.

We reviewed prior art (other OS implementations), and had some discussion about types of metered connection that you might have. This turns out to be very complex! Some providers offer plans which come with “N hours” or “N bytes” restrictions. Others exempt certain websites from metering entirely.

Another topic is logging of used data across different applications. systemd has features to log the network traffic of units, so once we have proper support for using systemd to start desktop applications, we can begin to track this and then think about how to expose it in the UI.

I was personally arguing for somehow tracking the global amount of network traffic (tx/rx_bytes), so that the shell can tell you when you are approaching / over your cap. My feeling is that this would require some integration with NetworkManager, but we would need to work out the details of what to track – total bytes isn’t good enough; you would at least need bytes per day/week/… to implement support for some types of metered connection.

Finally, if you’re reading this through Planet GNOME then you’ve already seen, but Philip created a survey that we would like to use to help guide future developments. Go fill it out please.

Parental controls & metered data hackfest: days 1 & 2

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.