My blog is moving

Long time no see. My blog is moving, to be precise here. With the hope of starting to write more, and about more topics, I want to thank everyone who read my blog, which are way more people than I could have imagined, with the hope of seeing you again on the new one. And the promise of writing about what happened around my life, work, KDE and more over the next week, and after the Solid sprint.

This blog will, of course, stay up forever in case anyone needs to crawl back in my life. For what comes next, please head to http://freddi.me .

P.S.: I’ll be also writing in Italian on my new blog, from time to time. Scary, huh?

The notifications issue, part 3: the (possible) solution

Howdy,

welcome back!

Preamble about this series

This series will be structured in 3 posts:

• The problem – outlining what currently we don’t have or doesn’t work (all of this in my opinion) in KDE.
• The status – what have been others up to in this topic.
• The solution – a proposed solution to improve our system, based on the previous posts.

This is, guess what, part 3.

Preamble about this post

First of all, an obvious apology for the delay. Unfortunately, I got sidetracked by many other things, and this post kept being delayed for any possible reason. But, what matters is the result, isn’t it?

Then, I’d like to clarify the following: this post is mostly about the concept itself and the way the user and the applications interact with the notifications – I am not the best person to talk about UIs, as you might know. So yes, you will see mockups, but please refrain from commenting on the UI aspect because I am not even trying to modify it – their purpose is merely to showcase the concept and the interaction.

Last but not least, you might find yourself saying “this can be done with the current API as well!”. It is in fact true – however, consider that what we are trying to do here is not to find out what is currently wrong with KNotification and friends (see part 1 for that), but to create a full new concept which goes beyond the API itself. Everything else is an implementation detail which will be eventually sorted, either with a KNotification replacement or extension.

Ah yes one last thing: I am assuming you are familiar with my previous blog posts – I won’t re-explain pieces of terminology such as transient and persistent.

That said…

Notifications as a living object

A new API is meant to be used for taking advantage of this new solution. We are used to have notifications be a one-shot mechanism after which we simply forget about them. This can and should still be possible for the most basic case, but what we really want to have is a living object, which exists during the lifetime of the notification. The reason why is quite simple, and it’s one of the things I can’t stand in the various notification systems we analyzed in “the status”.

Suppose you have a “1 unread mail” notification. Instead of clicking on the notification itself, you open KMail, and click on that unread mail. What should happen is that the notification reacts and solves itself after the event has been triggered. This is the basic preamble for the rest: a persistent (transient notifications of course are just a one-shot trigger) notification should be made persistent inside the code of the application itself, and the application must actively interact with the notification.

Grouping for efficiency

Grouping is one of my favorite topics and of course it had to be in. At the moment, grouping is a massive fail and can be solved only in a single way: on the server side. Relying on application for grouping is not a great idea, and kills the concept of being consistent – especially because we can afford to group on the other side.

This kind of grouping I am about to discuss applies only to persistent notifications – a separate section for transient notifications will follow, since the rationale behind both is quite different.

There is one single thing the application has to declare: the types of notifications it will be able to spawn. And this is already there in KDE, in the form of notifyrc files. This allows our server to detect how many events of a specific kind we are going to get. In this regard, we are going to get a notification like:

The main question one could ask himself would be: how do I detect the text then? This is a problem which KDE already solved with i18np, for example, which allows you to give two options for a string, depending if the occurrence the string is referring to is plural or singular. An hypotetical API call could be:

CoolNotification *not = CoolNotification::newPersistent(IMApp::NewMessageEvent, i18n(“%1 sent you a message”, contact), i18n(“You have %1 messages”));

Disclaimer: not meant for real API usage.

The drill is quite simple though – this not only allows our server to stack and group the events efficiently, but also to display the right “singular” message if all notifications but one resolve.

Grouping for spamming

This applies to transient notifications instead. The “hypotetical API” and result would be pretty much the same, but the rationale would be completely different. Suppose 40 of your contacts come online at the same time, or your application fails 40 times in a row – I guess you don’t want to be notified forever. The main difference is that in this case we would group only if we detect spamming. For example, we would refrain from grouping if 2 contacts come online in 5 seconds, even if one notification has not resolved yet. The main purpose of this would be to avoid clutter.

Grouping for activities

Some of you already predicted this – yes, I believe activities can really help in the way we perceive and interact with notifications. Let’s get back to our previous API call:

CoolNotification *not = CoolNotification::newPersistent(IMApp::NewMessageEvent, i18n(“%1 sent you a message”, contact), i18n(“You have %1 messages”));

Now, imagine CoolNotification was smart enough to tell the main server that the application sending that particular event belongs to a particular activity. Or, let’s try even harder – suppose your application does not belong to an activity but your contact is. Maybe the API call might look something more like

CoolNotification *not = CoolNotification::newPersistent(IMApp::NewMessageEvent, i18n(“%1 sent you a message”, contact->name()), i18n(“You have %1 messages”), contact->activity());

Now, let’s assume you are working hard on a project you have to deliver tonight. And contact happens to be your girlfriend/boyfriend sending you some “<3<3<3<3<3<3” over Facebook. Ok, maybe not now. BUT. Your partner is actually associated with your “Leisure” activity, while you’re hard at work in your “Work” activity. What if you got something like that:

Not only – you would get a “reminder” just once. What happens when you click on the notification then? Your context is switched to the “Leisure” activity and the notification is expanded onto the grouping you would instead expect and we described before. And what about transient notifications? In this case, we would simply discard all the transient notifications which have spawned on other activities, as Facebook taught us in the previous post. In fact, I doubt you’d be interested in one of your friends coming online, but you might be in case your boss logs in onto your company’s jabber.

Grouping for backlogs

One of my favorites. Just like any other social network does, we want to keep a backlog of events. As such, we can easily “roll back” to an action we wanted to undertake before (or we actually undertook) and revise it, or do it again – such as reading a mail or talking with somebody. This requires some work in designing the API and for enabling application, but for sure it would be desirable to have something like this:

Integration with the outer world

Aren’t you tired of having your notifications scattered around your browsers, desktops, and whatevers? What if your backlog looked something like:

A big challenge would be trying to integrate all of your events into a single source – your notification area. Is this another step towards the “social desktop” and web integration? You betcha.

Integration with the inner world

Of course, it is important to integrate the other way round. Up to now, my mockups might have tricked you into believing that notification == bubble in some corner of the screen. But that’s very far from my plan.

If you follow my various work in the open source realm, you also know my commitment and passion to the Telepathy project. Telepathy has the peculiarity of being completely modular, by having a channel dispatcher (mission control) and a set of channel handlers. This means that whenever a specific channel request is received, mission control takes care of choosing the most suitable handler between those available.

Why is this relevant? Because I plan on porting the concept of dispatcher+handlers to the notification world. Let’s suppose for a moment that we have 2 main components: the notification server, as our dispatcher, and the notification applet, as the “fallback” handler. Now, every application can register itself to the server via DBus as a handler for a specific set of notifications:

int handler = CoolNotification::registerHandler(this, TypeList() << “newmail” << “error” << “etc”);

CoolNotification::setHandlerActive(handler, true);

Why setHandlerActive? For example, we might want to have our application acting as a handler only when it grabs focus (this could be and actually should be automatic in the final API. But we are just trying to expose the concept here). Now, whenever our server detects a new notification of some kind, it will check if a specific handler is available before falling back to the default one (the applet). If so, the notification will instead be forwarded to the application instead of the applet, BUT it will still feed the backlog. This means, for example, that KMail could display a neat animation upon a new mail whenever it has focus, and save the user from a (in this case) useless bubble.

But there is more: what if rekonq or any other web browser could act as a handler for social notifications (see previous paragraph)? For sure new interesting means of interaction can be discovered here!

Interaction

I saved it for last due to the highly controversial topic. Before we start with this, let me do a preamble: as a clever friend of mine uses to say, there is no way to satisfy everyone, there is instead a way for pissing off the less possible people. And more than this, there is no right solution, but in the specific case there is a solution which in the end might integrate better than others.

That said, I strongly believe our future notifications should have no buttons, which means one single action: Interact (like we have seen in Google+). This because 90% of the cases we want to cover are satisfied by this specific paradigm. What about the rest, you might ask? It is true that some of the notifications we know (incoming call) require more than 1 action – the challenge is to find a way to make this irrelevant by having the application itself (call ui in this case) be able to cope up with a single action.

But there is more – think Active. In an environment like Active (or a mobile shell) we cannot afford to have a notification with more than 1 action, given that pushing a small button is out of discussion. As such, we want to find a mean of interaction which works well on any platform.

We might find out during the road that we were wrong, but up to know we really want to strive for having a single mean of interaction for every action.

What’s next?

Code! Of course all of this should be shaped into something real, possibly into a new framework. You might have more news shortly… who knows 😉

…and it’s over!

I hope you enjoyed this little series. Of course, your feedback, ideas and suggestions are much more than welcome in the comment box below. I will keep you updated on what is going to follow and when you’ll (maybe) be able to see all of this on your desktop, tablet and more!

The notifications issue – part 2: the status

Howdy,

welcome back!

Preamble about this series

This series will be structured in 3 posts:

• The problem – outlining what currently we don’t have or doesn’t work (all of this in my opinion) in KDE.
• The status – what have been others up to in this topic.
• The solution – a proposed solution to improve our system, based on the previous posts.

This is, guess what, part 2.

About the previous post

It was great to see interested comments and most of all actual replies to my questions. I want to clarify a couple things before moving on:

Some of you mentioned the existence of indicators, Colibrì and such. No worries: I know about them and of course they played a big role in my analysis. Though, I intentionally left them out of my problem analysis since they’re not a part of the stock KDE framework, and we want to aim for a solution which somehow “integrates” everything in one single place and API

I got some great answers to the “more than one action question”. Especially, several people agree on the “invitation” (I really like the name, credits to TheBlackCat) to A/V calls. We’ll see how they scale as we go 🙂

Also, Celeste pointed me out a usability study she is promoting targeted towards finding out how to make the notification system better. Needless to say this is also very helpful for the project you’re reading about, so I encourage you to spend some minutes of your spare time to help out. The link is above, but in case you read through it, here it is in its full glory: http://community.kde.org/Projects/Usability/KDE_Notification_User_Experience_Study

Preamble about this post

Those of you who might have come here getting ready to read a comparison between GNOME, Windows, Mac OS, etc. will probably be partially disappointed in seeing that my primary case studies actually do not belong to a desktop environment. Why, would you say, since this is what we’re trying to address? The first and obvious answer is that KDE is no longer “only” desktop, and needs a concept which scales. The second one is that (not even that) surprisingly, completely different appliances have the same needs and the same problems to address. After all, when you come to think about it, a notification is just… a notification.

WARNING: Long post is long.

Facebook

We will start by analyzing Facebook first. It is a great example in many ways, and a bad example in other ways, and we will now see why. First of all, let’s take a look at the basics. I guess all of you know the system fairly well, but I found a couple pictures which are especially valid for showing you what I want to show you:

Let’s start analyzing the picture. First thing we notice, Facebook is split in 3 areas: friend requests, messages, and other. First question – why the heck do I have a friend confirmation on my “other” stream? I’d expect all friendship-related activities would go in the “friend” area.  There is a reason for that, though, and it makes sense to me. Also, you might have noticed that this screenshot is from an old version of the system – intentionally. I want to try to focus on the differences and on the evolution.

Now, notice the left bar. We see that we have Messages and Friends again. Does it make sense? Why is that? To be honest this is a part I don’t like, since it’s a duplication of information, but it helps in proving a point: friends and messages are stuff on which you want to take an action, which might be delayed, but still needs to be undertaken. On the other hand, you can disregard and not be reminded of the fact that $GUY is stalking your pictures.

This is a child of the “transient vs. persistent” issue. In the web world, the concept of transient notifications almost doesn’t exist after all, but here we stepped over a similar principle: prioritization. Facebook clearly tells us that some events are more important than others, and should be considered in a different way. Coming to think about it, isn’t that also partly true for your desktop?

But the reader might now think: then maybe the whole transient deal is just bul^Wcrap. Not really – the reason is that a web application such as Facebook cannot really have such a concept since it acts in a disconnected way most of the time. But in that list, for example, I’d rather not have a persistent notification everytime someone “likes” my post. Ok, it sets my ego on fire, but it can become annoying. That’s a case where probably a transient notification would have cut it better.

But, let’s move on with our analysis.

Ok, that’s something more recent. What changed? The first impact would say “The picture on the left”, which is correct. But to me there is something much more important: grouping. Notice how before we had a notification about “X commented Y”, whereas now we have “X,Y,Z and other stalkers commented W”. There is also something else which gives grouping even more sense, you can notice it on your account: a small “x” icon on the top right of every notification. I understand it’s not really discoverable, and also its purpose is weird: if you hover on it, you’ll see a label “Unfollow”. In fact, clicking that button will simply stop giving you notifications about that specific post.

This is quite awesome in my opinion – not really for the feature itself, which I consider quite undiscoverable and barely useful for most of the audience (probably the reason of its discoverability), but for showcasing the power of grouping. Not only I will get one single notification for any event happened in a particular stream, but I also have a single entry point for deciding not to be notified of a particular stream anymore. In particular, there is something really significant here if you compare this approach with messaging: we are now used (thanks to mobile phones which now find fancy to arrange SMSs by conversation [yes I know threads existed before that but I’m considering what IMHO made them mainstream</hipsterism>]) to consider messages in the context of a thread.

Slowly, we are starting to consider events in a thread as well, where a starting point (in this case, a post) leads to a chain of events belonging to the same thread. To counter the obvious “posts can be considered behaving as messages”, sharing notifications and like notifications work in the very same (threaded, grouped) way.

Also, this leads to a MUCH lower number of notifications, and *uh oh* introduced somehow transient notifications in Facebook! If you notice, now everytime a notification enters your stream, you get a nice bubble on the bottom left, sitting there a couple seconds. The behavior of this thing is really interesting and worth a study.

This picture is good enough for showing you what I am talking about, but not for proving my point in its entirety. Suppose a new event happens, $GUY comments a picture of yours. The bubble will appear and a notification stacked. You can directly take the action by clicking on the bubble itself, including discarding (the X is much more discoverable here, imho). In this case, the notification will disappear. But there’s more to that, and here comes the concept of a transient notification.

Suppose you weren’t at your PC, you come back and you see a “1” in your “other stream”. Now, another guy comments. The same bubble appears, the notification is grouped, but “1” remains “1”. This is as close as a transient notification can get, since you will just notice 1 notification if you weren’t in front at your PC, but you would have witnessed a whole stream of comments if you were sitting right there, and you could have taken action on any of them. Instead, the “root” notification will just bring you to the first unread comment.

Also, the “x” in the bubble behaves in a very different way: instead of unfollowing the related stream of events, it simply “silences” the notification.

Enough with Facebook? Not yet, there is one last thing.

I am sorry I couldn’t find a better picture, but as you know the notification area looks exactly the same as this screen. What is weird? Yes, interaction. We’ve seen how Facebook is keen on having us clicking the notification to pursue an action, but here we have 3 choices:

• Look at his profile
• Accept
• Reject

I think it’s bad. It’s really inconsistent with the rest of the interface, and kind of breaks the paradigm we’ve seen in the rest of the system, which in my opinion remains really good.

Google+

Google+ notifications are a very good case study for tackling the two weird things we found in Facebook: the separation between events (G+ has a single notification area) and the interaction. Let’s see why.

First of all we notice two obvious things: the grouping is even more aggressive: the “Friend” area of Facebook has been shrinked to a single grouped notification (this is closely related to how interaction works). Secondly, the layout helps the impression of grouping by showing a visual feedback of roughly how many events the notification refers to (by showing a set of pictures, or a “stacked” set of pictures). But the way one interacts with notifications is probably the most interesting part of G+:

Clicking on a notification brings up a full interface to the event that notification would have led to. This solves in a very interesting way the issue with interaction. Usually, the chain of arguments is that you need more than one action, you need a lot of them since otherwise the problem would be made worse, as instead of having one clear thing to do, you would have to cope with a downscaled interface for making your choice. There I fixed it: now you simply have your whole interface to deal with. But when we port this to our case (KDE), we should ask ourselves: is this that much different than opening a new window?

My answer is: not that much. The reason why people like this approach is that their workflow is not interrupted in any way – they can check out the event, maybe even reply to a message, then they can close the notification area and – bang – back to where they were. In a way, we can say that every G+ notification has one single action: “interact”.

Bored with all this social crap? Time for…

The N9, or: the mobile world

I am intentionally considering only the N9 since it’s the only smartphone I know really well (since I use it daily). I won’t be as long as before, since many things are just the same as before:

• The N9 groups events: you get a single notification about having 5 sms incoming
• The N9 does something very close to Facebook about transient/persistent notifications: you get the equivalent of the “bubble” which is instead a small banner on the top of the screen. The behavior upon clicking/stacking is exactly the same
• The N9 allows a single action a-la-G+: when you act on a notification, a full interface is brought up for you to choose how to interact with it.

There are, though, a couple really interesting things in the N9. Let’s have a look at them.

Oh, how much I love this. The notifications on the lock screen really just cut it when I check my phone for events. And what about swiping on them to activate the notification itself? Just amazing.  This really shows how it is possible to make notifications an integral part of your experience when you are “offline”.

I am really sorry I couldn’t really find a picture for the next thing I want to show you. Some of you might know the N9 integrates its notifications with Facebook ones, basically showing notifications from Facebook as native. The interesting part here is that the grouping happens in a completely different way. A typical example of notification you might get is:

• 3 new notifications
• 4 new messages
• 15 new friend requests

Whereas for the “global notifications” it doesn’t really make sense, it is really interesting to see that the “new friend requests” grouping is incredibly close to G+ as a concept, and acts in the same way.

Differences

Those three cases quite cut it in my opinion, and really help in showing mutual similarities and differences. In particular, we’ve seen how G+ tackled the concept of notifications in a way which is really close to the mobile world: a notification opens an application. Sure, the interface is different, but the principle remains – instead of giving the choice of taking a stock action, it leads you to a richer interface in case it’s obvious that you might want to undertake more than one choice. Facebook does this when it comes to messages and posts, but fails in applying this concept to friend requests – probably on purpose.

Recap

So what did we learn today? That the outer world already found several possible solutions to the problems we have previously outlined, and somehow faced most of the challenges we are up to. The circle is about to close with the next blog post, where I’ll try to gather what we learned up to now and try to come up with a concept which might, eventually, become the guideline for a new notification system in KDE. While you’re waiting, are there any other existing notification examples you’d like to point out? And thanks for reading until here, that was indeed a long run.

The notifications issue – part 1: the problem

Howdy,

I will skip the obligatory wrap-up with where I’ve been and what I did, since it would be random boilerplate you are probably not interested in. Instead, I want to start a small series of blog posts about the status of notifications.

Why?

I didn’t wake up this morning with the idea – I am cooking this since several months instead. I’ve been talking extensively about this during the Workspace sprint in Barcelona, had some quick chats at Akademy, some others with some of the Ubuntu Designers at UDS, and more. Let me get this straight from the beginning: this is not really about the appearance or the technical implementation: this is mostly about the concept of notifications itself. But let’s start analyzing the problem.

Preamble about this series

This series will be structured in 3 posts:

• The problem – outlining what currently we don’t have or doesn’t work (all of this in my opinion) in KDE.
• The status – what have been others up to in this topic.
• The solution – a proposed solution to improve our system, based on the previous posts.

This is, guess what, part 1.

Preamble about this post

Some readers might say: “hey, you’re outlining problems which we have in KDE that $STUFF already solved”, and in fact they’re right. I’m not ranting even here, I am just trying to approach the issue one step at a time. The solution I want to propose is a mixture of my own ideas and already existent solutions – this is why I want to try to be as clear as possible starting from the very beginning, which is finding out why we need something better.

What is wrong about notifications?

This question probably has a gazillion answers which might all be right or wrong, but I want to try and focus on a specific thing before anything: purpose. Let’s consider a number of use cases:

• A file transfer finished
• I received a new mail
• A friend got online
• Somebody sent me a message on IM
• My battery is running short
• An application encountered a non-critical error

What is the question here? Hypothetically, the first one which might come to one’s mind might be “Do I want to be notified?”, which is sensible – I have been asking myself this question quite a number of times. But we’ll get to that later. Another question, which is the one which bothers me the most, is “How do I want to be notified?”. I didn’t mention those use cases by chance – in my opinion (but I think this might be applied to many of my kind readers) there are very different ways in which those events should be displayed. I often get very annoyed by the fact I don’t have a way for interacting sensibly with my events.

Transient vs. Persistent

This is what I usually call the “transient vs. persistent” issue. Supposing I’m away from my laptop, if a friend of mine goes online or an application warns me about, let’s say, “connection dropped”, I sure don’t want to have a reminder about this when I get back to my PC. Although, I’d like to have a way for knowing that I got mail and a friend contacted me.  At the moment, this is something we completely lack.

In my view, a notification should ease the workflow, not interrupt it. Easing the workflow means allowing me to quickly reach to the actions I need to undertake (such as reading an [hopefully] important mail or message) and not being bothered by stuff I don’t care about. Persistent notifications are probably the most obvious way to separate “todos” from “stuff that happened”. Which somehow links us to another problem…

Spam

Yes, spam. When an application goes totally crazy and starts spawning a number of notifications bothering the user and possibly your CPU as well. When I’ve been talking about this problem with some people, one of the first answers I got was “well, fix the application then”. Here’s why, in my opinion, this won’t work:

• You cannot fix every application out there
• At the same time, an application can be designed in a way such an event happens due to some unforeseen circumstances. Implementing a “spam control” on an application basis means introducing complexity just for the sake of notifying the user.
• The definition of “spam” itself is quite tricky: having a serious HIG saying “you cannot stream more than x notifications every y” is very hard to follow for everyone, and applications might decide to go for their own “spam control” with their custom rules.
• In general, this could be summarized with: “Letting the application handle that means introducing new complexity at the risk of sacrificing consistency”

This is why I strongly believe the notification system itself should be capable of handling correctly this case.

Interaction

There, I know you’ve been waiting for this. It’s likely the most controversial topic when talking about notifications, on which everyone has his own ideas. The very reason why I’ve not been talking about this before is that I wanted to show that this issue is strictly linked to what I said above. You might in fact find out that in most cases, persistent notifications require interaction, some transient might suggest an interaction, some transient can’t even do that. Let’s analyze our previous use cases in this light:

• A file transfer finished (transient) – I’d say no interaction, one might go as far as “open target folder/file”
• I received a new mail (persistent) – Open that mail
• A friend got online (transient) – Suggest to open a chat with him
• Somebody sent me a message on IM (persistent) – Open that chat
• My battery is running short (transient) – Not much I can do with that
• An application encountered a non-critical error (transient) – Same as above

As you see, there is a pattern there – it’s not by chance that interaction is required specifically by persistent notifications – as I said before referring to persistent notifications, they need to “reach to the actions I need to undertake”. But besides that, there is another interesting story here – you might notice that every notification only allows for one obvious action (apart from “discard”, which is a different business). Exercise to the reader: can you think about a concrete case (not a weird corner case) in which a notification might need to suggest more than one action? (as I said before, discard doesn’t count as such).

Context

It’s quite hard to find out if a notification has a context or not. If I’m working hard and I don’t want to be distracted, I sure don’t want that friend of mine telling me “OMG LOOK AT DIZ VID LOL”. My fault in the first place for leaving my IM open, but this happens so many times. This part of the problem is not really specific to notifications, which is just a small part to the bigger issue. But it is true indeed that the next step after solving the persistency of notifications would be solving the conflict of notifications not belonging to your current context.

Wrap up

There is indeed room for improvements. Where do we go from here then? If you’ve been following me, we need a system which is capable of bothering us as less as possible, while “remembering” us what we need to do, and allowing us to interact in a sensible way. Does such a system already exist? Yes and no. I guess this will be food for part 2, though.

In the meanwhile, why not dropping a comment about how you like the initiative, and what are your feelings towards the problems I explained? Maybe I missed something obvious? Discussions welcome. Until then, see you for the next part.

The quest towards trusted client applications: a rambling

Some of you are surely aware of my work with PolicyKit and my efforts on making privilege escalation in KDE/Linux easy and accessible. The final result of my efforts was KAuth, now part of kdelibs. Although, since quite a lot of time I have been wondering on how to improve the whole escalation/trust experience, also covering a part of our middleware which is still not quite there.

One of the main issues in a Linux system at the moment is that we are not capable of identifying and ensuring that a client application *is* actually the application we are expecting. Anyone can fake a DBus service on the session bus, same goes for the process name and much more. This is also one of the big pitfalls of Polkit – as much as the authorization is guaranteed to be unique for each client, there is no way to determine if a specific client is *actually* supposed to execute a specific action or not.

These days I am at UDS, and I have been talking about the subject with Alex (Fiestas) and others quite extensively, thinking about a potential way of fixing it. It is not an easy topic at all and the solution is anything but obvious. We came to consider the following points:

• A client application should be “signed” somehow against a central trusted entity
• This trusted entity should be managing the authorization towards both privileged and unprivileged actions

This design aims to solve several problems beyond privilege escalation – namely, API access restriction. A very good example is inhibition. At the moment, any application can decide independently to prevent suspension on your system, making your laptop fry if it persists throughout the session. In an ideal world, we would like just a set of “trusted” applications to be able to execute that API. Of course, the concept of a trusted application can either come from the distribution or the user – we don’t really care about this. What we really care about is determining that a specific application IS actually the application we expect it to be, and that it has a set of specific privileges.

So our central “trusted” entity, ideally a daemon started in a way in which it could not be easily faked (I guess systemd might help here), would take care of being a central policy handler for several userspace features and applications. The main problem in this design is how to implement the signature check for each application, and how to make sure the application only can advertise its own signature. This is the solution which seems the most sensible to us at the moment:

• The application gets installed through a package management system
• A post-installation hook creates a user named after the executable of the application itself, or in a way which is easily identifiable by the application.
• The same hook takes care of generating a key pair for the application. One key gets stored in a location accessible only by the newly created user, the other is stored in the database of the central trusted entity and is associated uniquely with the application (inside the central daemon)
• The application would be a setuid executable. This way, it can escalate back to its original user for the signature handshake process, and get back down to the caller for everything else. This should not be a treat to security as the only privilege of the “special” user would be accessing that specific directory.
• This way any malicious application without root access would not be able to fake its identity towards a “trusted” client application
• Of course, this implies that only the package management tool and a developer tool should be able to create new certificates inside the central entity. Which would be guaranteed via the very same mechanism. Of course we start from the assumption that the OS installation is not compromised, which is sensible.
• Before you complain about the bootstrapping phase, here is how it works. We assume that the package manager will be always installed first. Upon package manager’s installation, the package manager installs its own key (no need for its user, since it always runs as root anyways) into a known path. When the central trusted entity is installed, during the installation phase it self-installs the specific certificate into its database, trusting only the package manager in the first place. This way the system is ready to perform other certificate installations.

I would love to hear opinions on this before we can start working on a proof of concept approach and see if all that we said is somehow feasible. Do you see any flaws? Any obvious things we’ve missed? Any ideas for doing what we planned in a better/simpler way? Please discuss and let us know.

News from Akademy 2012

Howdy,
at KDE, we’re always busy on several things – this is the time of the year where we are putting most of our organizational efforts into Akademy. In particular, a couple weeks ago me and Claudia joined Laur in advertising Akademy in Tallinn, and I held a workshop at the IT college about KDE/Qt development. Everything is shaping up nicely and the location seems really cool – you can indeed look forward to one of the best Akademy events ever! The three of us also did a quick interview for the local community, which is on YouTube, if you want to take a look at it.

Are you attending Akademy?

Hopefully you are, in case you are not, you definitely should. Supposing you are, PLEASE REGISTER SOON! The conference seems to be far away, but July is much closer than it seems. We need to know how many are we to plan all of the events efficiently and to avoid running out of space and resources. So register soon, register early, register here. As always, the registration is free of charge – if you are a professional attendee though, please consider registering as a professional. The registration fee you’d pay in this case will help us in organizing the event and add resources to our pool.

Book your accommodation!

July is going to be a busy month, and Tallinn is going to be the place to be for its first week. This means there is a shortage of rooms already, so don’t miss out in booking your accommodation quickly to secure your bed. There are several suggestions here, you can spot the option which suits you better. Same goes for the flights – most of them will be packed during those days, and prices are going to rise very soon. So book early, book now!

What about you?

Unfortunately, this year I won’t attend the weekend because I have another commitment during those two days, so I won’t even be giving a talk, and unfortunately will miss out on some of the awesome keynotes which have just been announced :(. But this doesn’t mean I won’t be there – I plan to crash the party on Monday, so I can proudly say:

But just for the last 5 days 😦

Calling all artists, designers and users

Have you heard the last news from Aleix? We are aiming towards finding a new, concrete vision for our beloved KDE workspace. We already gathered a team of KDE superstars, we have had some preliminary discussion at Plasma Active sprint; there’s just one thing missing: YOU.

Thanks to Luca, Ben, and all the amazing guys behind the KDE Forums, I am honored and pleased to introduce you to:

The KDE Workspace vision forum

What is it? As Luca explains in the forum announcement, a new vision requires new ideas and new people. Do you think you have the best idea ever for our desktop environment? Is KDE4 perfect for you, but there’s that little something you can’t stand? Do you think you have got what it takes to show the world how YOU see the desktop environment of the future? Then indulge no further and start posting: developers will jump through this new forum frequently to take a look at your creations, comment on them and – why not – make them real.

This forum will hold posts, mockups and explanation of any new idea you could have. It doesn’t necessarily need to be over something new, or over something existing: just let your fantasy guide you – the more innovative your idea is, the better. Mockups are of course very welcome, and so is artwork: but if you just have a great idea for a new concept, we will be also happy to read through it thoroughly even if there are no nice pictures.

This project has just started, so don’t miss the chance to be between the first in posting your ideas. Are you ready to make KDE rock even more? We are, and we are just waiting for you.

Bits from Plasma Active Sprint and future events

Hello there. New blog post just to catch up with some happenings in the last days and future events. Never been very good at introductions, so:

Plasma Active Sprint

As you might have read already, I have been joining the Plasma Active sprint in Darmstadt. Besides having seen lots of old friends and meeting new ones, we’ve had very productive discussions over the future of Plasma Active and KDE in general. Me and Martin in particular have been thinking and working a bit on the concept of Account management and Metacontacts (a very old discussion we have had in KDE Telepathy multiple times).

One thing which became clear from these discussions was that we want to foster the usage of Akonadi and Nepomuk as much as possible, to avoid reinventing several wheels especially when having to store or cache data. Martin will probably propose a GSoC me and (hopefully) somebody else will mentor about all of this. We want to make KDE a desktop/mobile shell deeply integrated with internet services and this is just the first of many steps we will take. Surely interesting times are ahead of us if you are excited about this.

There have been also several other topics of discussion which are too long (and some maybe uninteresting) to be summarized in a blog post, but one thing is sure: KDE is much more alive and kicking than ever, and the future seems really something to look forward to.

Akademy Pre-Event

From the 26th of March I will be in Tallin, Estonia, with Claudia and the local organizers to have a brief pre-event of Akademy 2012. For the occasion, I will be holding a lesson/workshop on KDE/Qt development at the Estonian IT College, which is also going to be the venue of the event. Needless to say that if you happen to be there, try not to miss it! We will also take care of studying the venue to make sure Akademy 2012 will be among the best ever!

Google Summer of Code is on!

Teo already blogged about this – KDE has been (again) accepted as an organization for GSoC for 2012! For me it is a time I am always looking forward to – this year I have not one but two awesome potential students with great skills and great ideas, ready to make KDE rock even more. Do you think you got what it takes to be part of the great number of students that every year join KDE in submitting a proposal? Then look no further: we have a huge set of ideas, and we are more than happy to welcome yours (we know a lot of people with great ideas out there, and you are probably one of them. Don’t be shy 🙂 ).

If you are serious about your application, learn from your fellow students! Every year we get an incredible amount of outstanding proposals – and they’re so many sometimes we even have to reject them. So you want to be up to the challenge. The amazing Teo cooked up a great (and funny) blog post covering everything you need to write a kick-ass proposal. I consider it as a must-read for any student who is really committed to having his project accepted in KDE.

The application period will start in a week  – get ready!

Software

There’s amazing things coming up in our software as well. I’ll write about them briefly as they deserve their own post, when time will come:

• David blogged about KDE Telepathy 0.4. It’s going to be awesome.
• I have been through some modifications of KAuth for frameworks. Some changes are slightly intrusive, but guarantee some fixes and a much improved workflow. I will tell you more in a separate blog post in the next days.
• We are trying to get serious on the Accounts thing (see Plasma Active Sprint), and hopefully we’ll be showing some results soon
• And we are trying to cook up something for artist and designers who happen to use or like KDE. Stay tuned for that, news very soon.

Hopefully that’s enough for you to look forward to further updates 🙂

Fixing lid close suspension in 4.8.1

I never thought I would have dedicated a blog post to a single bug, but here I am. It has been quite an effort fixing that for good, but we made it, and I wanted to share some considerations we made while doing this.

Before I begin, let me say that bug was an incredible example of constructive feedback by our awesome users: we got plenty of relevant information in a ridiculous amount of time, so I want to thank anyone who replied and/or reported, and if you, dear reader, have an outstanding issue in your KDE desktop – this is a good example of what it takes on your side to get it fixed as soon as possible 🙂 But let’s get to the point…

The issue

Since 4.8, as you probably already know if you follow my blog, inhibition in power management got a significant boost all over the place, but most of all started to work as it should. In addition, we enforced a policy which considered a lid close action to be implicit. We didn’t consider, though, that many application implemented inhibition before 4.8, even if in fact the whole routine was broken in a relevant number of cases. Turns out that some of them were actually doing this wrong.

In addition, we found a bug in our RandR code for detecting multiple displays connected, which triggered a persistent inhibition throughout the whole session since a second display was always detected.

So, what happened in the end? Lots of users weren’t able to suspend their laptop when closing the lid, maybe even you reader. But we tackled down every cause and fixed them.

Applications

Unfortunately, there is no way we can predict whether an application will do its job or not – we can just trust them to do it right. The good news is that our awesome users found the cause in two applications – KTorrent and Apper. While for KTorrent the inhibition feature is actually configurable, so it wasn’t really a bug but a new behavior discovered, for Apper the case was different – a bug in the inhibition routine went unnoticed, and we fixed that. I heard Daniel just released a new version which contains the fix – needless to say upgrading is highly recommended.

KRandR

I am a bit sad about this since this was meant to be one of our killer features. Although, we had to face a number of problems with drivers and such when detecting a second display, as already mentioned. We managed to get to a point where most of configurations will be actually supported, and fixed a number of corner cases where inhibition was not desirable. However, in the end we will probably make this feature configurable, as some users also told us that having suspension inhibited in a multi-head setup is not what they want.

Explicit vs. Implicit

And here’s to the very root of the problem. Our power management system is smart enough to distinguish whether an event has been explicitly requested by the user, such as a button press, or it was an implicit decision from the system, such as an idle timeout. The inhibition mechanism is designed not to inhibit any explicit action, just preventing the system from undertaking an action when the user is not taking part in the decision. The reason why we considered lid as an implicit event was probably wrong, after the feedback we got; but it was mainly to prevent the system from going down when something important (software update) was going on.

Most of our users showed us that the expectation of a lid close is definitely to carry on the configured action regardless of what’s happening in your system, which is indeed something sensible. At the same time, some people were happy with the new behavior and provided some good use cases to prove this (for example, using the new applet checkbox to prevent suspension when closing the lid). In the end, my take was to make this kind of behavior configurable – in 4.8.1, the advanced options will have a checkbox which is going to define whether a lid close is going to be considered explicit or not. And by default, it will be considered explicit like in previous versions.

Conclusion (or TL;DR)

I am happy to say this annoying bug should be completely fixed in 4.8.1, and at the same time we managed to leave our users with a choice to make their PC behave as they think it should. I really hope for 4.9 we’re going to deliver a rock-solid KRandR+Power Management implementation and we’ll try really hard for that, even because that would be a neat feature for Active.

So, if you were affected by this bug and do not care about anything besides your PC suspending when your lid closes – all of this will be just a bad memory after updating to 4.8.1 without the need for you to do anything apart from the upgrade itself. Otherwise, you can restore 4.8.0’s behavior by going in the advanced options. And, in any case, do not forget to update any application which was misbehaving.

KDE Telepathy 0.3, KDE SC 4.8, let’s party!

What a week it has been. Not only I’ve had a few days of vacations in beautiful Australia, but two major events happened.

You probably already know that, KDE SC 4.8 has been released. I might be biased, but trust me – this release is amazing. I am especially proud my work on power management got the first page this time – it’s really a killer feature, and I really hope it will become a keeper and another great reason for using KDE for most of you.

But it doesn’t end here: KDE Telepathy 0.3 has been released. Now, as much as this event might seem less interesting, it has a very special meaning to me. KDE Telepathy has been the proof of how a group of friends can get together and build something awesome, while having a lot of fun.

The project is now in a beta state, meaning we’re almost there, and you can start checking out what’s boiling without fearing your PC will blow up in a billion pieces. Of course, we are still not advertising this release to be fully stable, but we do accept bug reports at this stage, and believe the basic features are ready to be tested. So, no excuse: together with your new shiny KDE 4.8, try the future of Instant messaging on your favorite desktop environment!

Assuming you are a developer, are you interested in what these changes will bring to your world? Well, you’d better be excited. A video is worth a thousand words, they say – then why not checking out my talk at linux.conf.au about creating social apps with Telepathy and Qt? And if you are wondering – yes, the code for the example is actually available on KDE’s git on one of my scratch repos (link coming later, quickgit seems to be unreachable at the time I’m posting). See for yourself how easy it is to make your application rock even more!

But, the most amazing thing happened when David started the beer fundraiser, to get us wasted at FOSDEM. Well, the response has been flattering: up to now we have raised something along the lines of 230€, which is enough to kill a couple elephants considering where we’re going. So thank you! Given this thing has gotten quite far, we’re adding some more rules to our small game, and we’ll rollover funds to any other meetings if we pass out before spending all of this money (likely). Want to have a nice picture to show to your kids of a bunch of friendly hackers lying on the floor or having lots of fun without actually doing anything of the usual activities they are supposed to do? You still have time to donate.

(apparently wordpress.com doesn’t like paypal buttons – please refer to David’s blog post for donating)

Thanks again everyone for your support, and I hope our new software will rock your world.