digg bar controversy

Update: I’ve actually written this post yesterday and scheduled it for posting today. In the mean time, digg has found an even better solution and only shows their bar for logged in users. Still – a solution like the one provided here would allow for the link to go to the right location regardless of the state of the digg bar settings.

Recently, digg.com added a controversial feature, the digg bar, which basically frames every posted link in a little IFRAME.

Rightfully so, webmasters were concerned about this and quite quickly, we had the usual religious war going on between the people finding the bar quite useful and the webmasters hating it for lost page rank, even worse recognition of their site and presumed affiliation with digg.

Ideas crept up over the weekend, but turned out not to be so terribly good.

Basically it all boils down to digg.com screwing up on this, IMHO.

I know that they let you turn off that dreaded digg bar, but all the links on their page still point to their own short url. Only then is the decision made whether to show the bar or not.

This means that all links on digg currently just point to digg itself, not awarding any linked page with anything but the traffic which they don’t necessarily want. Digg-traffic isn’t worth much in terms of returning users. You get dugg, you melt your servers, you return back to be unknown.

So you would probably appreciate the higher page rank you get from being linked at by digg as that leads to increased search engine traffic which generally is worth much more.

The solution on diggs part could be simple: Keep the original site url in the href of their links, but use some JS-magic to still open the digg bar. That way they still get to keep their foot in the users path away from the site, but search engines will now do the right thing and follow the links to their actual target, thus giving the webmasters their page rank back.

How to do this?

Here’s a few lines of jQuery to automatically make links formated in the form

be opened via the digg bar while still working correctly for search engines (assuming that the link’s ID is the digg shorturl):

$(function(){
  $('div#link_container a').click(function(){
    $(this).attr('href') = 'http://digg.com/' + this.id;
  });
});

piece of cacke.

No further changes needed and all the web masters will be so much happier while digg gets to keep all the advantages (and it may actually help digg to increase their pagerank as I could imagine that a site with a lot of links pointing to different places could rank higher than one without any external links).

Webmasters then still could do their usual parent.location.href trickery to get out of the digg bar if they want to, but they could also retain their page rank.

No need to add further complexity to the webs standards because one site decides not to play well.

The consumer loses once more

DRM strikes again. This time, apparently, the PC version of Gears of War stopped working. This time it seems to be caused by an expired certificate.

Even though I do not play Gears of War, I take issue in this because of a multitude of problems:

First, it’s another reason where DRM does nothing to stop piracy but punishes the honest user for buying the original – no doubt, the cracked versions of the game will continue to work due to the stripped out certificate check.

Second, using any form of DRM with any type of media is incredibly shortsighted if it requires any external support to work correctly. Be it a central authorization server, be it a correct clock – you name it. Sooner or later you won’t sell any more of your media and thus you will shut your DRM servers down, screwing the most loyal of your customers.

This is especially apparent with the games market. Like no other market, there exists a really vivid and ever growing community of retro gamers. Like no other type of media, games seem to make users to want to go back to them and see them again – even after ever so many years.

Older games are speedrunned, discussed and even utterly destroyed. Even if the count in players declines over the years, it will never reach zero.

Now imagine DRM in all those old games once you turn off the DRM server or a certificate expires: No more speedruns. No more discussion forums. Nothing. The games are devalued and you as a game producer shut out your most loyal customers (those that keep playing your game after  many years).

And my last issue is with this Gears of War case in particular: A time limited certificate does not make any sense in this case. It’s identity that must be checked. Let’s say the AES key used to encrypt the game was encrypted with the private key of the publisher (thus the public key will be needed to decrypt it) and the public key is signed by the publishers CA, then, while you check the identity of the publishers certificate, checking the time certainly is not needed. If it was valid once, it’s probably valid in the future as well.

Or better: A cracker with the ability to create certificates that look like they were signed by the publisher will highly likely also be able to make them with any timed validity.

This issue here is that Gears of War probably uses some library function to check for the certificate and this library function also checks the timestamp on the certificate. The person that issued the certificate either thought that “two years is well enough” or just used the default value in their software.

The person using the library function just uses that, not thinking about the timestamp at all.

Maybe, the game just calls some third-party DRM library which in turn calls the X.509 certificate validation routines and due to “security by obscurity” doesn’t document how the DRM works, thus not even giving the developer (or certificate issuer) any chance to see that the game will stop working once the certificate runs out.

This is lazyness.

So it’s not just monetary issues that would lead to DRMed stuff stop working. It’s also lazyness and wrong sense of security.

DRM is doomed to fail and the industry finally needs to see that.

IRC user interface idea

Don’t you know this problem?

You are connected to some amount of IRC servers and you are watching a certain amount of channels.

Every IRC client I know either uses tabs or windows to separate these channels in their own context, usually providing some visual clue if there was activity in a different channel you are not currently watching.

While this metaphor probably makes a lot of sense in very busy channels, I think that consolidating every channel into one single window probably is a much better way for you to follow what’s going on and to talk back to the channels – especially when you are watching lesser populated channels.

This frees you from the burden of constantly switching channel windows (or tabs) to see what is going on.

Let’s say you are connected to irc1.example.com and irc2.example.com. On irc1, you are connected to #channel1a and #channel1b and on irc2, you are connected to #channel2a

Now, to my knowledge, every current IRC client either uses three windows or three tabs (maybe even 5 windows/tabs because the server themselves get a window too) to represent this information. In window based clients, you can arrange all of them aside of each other, but talking to a certain channel still forces you to focus different windows.

Now with my idea, you would consolidate these channels. You would only get one window which contains all the messages from all channels.

So in the simplest incarnation, you’d probably see something like this in your chat window:

1) irc1/#channel1a [user1aa]> hi there!
2) irc1/#channel1b [user1a]> hi there!
1) irc1/#channel1a [user1ab]> hi user1aa
3) irc2/#channel2a [user2aa]> hi folks!

though you would probably understand much more easily what’s going on if the server-, channel- and user names were a bit more… well… distinct.

Of course, you could add color. You assign each channel a color, like this:

1) irc1/#channel1a [user1aa]> hi there!
2) irc1/#channel1b [user1a]> hi there!
1) irc1/#channel1a [user1ab]> hi user1aa
3) irc2/#channel2a [user2aa]> hi folks!

and if you need to, you can still color nicks.

1) irc1/#channel1a [user1aa]> hi there!
2) irc1/#channel1b [user1a]> hi there!
1) irc1/#channel1a [user1ab]> hi user1aa
3) irc2/#channel2a [user2aa]> hi folks!

Now… how to talk back?

Easy. Every channel is assigned a number for quick access. Just type /[channel number] to switch to that channel and type, then hit enter. The channel you last talked to is predefined and sticks around until you hit /[another channel number].

This feels so much an easier and more intuitive way to handle multiple connections, especially in cases where the channels you are joined are not too active, as in this way, you can easily watch everything that is going on.

Also, usually, discussions happen in intervals in different channels. You will only very rarely see the color concert I’ve shown above as usually, you have a discussion going on in one channel while the others are relatively quiet.

I’ll probably have to go and implement a proof-of-concept sometime in the future, but this feels like such a nice idea when just looking at it. Why is nobody doing it? What am I missing?

Food for thought

 

  1. When you open a restaurant, you know the risk of people going to the supermarket and cook their own meal, not paying you as the restaurant owner.
  2. When you publish a book, you know there are going to be libraries where people can share one copy of your work.
  3. When you build a house and sell it, you know the people living there will be going in and out of your house for year without ever paying you anything more.
  4. When you live in a family and clean the parents car for one Euro, you know about the risk of your sister doing it for 50 cents next time around.

But

  1. The music industry claims to have a monopoly on their work, managing to get laws created that allow them to control distribution and disallow anybody to create a lookalike without paying them.
  2. The game industry is hard at work making it impossible for honest customers to even use the game they bought on multiple devices. And now they even begin to go after the used games market (think about that SNES pearl you just saw in your small games store. The one you wanted so badly ever since you’ve been young. Wouldn’t it be a shame it was illegal for them to sell it?)
  3. The entertainment industry is hard at work to make you pay for every device you want to play the same content on.
  4. Two words. “SMS pricing”.

Why do things applying to “small people” not apply to the big shots? Why does the government create laws to turn around well-known facts we have grown up with just so that the wealthy companies (the ones not paying nearly enough taxes) can get even wealthier?

I just don’t get it.

Why is nobody using SSL client certificates?

Did you know that ever since the days of Netscape Navigator 3.0, there is a technology that allows you to

  • securely sign on without using passwords
  • allow for non-annoying two-factor authentication
  • uniquely identify yourself to third-party websites without giving the second party any account information

All of this can be done using SSL client certificates.

You know: Whenever you visit an SSL protected page, what usually happens is that your browser checks the identity of the remote site by checking their certificate. But what also could happen is that the remote site could check your identity using a previously issued certificate.

This is called SSL client side certificate.

Sites can make the browser generate a keypair for you. Then they’ll sign your public key using their private key and they’ll be able to securely identify you from then on.

The certificate is stored in the browser itself and your browser will send it to any (SSL protected) site requesting it. The site in turn could then identify you as the owner of the private key associated to the presented certificate (provided the key wasn’t generated on a pre-patch Debian installation *sigh*).

The keypair is bound to the machine it was generated on, though it can be exported and re-imported on a different machine.

It solves our introductory three problems like this:

  • by presenting the certificate, the origin server can identify you. No need to enter a user name or a password.
  • By asking for a password (something you know) and comparing the SSL certificate (something you have), you get cheap and easy two factor authentication that’s a lot more secure than asking for your mothers maiden name.
  • If the requesting party in a three-site scenario knows your public key and uses that to request information from a requested party, you, can revoke access by this key at any time without any of the parties knowing your username and password.

Looks very nice, doesn’t it?

So why isn’t it used more often (read: at all)?

This is why:

Picture underlining the

The screenshot shows what’s needed to actually have a look at the client side certificates installed in your browser, which currently is the only way of accessing them. Let’s say you want to copy a keypair from one machine to another. You’ll have to:

  1. Open the preferences (many people are afraid of even that)
  2. Select Advanced (scary)
  3. Click Encryption (encry… what?)
  4. Click “View Certificates” (what do the other buttons do? oops! Another dialog?)
  5. Select your certificate (which one?) and click “Export” (huh?)

Even generation of the key is done in-browser without feedback by the site requesting the key.

This is like basic authentication (nobody uses this one) vs. forms based authentication (which is what everybody uses): It’s non-themeable, scary, modal and complicated.

What we need for client side certificates to become useful is a way for sites to get more access to the functionality than they currently do: They need information on the key generation process. They should allow the user to export the key and to re-import it (just spawning two file dialogs should suffice – of course the key must not be transmitted to the site in the process). They need a way to list the keys installed in a browser. They need to be able to add and remove keys (on the user’s request).

In the current state, this excellent idea is rendered completely useless by the awful usability and the completely detached nature: This is a browser feature. It’s browser dependent without a way for the sites to control it – to guide users through steps.

For this to work, sites need more control.

Without giving them access to your keys.

<divpInteresting problem. Isn’t it?</p>