Ni av ti nordmenn ønsker å kommunisere med fastlegen sin over internett. – Helsevesenet bør få én felles inngangsportal på nett, sier Teknologiråds-direktør Tore Tennøe.

Denne påstanden er basert på en undersøkelse foretatt av Response Analyse Oslo for Teknologirådet. Hvis man føler lenke til denne artikkelen, fremgår noe mer informasjon om metodikken bak undersøkelsen:

Et landsrepresentativt utvalg på 1098 personer fra 17 til 84 år har svart på den elektroniske spørreundersøkelsen…

Spørsmålet er da: er det et landsrepresentativt utvalg hvis man kun baserer seg på dem som svarer på elektroniske undersøkelser? En ting som er helt sikkert, er at man ikke kan si at “9 av 10 nordmenn ønsker…”. Siden undersøkelsen gjelder bruk av elektroniske hjelpemidler er det en åpenbar svakhet at (sannsynligvis) kun de som bruker elektroniske hjelpemidler har mulighet til å svare. Når det er sagt er det veldig mangelfull informasjon om metodikken brukt i undersøkelsen, så man kan ikke være bastant her. Viktige momenter er hvordan man har valgt ut respondenter, hvordan man har kontaktet dem, og ikke minst hvor mange som har unnlatt å svare.

Metodikken i undersøkelsen er det vanskelig å si noe konkret om siden veldig lite informasjon om den er tilgjengelig. En ting er dog sikkert, artikkelen som har dedusert at “9 av 10 nordmenn…” burde si noe om datagrunnlaget for påstanden. At undersøkelsen var foretatt elektronisk er essensielt. Kanskje burde det heller stå “9 av 10 nordmenn som svarer på elektroniske undersøkelser ønsker…”

One thing is that the perpetrators could use this information to get details about my relationship with Atlassian, among other things my license keys for Atlassian products. Even worse is that they could try and use the passwords to get into my accounts at other sites. That would be successful if I used the very usual and very baaad practice of reusing the same (user name and) password on several sites and applications. Luckily I don’t.

Here is what Atlassian states about why this could happen:

During July 2008, we migrated our customer database into Atlassian Crowd, our identity management product, and all customer passwords were encrypted. However, the old database table was not taken offline or deleted, and it is this database table that we believe could have been exposed during the breach

Trying to act as a responsible company, Atlassian goes on to list what they have learned from the incident. Among other things, they state that

The legacy customer database, with passwords stored in plain text, was a liability. Even though it wasn’t active, it should have been deleted. There’s no logical explanation for why it wasn’t, other than as we moved off one project, and on to the next one, we dropped the ball and screwed up.

I am sorry, but I find it hard to believe that this is the entire truth. Yesterday afternoon (European time) I went to their site and on the login screen I used their “Forgot my password” functionality. Can you guess what happened? They sent me an email with my password in clear text! So, I would indeed say that this “legacy database” is indeed active…

Later on the day yesterday, I also got an email from the Apache Software Foundation that their JIRA instance also have been hacked. See their blog entry about the issue. According to the blog entry, the situation is a bit better than it is at Atlassian. They state that

If you are a user of the Apache hosted JIRA, Bugzilla, or Confluence, a hashed copy of your password has been compromised. JIRA and Confluence both use a SHA-512 hash, but without a random salt. We believe the risk to simple passwords based on dictionary words is quite high, and most users should rotate their passwords.

At least, the password was not stored in clear text, which is of course much better than having it in clear text. However, the compromised passwords could still be useful for an attacher because they are not salted. It allows an hacker to compare hashes of other accounts with hashes of a known password which would allow a dictionary attack (as is stated).

This is not security for the crowds (pun intended).

WTF? I am quite sure that replacing ToLower() with ToUpperInvariant() will make my test fail…

For example, transactional leadership with support from “traditional” tools:

1. The manager gives her subordinate an assignment to write some document enclosed in an email
2. The subordinate receives the assignment in email, creates and writes a document, drop it to a company file share, and emails his boss to review the document
3. The manager reviews the document and sends a response in email
4. The subordinate updates the document according to his boss’ review and finalize the document. Then, he notifies his boss that the document is finished.

This would be an example of transformational leadership: The boss creates a Wiki page for the document, and invites her subordinate to participate, either by screen sharing or editing directly in the Wiki page, and they work on the document together. It might be that my view on transformational leadership is too simplified or misunderstood, but I think there is a link.

I think that starting to use new collaboration tools often would mean a shift in leadership style in the organization. These tools invites us to work differently, and will not gain their potential usage unless we are willing to let go of traditional ways of working. Starting to use collaboration tools thus benefits greatly from leadership buy-in, although not strictly necessary (it could emerge from the masses).

“They argue that their new strategy is intended to allow new ideas to emerge in an evolutionary fashion, making it possible to move data traffic seamlessly to a new networking world.”

The Internet has indeed been evolutionary, how can one prevent ending up in the same mess once again?

“Gigi Zenk, a spokesperson for the Washington State Department of Licensing, says that Washington has made it illegal for third parties to use data from RFID tags without the tag owners’ consent.”

Well, now I am relieved. Not.