An interesting presentation on  design criteria for social web sites, with discussion of how the multiple facets of identity are not supported in most online social networks.  The presentation is interesting both from the directly applicable design of groups/roles and the discussion about how to handle attributes and information flow within social web sites.

At the same time we see an interesting uptake in the use of social web sites and channels to discuss (and cut the lead time of scientific discourse) things like Analysis of Vinay Deolalikar’s recent preprint claiming to prove that P != NP.

SURFnet published a video on how the Dutch research network is proceeding with its innovative Collaboration Infrastructure project COIN.  This work is a synergy of federated identity, social networking and collaboration tools.


A precise analysis of the situation we are in, is given by Chris Palmer, Seth Schoen and Peter Eckserly  in It’s Time to Fix HTTPS.  They make some key points that I would like to see stressed more in the discussions:

  1. Usability is the number one problem for security on the Internet
  2. The security model for browser PKI certificates is not properly understood by users, developers or administrators.
  3. SSL certificates are subject to some perverse incentives that lowers the real security

I like the statement about security:

  • If people don’t understand it, we engineered it wrong.

and the more realistic statement

  • Let us start by making a security model that requires only one advanced degree to understand.

If the solution proposed in the presentation is a good one I do not know.  Any solution that trusts everchanging sources runs the risk of being gamed.  Any static solution runs the risk of not being updated.

I hope the last statement about making something that requires only one advanced degree is possible.  The current use of SSL certificates is what I regard as

  • The server promised to encrypt your communication, and they may be who they claim to be (but check out of band if you really care)

January is the month for reporting on last year, and the biggest change in the way I used Internet last year was the headset.  I never leave home without it, either a discrete white one for my cell phone, or a clunky one with a good microphone for my laptop.

Why do I bother to drag a headset around?  Because podcast and phone conversations are really important to me.  And I have started to watch video systematically, and include video search in my information searches.  When I had to stay around for 20 minutes after my swine flu vaccine shot, I could watch an interesting YouTube video about learning metadata standardization on my cell phone.

When are headsets useful:

  • Headsets make the Internet available in noisy situations, and my life is sometimes noisy.
  • Headsets make me available to the world, and filters information for the others since they avoid the noise in my surroundings
  • Headsets support person to person communication, and I like talking to people
  • Headsets support feelings, since the sound of your voice gives me a lot more information than text and emoticons
  • Headset comes with the cell phone, which is a body part

Late summer 2009 the swine flu scare caused us to investigate a scenario where 40% of the work force and students in higher education has to work from home because of quarantine rules and parents staying home to care for children.  Main advice: buy headsets for everyone! Video is not all that important, but sound is critical.  Other issues that we investigated includes services for shared authoring and phone meeting infrastructure.  Luckily the scenario never materialized, but the advice stands: buy a good headset!

One thing that bugs me: the lack of federated authentication and good authorization mechanisms for conference facilities.  Phone conferences and many video conferences are set up by sharing secrets.  Other multi-party conferences are managed by social networking facilities where people have to be contacts or friends to be able to join a conference.  Some facilities rely on the good ol’ Security-by-obscurity for access, where being wide open is useful but risky.  Another thing that bugs me is gatekeepers for video conferences, they are just plain nasty and non-communicative.  And some of the video conference user interfaces should be taken out behind the barn and shot, to get them out of their misery.

Interoperability challenges get bigger when crossing security boundaries or organizational boundaries. Working from home on a non-secure PC/Mac by definition cross a security boundary before reaching anyone, and places high requirements when attempting peer to peer communication. Communicating with a central server is less complicated, as the number of boundaries crossed is limited.

In the context of web conferencing solutions that may support remote teaching, there are challenges related to interoperability both within the application area and with the rest of the infrastructure:

  • federated login: more and more products claim to be SAML2.0, or at least Shibboleth-capable
  • supporting pre-defined groups, for example by integrating from a learning management system and reusing the predefined course groupings
  • calendar integration, or integration with other collaboration tools
  • chat integration, supporting the tools familiar to the end user
  • user interface familiarity: standard place for toolbars and icons, familiar icons, comprehensible vocabulary
  • integration with the phone infrastructure: could be by SIP or through MCUs, should speak well with plain old telephony

Vendor lock-in is a danger when choosing products, and such lock-in may manifest in different ways for desktop conferencing:

  • software installation: requiring everyone participating in a meeting to download and install specific software on their PC/Mac
  • lock-out of other solutions: being unable to participate in other meeting solutions as the PC/Mac is pre-configured for a specific solution and the other solutions may have conflicting requirements that are difficult for the end user to sort out
  • data rot: stored content/data, developed for a specific whiteboard or document format, get inaccessible as the contract expires
  • no sharing of information: impossible to extract content/data to other systems

Software installation is mostly solved by using a central server for multi-person meetings, where the participants download flash or java capable software to their computers.  Any researcher participating in international projects has come across at least one non interoperable web/video conferencing solution provided by the lead partner in the project, and being required to download software to be fiddled with, often leading to non-functional sound, video or chat which then again leads to non-productive meetings.

Some interoperability challenges may be solved on the organizational level for applications residing inside the organizational security boundary. Traditional video conferencing, with pre-configured meeting rooms, is an example where dedicated staff and pre-punched holes in firewalls make it possible to use not-really-interoperable products across organizational borders.

Open standards, and consistent implementation of these, play a key role in interoperable collaborative solutions. The current technology situation makes it necessary to test products for compliance with open standards.  And the current audio/video driver software wars make Linux a hardship with regards to open interoperable video conferencing solutions that will work from home.

I wish there was a silver bullet allowing several of us to speak to each other and listen to others and look at slides and drawings, even in a multi-vendor environment.  I had the same wish 15 years ago.  At least the user interfaces have improved, and USB has added a layer of indirection that solves some of the hardware issues.  I wish that reality would shatter my video conferencing cynicism.

This summer’s most popular web site at our place is with the weather forecast.  Yr just hit a billion weather forecasts since the start in 2007 (given that the site is in mainly in Norwegian, and there are only 4.8 million Norwegians, this is amazing).

One of the main factors in the success of is their open access to data sources. hands out XML streams (and GRIB for the oceanic) for 7 million sites world wide, and they provide access to all data from all Norwegian weather stations.  Scripts for including as a gadget on your own web site are available, with good user instructions. In addition to a good end user interface this helps build a reliable site for weather information.

My advice to other public agencies: provide data that may be presented, reused and reconstructed – and build a simple interface to your own information.

A draft of federation protocols for Wave, the hot-of-hottest new collaboration tool from Google is presented in the draft General Verifiable Federation by Lea Kissner and Ben Laurie.  More white-papers are available from the Google Wave innards site.  Google Wave is announced as open source, and is  based on the principle of federation.

Wave itself is an example of what happens if the user experience is put in the driving site, and looks exciting!  The proof of the email system (and the instant message system, and document sharing, and photo sharing, and collaborative work, and sharing information) is the eating of the pudding, and I am looking forward to tasting the pudding.

Quote from the Wave presentation

Federation that was hard. So we are building this thing with live concurrent editing and chatting and instant messaging and pictures and all that stuff.  And then we throw federation into the mix, which vastly complicates things.  It would be so much easier, frankly, from an engineering point of view if we could just keep this proprietary and we control all the servers and we control all the update schedules and so on.  But we think it is worth the effort. We hope you can help us with this.  We think the world is better place if everyone can build wave systems with it.

The share abilities of federation technology is in focus.  As it should be.

The innards of wave technology remains to be auguried by resident high technologists.  But it looks cool.

Logout interfaceLogging in is simple.  Getting out is simple, you just close your browser.  Unless you wanted to explicitly log out, or you needed to log out from just one application and keep the other applications working. Another issues is related to closing all browser windows, this sounds easy to do, but can be too difficult for some users.

Andreas implemented a nice user interface for single log out in SimpleSAMLphp, as shown on the right.

A surprising high number of users (8-10%) started using the SLO functionality when this was enabled in March 2009. If this number continues to stay high as we move from pilot in a selected user group to the broader audience in education remains to be seen.

Our main motivation behind the SLO interface was to offer a way to log out from one specific application where the licensing scheme was based on payment per  user logged in at the same time.  This motivated us to find a way to log out from that system, while keeping the other sessions with service providers alive.  If we demanded a global log-out, the end users would loose their work flows in all applications within the single sign on domain.  Not using federated log-out would simply give the user a SSO session in to the application for example at a browser refresh, and this without the user knowing and being able to control the situation.

User testing provided useful feedback, and we ended up with a page as displayed above.  If log-out fails from any application (as it sometimes does with HTTP redirect when a server goes down), this is indicated with a warning sign next to the service.  All successful log-outs are marked with green.  The user is advised to explicitly close all browser windows if log-out fails.

Making the end user aware of what applications he is logged in to, is part of the awareness raising for greater security. On the other hand, we do not want to drown the user in information, because than we end up in the Click-OK-to-continue syndrome.  The minimum information required is the names of the services and some graphic indicators of login/log-out situation.

More information about the technical implementation is available in My thoughts about SLO by Andreas Åkre Solberg, and in the SimpelSAMLphp documentation.