Alice, Bob, and Mallory

Sometimes you do not want to show the database id for a row in the URL. The reason could be that you do not want someone to be able to scan through all the data.

One solution is to use GUID's but they have drawbacks and one of them is that they add a considerable length to the URL. The shortest URL-safe representation of a GUID I've seen is 22 characters but usually they are 36 characters.

Depending on how your id's are implemented a much shorter way could be to simply to encrypt them.

Here's a Ruby-example that Blowfish encrypts, Base64 encodes and URL-encodes an integer value. You can get crypt as a gem:

gem install crypt

1
2
3
4
5
6
7
8
9
10
11

require 'rubygems'
require 'crypt/blowfish'
require 'Base64'
blowfish = Crypt::Blowfish.new("A key up to 56 bytes long")
plainId=123456
encrypted = blowfish.encrypt_block(plainId.to_s.ljust(8))
idForURL = URI.escape((Base64.encode64(encrypted).strip))
decryptedId = blowfish.decrypt_block(  
                          Base64.decode64(  
                          URI.unescape(idForURL))).
                          strip.to_i

The .ljust(8) is because Blowfish is a 64-bit block cipher and the Ruby-implementation does not pad the data itself.

The id in the URL in this case would be c2PSXWgky40=. Its 12 characters long (11 if you skip the equal sign) and that's 10 or 24 characters shorter than a GUID. Also there is zero percent chance of collusion and if you want to you can even decrypt it.

This is not a super safe implementation but if you start your id's at a random and not too low number you are making it a bit harder for someone to crack the 56-bit key. Actually a truly random and at least 64-bit big number would be a better choice as it would have no connection to the true id at all. You would have to check for uniqueness before storing those in the database though.

There were no cross-platform windowing toolkits for Ruby so _why made one and he calls it Shoes. Not even close to 1.0, it's already yummy in a chunky kind of way and since it came from _why I simply had to try it out. Something simple.

Shoes.app :width => 1024, :height => 768 do  
  corners = [ {:x => 256, :y => 10}, {:x => 12, :y => 378}, {:x => 506, :y => 378} ]
  xpos,ypos,c = 256,10,0
  srand
  2111.times do
      c=rand(3)
      xpos += (corners[c][:x]-xpos)>>1
      ypos += (corners[c][:y]-ypos)>>1
      star xpos, ypos, 5, 10
  end
end

The result.

Recently I happened to see the FNV hash being mentioned. I had never heard of it before so I googled it and found the authors page but also a true gem. If you want a crash course in hash functions then I can recommend Mulvey's site.

This company is presenting a smart card with built in display. I do not know the underlying protocol for making debit/credit card payments by smart card instead of using the magnetic stripe but if the protocol is sophisticated enough this could help blocking some of the known attacks of those. As Chip and SPIN points out the smart cards has some issues. One of them is that if the terminal is compromised you as a customer have no way to know that you are actually confirming the transaction you think you are while entering your pin code. If your smart card shows the amount, you could at least not be deceived into emptying your account.

Three weeks ago lightning struck nearby. Today my ISP finally tried to change the switch in the central even though I reported back to them that my VSDL modem worked just fine at a friend’s house only a couple of days after my connection died.