 Hi, I'm here to talk about a feature that we've been working on within Endless and the wider GNOME community over the last year or so, based around parental controls and digital wellbeing. So essentially we want to be able to limit the amount of time that your child or whoever, generally we use child for example, can use the computer or use a particular app or the apps they use or which times of day they're allowed to use it for and you can then translate that from enforcing it on a child to sort of advising it on yourself like for example I shouldn't be allowed to use the computer after 1am because it's always a bad idea and I want my computer to be able to tell me that because I never look at the clock. So that's what we've been aiming towards. As part of this we need to work on system D and add support for time-limited login sessions. So we did that by adding that to the scope unit in system D where the runtime maxec property which works just like for service units. So if you set that on a scope unit after that amount of time it'll get a sig term and everything in it will die and if that doesn't happen then sig kill will happen. So this works because the scope unit is used for a login session so if you apply that limit to the scope for a login session the whole session will be killed after 2 hours of use or whatever limit you set and then we've added the same parameter to the system D PAM module so that if some other module in the PAM login stack sets that the limit will then be passed through to the login session that's created as a result of login and so you can have a PAM module which enforces your limits and also which stops you from login if you've exceeded your limits earlier in the day. So with that done what's next we need to store how much time you spent in your session, how much time you spent using different apps over the last week or day or whatever period you want to calculate it and force it over. We need to implement that custom PAM module that'll set the limits and force that on login and the session end and we need to move to using system D user sessions in production because that gives us scopes for apps and more control over applying these limits to individual parts of your system. And we need a way to store all of that data and use it to inform the policy decisions and also to provide you feedback in the form of graphs like this. This is a mock-up that Alan Day did about the digital well-being side of things so the kind of keeping track of yourself rather than enforcing things on your kids but you can see this scope for providing you feedback about how much you've used your system over the last days or months or whatever. So with the system D side of things it's quite a general approach just adding this new properties to scope units so it could allow many other things to be implemented in context other than the desktop. So we've got a pair of look at odds, we've got digital well-being but you could use it for terminating scopes of processes that you don't quite trust to finish execution in a certain amount of time. For example continuous integration systems where tests might overrun or hang and you want to just kill them all after a certain time limit or you could use it for a kiosk mode if you want to allow someone to use a computer in a public place for up to half an hour or whatever and then after the half hour they get knocked off. There's many different options because it's quite general and that's it. A lightning talk. There's some links there and I'm happy to talk about the future with anyone if you want to catch me afterwards. Thank you.