I could only be at the MIT for a few hours today, so this summary only covers the morning part.

Networking

We started the ‘Enterprise’ track almost on time, with a session on Enterprise Networking features. The NetworkManager team had been assembled at the Red Hat offices in the week before, so things were fresh in the memory of both Dans.

Dan Winship began this session with a demonstration of a network panel and shell network menu that showed VLANs, bonded connections and multiple network devices. Dan couldn’t carry the required HW to the summit to show off Infiniband connections showing up as well 🙂

There was some discussion of how bonds and other virtual devices should appear in the network menu. Should we show all the slave devices ? Would it be confusing if eth0 just ‘disappears’ when it is part of a bond ? The general consensus was: no, we don’t want to see details in the menu, administrators who want to see the details can go to Network Settings.

The discussion also touched on other topics such as overlap between virtualization and networking. NetworkManager currently doesn’t show anything about the tun/tap devices that libvirt sets up for connecting VMs to the network. If it does, would we want those to show up in the network panel ? I don’t think there was a clear consensus, but everybody agreed that it would be great for gnome-boxes to have ‘one-click network access’ and a very easy way to say ‘give this box internet access’ or ‘I want to ssh into this box’. See bug 677688.

Another question that came up in the discussion was how to deal with multiple connections for devices. One idea would be to have a list of connections, similar to how we now present wifi aps/saved connections. For wired, it is probably rare to have more than a 2 or 3 connections that you switch between, so maybe a full-page list is overkill. For 3g, the connections will often be location-specific, e.g. when you choose a different provider while travelling.

Dan’s patches will land in 3.7 soon.

Authentication and Smartcards

After a short break, we moved on to talk about authentication, and smartcards in particular. The discussion went into many corner cases and complications; I’ll try to sum up what conclusions I took away from it, maybe others can chime in and provide theirs.

There’s two basic scenarios where we want to support smartcards:

• Use smartcards when logging into your desktop, probably authenticating against a central server
• Use a smartcard to obtain a Kerberos ticket after you’ve logged in to your desktop

We had a long discussion over which of these use cases is more important and gets to be the 80 in the 80/20 split. At the end of the day, we need to support them both.

In the first case, when the machine is configured for using smartcards to login, we probably want to bypass the user list entirely and display a ‘please insert your smartcard’ prompt. When the machine is not exclusively used with smartcards, swiping the card while the user list is displayed should get you to the prompt for the pin to unlock the card. When a user is selected from the user list, we should be able to get a list of supported authentication method from SSSD, so that we can display a list of buttons similar to what can be seen in this mockup.

Querying the supported authentication methods will also be important for the second case, when creating an ‘Enterprise Login’ in gnome-online-accounts. Currently, we just ask for username and password in that dialog. When smartcards support is added, we should optionally allow the user to use a smartcard instead, and then also ask for the smartcard to be reinserted when the ticket expires and we need to reauthenticate.

One question that was brought up at some point in the discussion is: Should we include UI in GNOME to set up a machine for smartcards, or to enroll smartcards in a central server. The answer was an unanimous: no, we don’t need that. These are administrative tasks; we expect users in such scenarios to receive a properly configured machine and smartcard.

There are a number of expected behaviours in the session, when a smartcard is used to log in. The most prominent one is to lock or end the session when the smartcard is pulled. gnome-settings-daemon actually has a plugin that implements this, but it is fairly simple-minded: we either lock your screen, or force-quit your session right away. We should probably combine this into a single action, which locks your screen right away, but gives you some grace period where you can stick your smartcard back in before ending your session. There was also some discussion about what else should be ‘locked’ in this case. The keyring is an obvious example, but there may be others, such as an encrypted home directory.

The lock screen + force-quit after a grace period may overlap with support for time-limited session, which is something that we have wanted in gnome-session for a while.

Another question that was raised is: what about remote or virtual sessions, such as in gnome-boxes ? It can get access to a smartcard via USB redirection. If the card is removed, should the session just be disconnected?

At the end of this session, we took a little detour into discussion UX problems with our current system-modal dialogs. Too often, these pop up ‘out of the blue’, and interrupt the user who was typing in some window. Many cases were mentioned, all of which seem to come down to ‘the app shouldn’t do that’. We need to figure out use canses write guidelines for proper use of system-modal dialogs.

Privacy / Sharing

Jon gave a 30 minute presentation of the current thoughts of the design team in the areas of notifications, search, privacy and sharing. I don’t have URLs for his wireframes atm, so I’ll just give a brief description.

Jon described four new control-center panels.

The first one is about finer-grained control of notifications, on a per-application basis. It will allow you to say things like: I never want to see a ‘new mail notification from evolution again’, or ‘please show me chat notifications, but leave out the embarrassing details when the screen is locked’. This is a logical continuation of the current all-or-nothing switches we have for notifications (in the user menu) and for notifications on the lock screen (in the screen & brightness panel). The great thing about this is that it can be implemented entirely in gnome-shell, it doesn’t need any cooperation from the application side.

The search panel lets you configure what applications provide search results for display in the shell overview, and in what order they appear – this seems to be a frequent user request (‘I want to see recent chats before the contacts’). Only applications that install a shell searchprovider will appear in this list. More detailed configuration of where applications search (‘include $HOME/my-important-documents’ in gnome-documents search) and what results they provide will be left to application-specific preferences. One aspect of this that came out in the discussion is that we probably need some tracker extensions to let applications request a narrow view of only the files they are interested in. That is better than relying on apps to do the filtering themselves, both in terms of performance and in terms of privacy (as a small step towards being able to have ‘untrusted’ apps on your system).

The last two wireframes that Jon had are for Sharing and Privacy panels, but I’m out of space to describe them here, so I’ll just wait for somebody to post links to them.