April 2009

Consequences of Internet use, for ages 9-13 and 15-19, are presented in the You Decide campaign.  Privacy, bullying, critical text analysis and other issues are presented to the children and youngsters.  The campaign for ages 15-19 was very successful, and the hope is that the new material for ages 9-13 will be as helpful.

The forces behind this initative are Utdanningsdirektoratet (Norwegian Directorate for Education and Training), The Norwegian Data Inspectorate, and Teknologirådet (The Norwegian Board of Technology).  Language versions include Bokmål, Nynorsk, Sami, English, Spanish, Danish and Macedonian.


Is web single sign on (SSO) less secure than having many passwords?  If they crack my account, they gain access to many services at one go, so it must be worse?

Some of the reasons the reasoning is flawed

  • In practice end users chose to have the same password on multiple services.  Given a cracked account, trial and error will give access to other services.
  • If end users are forced to having too many passwords (more than 2-3), they write down the information.  Often the written information is on a yellow sticky note under the keyboard or on the desk lamp.  This is not secure.  Universities are open, and students mill around in all corners.  Students have eyes, and many have memories.
  • Storing passwords at each individual service provides a multitude of cracking vectors.  Attacking a service will eventually yield an account that may be used to further gather passwords.
  • If the account is cracked, the user may notice it earlier if the every day services are affected.  This reduces the exposure time of the cracked account, and helps reduce the consequences of a cracked account.
  • It is easier to have a stringent operational regime for a single password store and a web single sign on service than to have the same strictness for every single web service.  This does not apply for security solutions where all the security is at a single firewall at the perimeter.  It does apply to real live services on the Internet, or any service exposed to hostile users.  Daily operations and data access is grossly underestimated in most security considerations.
  • Minimal data exposure is good engineering.

Putting all the eggs in one basket may be a good idea if the basket is well guarded and you watch your steps.

Why are we spending effort on walling off bigger and bigger spaces on the Internet, and giving everyone a federated ID when what we want is more social media: sharing information, participation and communication?  This question was posed today by one of the participants in Det Digitale Trøndelag (e-collaboration for the public sector in Trøndelag).

Why is identity a necessary part of building the social media?  Social media (and web 2.0) is social because we have the ability to share information using different relations and services.  Relations to other people is normally dependent on identity services to function.  Facebook uses the consept of “friends” to select who gets to see your information, where Twitter use the “follow” function to determine what appears on you personal tweet.

The Internet part of life gets bigger and more interactive.  Transcending the passive consumer status requires the ability for both people and computer systems to read, write, collaborate and determine relevance.

People Computer Systems
Read Data import
Write Data export
Collaborate Exchange data, establish secure communications
Discover information Capability negotiation
Determine what is relevant Personalization, authorization
Trust Security

What language should a user be presented with in a login service?  The preferred language, of course.  The exercise remaining is to define the two terms language and preferred, and then to determine who preferres the language for the specific user.

A login service may use the following steps to determine what language to present, and terminate the search for information at the first positive answer

  1. Check if the user has chosen a language for the login page. End user choice is recorded in a cookie.
  2. Check if the referring service provider is requesting a preferred language
  3. Check if the browser has set an Accept-Language header
  4. Use a globally defined language as the default setting

A web service (service provider) may run through a similar checklist

  1. Check if the user has chosen a language for the site. End user choice is recorded in a cookie.
  2. Check if the preferredLanguage attribute has a value supported by your site
  3. Check if the browser has set an Accept-Language header
  4. Use a globally defined language as the default setting

Preferred language is usually preferred by the end user, but in Feide and other federations the home organization of the end user may also choose to enforce a specific language.  For elementary schools this could be a good choice, as children may add choices not supporting the educational goals.  In a situation with heated language discussions, this policy option could lead to further discussion and great opportunities for hands-on learning about political processes.

The Accept-Language header reflects configuration of the browser or operating system.  Such configuration is not necessarily reflecting the needs for web services, but could be optimized for instance for keyboard layout (Danish English being a popular choice, and this is weird even if English is an Anglo-Saxon language and the Angles and Saxons hailed from Denmark). Using the Accept-Language header from the browser without the other choices is not considered good practice, as commented in advice from W3C

The HTTP Accept-Language header was originally only intended to specify the user’s language. However, since many applications need to know the locale of the user, common practice has used Accept-Language to determine this information. It is not a good idea to use the HTTP Accept-Language header alone to determine the locale of the user. If you use Accept-Language exclusively, you may handcuff the user into a set of choices not to his liking.

The vocabulary for language codes is defined in several standards, among these are ISO 639-1 (two-letter language codes) and ISO 639-2 (three-letter language codes.  Feide is changing the encoding from two-letter language codes to three-letter language codes to add support for the two Sami languages that do not have two-letter codes: Southern Sami and Lule Sami.  Support exists for English, Norwegian, Norwegian bokmål, Norwegian Nynorsk and Northern Sami.  If you ask me why a small group of people like the Norwegians (4,8 million) have two kinds of Norwegians (two really similar forms of the same language), you should prepare yourself for a long discussion on urban/rural, political power, nationalism and the construction of a national state.  Or you could just accept the way it is, and move on to why the Sami (30000-70000) have multiple distinct language.

More practical advice on how to handle language processing in simpleSAMLphp is available.

Summing up: Language choices are complex.  Good luck!