When I created my on-line photo album, we had the year 2001 and there was nothing wrong with publishing ones photos in the Internet. It has been almost ten years now, and things have changed. Privacy is an issue, especially when it also affects your friends and family. The problem
So I needed to find some protection. These were my requirements:

1. I only want to protect parts of the site, as there are some pictures that I intentionally share with the public. This selection should be possible down to the individual image.
2. The solution should work without any dynamic server component besides the web server itself. This rules out any self-written CGI scripts as well.
3. One password, given to all my friends etc., is not sufficient as it might leak to unintended audience.
4. I do not want my visitors to have to register and remember yet another username and password just for my site. I also do not want to manage this user database.
5. I do not want to have do large changes to the file structure of my photo album.

This rules out most common options, e.g. protection by a .htpasswd file. Requirements 3 and 4 point to a solution based on OpenID. With OpenID, my visitors can authenticate against a service they already use (Google, Yahoo, etc.), relieving me from the burden of maintaining a user database and them from having to remember a password. There is a mod_auth_openid module for the Apache webserver, and it is even distributed with Debian in the libapache2-mod-auth-openid package. So requirement 2 is fulfilled. The tricky part is: How do we achieve OpenID protection for some images, and not for others. The solution I first played around with selectively enabling or disabling mod_auth_openid based on <FileMatch> directives in the Apache configuration, but it was not elegant and would not scale well. I have more than 20.000 pictures to manage, and have already selected over 5000 pictures to be shown without protection. My solution is based on a partial copy of the whole directory tree that contains all public files. To save disk space, these are just symbolic links to the real file in the protected location. Some mod_rewrite magic then takes care of giving the user the impression that all files are in the same location. I set up a small example of my solution, which has this directory structure:

.:
drwxr-xr-x 2 root root 4096  2. Aug 12:03 images
lrwxrwxrwx 1 root root   18  1. Aug 12:05 index.html -> private/index.html
lrwxrwxrwx 1 root root   18  1. Aug 12:05 login.html -> private/login.html
drwxr-xr-x 3 root root 4096  2. Aug 12:03 private
./images:
lrwxrwxrwx 1 root root 33  2. Aug 12:00 pleaselogin.png -> ../private/images/pleaselogin.png
lrwxrwxrwx 1 root root 28  2. Aug 12:03 public.png -> ../private/images/public.png
./private:
drwxr-xr-x 2 root root 4096  2. Aug 12:00 images
-rw-r--r-- 1 root root  267  2. Aug 12:03 index.html
-rw-r--r-- 1 root root   94  2. Aug 12:01 loggedin.html
-rw-r--r-- 1 root root 2091  2. Aug 12:03 login.html
-rw-r--r-- 1 root root   10 18. Nov 2009  protected.html
./private/images:
-rw-r--r-- 1 root root 4074  2. Aug 11:58 pleaselogin.png
-rw-r--r-- 1 root root 2670  2. Aug 11:58 private.png
-rw-r--r-- 1 root root 2043  2. Aug 11:58 public.png

As you can see, real files only reside in private/, outside of that, only symbolic links exist. The apache configuration protects the private directory and blends it into the main directory:

   <directory /var/www/nomeata.de/openid-test>
        RewriteEngine On
        # Abuse the login page as an error image
        RewriteCond % QUERY_STRING  \.(png jpg)
        RewriteRule ^login.html$ /openid-test/images/pleaselogin.png
        # Ship private files, if they exist, unless public files exist
        RewriteCond  $1 !^private
        RewriteCond  /var/www/nomeata.de/openid-test/$1 !-f
        RewriteCond  /var/www/nomeata.de/openid-test/private/$1 -f
        RewriteRule  ^(.+)$ /openid-test/private/$1
   </directory>
   <directory /var/www/nomeata.de/openid-test/private>
        AuthOpenIDEnabled        On
        AuthOpenIDDBLocation     /var/lib/apache2/mod_auth_openid/mod_auth_openid.db
        AuthOpenIDLoginPage      /openid-test/login.html
        AuthOpenIDTrustRoot      http://nomeata.de
        AuthOpenIDCookiePath     /
        AuthOpenIDCookieLifespan 2592000
    </directory>

A special trick handles the login page for protected images: If the login page is requested and the referrer indicates that the user tried to access a .png or .jpg file, apache will instead ship an image containing an error message. For my photo album I have a small Perl script that, given a directory with a private/ directory therein and a list of rules in form of glob patterns, will symlink matching files and remove symlinks that are not allowed any more.
What s next? As you can see, this does not actually protect the content. It only requires the user to authenticate, then everything is visible. To select which OpenIDs are allowed to access which code, some bugs will have to be fixed in mod_auth_openid first. There was little activity there recently, I hope that the project is not dead.

We had one of the biggest snows of the year today in Montreal. The storm, which happened overnight and was supposed to let up around noon, still hasn't stopped. It's a practical white-out outside -- big fluffy flakes everywhere. The radio said we had more than 40 cm of snow, which is just amazing. I headed over to La ka this afternoon for an interview with Steve Faguy of the Montreal Gazette. I was pretty worried about going out, but as usual I was pleasantly surprised when I was outside. Snowy weather is pretty gentle, and although I was cold and wet when I got to La ka, it wasn't all that bad. I had a good talk with Steve about Wikitravel, Montreal tech scene, and the French Revolutionary Calendar. I'm looking forward to seeing the article when it comes out. tags: steve faguy la ka snow interview gazette

certifi.ca doing well I was glad to see a post about certifi.ca in the Solution Media Blog of Thomas Huhn. Thomas set up the extremely useful OpenID Directory, so his opinion is pretty valuable. I'm glad he's as enthused about certifi.ca as I am. tags: thomas huhn certifi.ca openiddirectory openid

Registration and privacy I think I have an account on every free OpenID service on the Web. I need lots of accounts for debugging purposes, and I also like to have an idea of what people are doing with the protocol. I checked out prooveme.com a few days ago. prooveme.com gives out OpenIDs with SSL cert authentication, like certifi.ca. It seems like an OK service, but I don't think they use SSL and certs the right way. I tested the prooveme ID on a couple of services, had a couple of errors, and that was that. So I was surprised to see this posting in the proovemeblog today:

• certifi.ca is another site doing certificated OpenID. Evan, the creator of certifi.ca is a subscriber of ours. We'll obviously be pleased if he carries on using us!

Now, I've been in wikis long enough to know that you have to AssumeGoodFaith when people post things in public forums, so I'll take this comment as nothing more than clumsy but good-natured ribbing. Ha ha ha. But: I haven't publicly said that I'd tested out the prooveme server. I'm not particularly embarrassed about it, but I hadn't had any reason to mention it to anybody, either. So the only way the poster could know that I'd registered for their service was to check their database records for my registration information. Publishing users' registration info without their consent steps over an important privacy line for me and, I think, for a lot of people. I'm not sure making a joke really justifies that kind of privacy invasion. I don't feel fairly treated, here. I partly blame myself: after all, I submitted personally-identifying information (PII) into a Web form on a site without an explicit privacy policy. I've gotten so used to OpenID providers being experienced with security and privacy issues that I made assumptions that turned out not to be the case. I've taken the incident as a wake-up call to put a privacy policy on certifi.ca. I hope that will communicate to users what I consider acceptable use of their data. And I'll make sure to check carefully for privacy policies whenever creating a new account in the future. For clarity: if I have an account on a Web service, that is not any kind of endorsement of their service, and doesn't necessarily suggest that I use that service regularly (or at all). I'm going to see what I can do to get my account deleted from the prooveme servers to avoid any misunderstanding in the future. tags: prooveme privacy openid

I was happy to see The OpenID Directory mentioned in a comment on the TechCrunch article about Jyte. There have been directories on http://openid.net/, but it's nice that someone's made a more convenient interface for this kind of list. tags: openid openiddirectory