The other side of the moon

We frequently see reports of website usage going up as load time goes down, or vice-versa. It seems logical. Users use a site much more if it's fast, and less if it's slow. However, consider the converse too. Is it possible that a site merely appears to be faster because users are using it more, and therefore have more of it cached? I've seen sites where the server-side cache-hit ratio is much higher when usage is high resulting in lower latency. At this point I haven't seen any data that can convince me one way or the other. Do you?

In the early days, when you can't afford hardware, optimise for efficient code.

Sometimes this results in unreadable code or a language that not too many developers are familiar with. This is okay. You're trying to reduce the cost of hardware.

When you get large enough to hire other developers, the cost of hardware is no longer your largest expense. At this point, optimise for code readability.

This might mean writing slightly less efficient code or moving to a more popular language. That's okay. Developer efficiency is more important at this time.

At LogNormal, we’re all about collecting and making sense of real user performance data. We collect over a billion data points a month, and there’s a lot you can tell about the web and your users if you know what to look at in your data. In this post, I’d like to go over some of the statistical methods we use to make sense of this data.

You’d use these methods if you wanted to build your own Real User Measurement (RUM) tool.

The entire topic is much larger than I can cover in a single post, so go through the references if you’re interested in more information.

So after WebPerfDays today, a bunch of us ended up at a Pizza place in Mountain View. Naturally the first thing we all did was search for wifi in the area and try to get on to a network from our mobile devices.

Now Mountain View has Google Wifi, and it appears as if they now require you to sign in with your Gmail account, and that's where the problem comes in... for me at least. I have two factor auth turned on for my google accounts, which means that after I type in my username and password, I get to a second screen to enter my second authentication token. This token comes from an app on my iOS device... the same device I was trying to log in with.

I switched to the app to get the token number, but as soon as I did that, iOS decided that I didn't actually want to sign in to the wireless network, and disassociated itself from the Access Point (AP).

Once I'd got the number, I switched back to the settings app and it initiated login again, which means I had to enter my username and password again, and by the time I'd reached the token screen, the token had expired.

This is what the token screen looks like:

It was rather annoying.

It then hit me that I could copy the token to the clipboard, and then paste it into the token text field, which should shave a few seconds off and maybe let me through.

That worked, but it was still annoying.

We started talking about how this interface could be improved. There are a few reasons why this is a problem, and I think they're mostly Apple's fault.

When you connect to a wireless network, iOS attempts to connect to www.apple.com. If it gets redirected somewhere else, it assumes that it's being asked to authenticate, and displays whatever page it gets redirected to in a browser like window.

The problem is that if you do anything other than interact with the content in this window, iOS treats it exactly the same as hitting the "Cancel" button (top right of the screenshot), terminates the login and dissociates from the AP.

This means that you cannot switch to the Authenticator App (second app at the bottom of the screenshot) to get your token.

Can Apple fix this?

Yes, just don't cancel sign in unless I explicitly click cancel

Can Google fix this?

Maybe, if they could provide a link or something that would open the Authenticator app right from that page and let me pull the number out of it (I don't know enough about iOS to know if this is possible).

Do any Apple/Google engineers want to take this up?

It's been a while since my last two posts on the topic. This time it's Groupon.

The password reset page is over HTTP:

The reset password email that you receive contains a link that looks like this:

http://groupon.com/users/password_reset/{token}?utm_source=password_reset \
    &utm_medium=email&sid={sid}&user={uid}&date={YYYYmmdd}

This link does a 301 to itself and then a 302 to a HTTPS version of itself.

The good thing is that your new password is sent over SSL. The bad thing is that your reset token is sent in clear text.

Update: This issue has been fixed by Groupon a couple of hours after reporting it.

Several organisations, consulates, for example, have forms that need to be filled up in PDFs. They have very smart PDFs that change as you fill out the form and generate nice 2D bar codes at the end with all the information easily scannable when you submit the form. Most of these forms can be saved after you've filled them out, which is important if it's complex and you need to work on it for a few days, or if you need to put it on a pen drive and take it somewhere else to print.

Every now and then however, I've come across a PDF that won't allow you to save the form contents. This kinda sucks, so I decided to find a work around.

I first tried the print to PDF option, however Adobe won't let you print these particular PDFs to a PDF.

I tried Preview, but you can't fill out the form in Preview.

Then I tried actually printing it to a dummy printer. Note that this is for MacOSX.

1. The first step is to open your printer settings. If you don't have a printer create one:
   
2. Then open the Print Queue and pause it
   
3. Step 3, is to print your document to this printer.
4. Now look into /private/var/spool/cups for a file that was created within the last few minutes. It should start with d and have a lot of numbers after it. You'll need sudo:

   sudo ls -l /private/var/spool/cups

5. copy this file somewhere convenient, and give it a .ps extension (it's a postscript file).
6. You can now open this file with Preview. I recommend opening it and reordering the pages, and then save it as a PDF.

That's it. There's a way to do it for windows too, but I don't have a windows box handy to document it. Linux is trivial.

So it looks like I've been forgetting a lot of my passwords recently. After yesterday's issue with delicious submitting passwords in the clear, today I have a problem with livemocha.com.

As before, their login page is properly secured, but the password reset page is over HTTP:

This is the password reset page:

And this is the URL the passwords are POSTed to, in clear text:

They also include third party code on their page, in this case it's a flash object from userplane.com, google analytics, and some JavaScript from pbc.com (alias for paybycash.com)

I've gotten in touch with them via their online form. Let's hope they respond.

I recently tried to log in to my delicious.com account, and realised that I'd forgotten my password, so went through the reset password flow. This is what I saw...

1. The Sign-in page is over SSL, which is good:
   
2. The Forgot password page, where you enter your username is also over HTTPS. Not strictly required, but good all the same:
   
3. This sends you an email with a link to reset your password. This page is not over HTTPS:
   
4. And submitting this form also goes to a page that is not over HTTPS:
   

Now they put the login page on HTTPS, which shows that they want to protect the user's password from sniffing, but the password reset form, which also accepts the user's password, sends the password in clear text over HTTP. This isn't good. If you're going to protect passwords via SSL, do it everywhere. FWIW, the userid (but not the username) is also sent in this form.

Additionally, the password reset page contains JavaScript from google analytics and chartbeat. As I've written before, you shouldn't trust third party scripts. While you may choose to ignore this on most pages, pages that accept the user's credentials should be considered sacred. The user assumes that anything they enter on this page is available only to your servers. By including third party JavaScript, you're breaking that trust.

I've emailed violations@delicious.com with these details, and am awaiting a response.

Update 2012-01-25 21:08 UTC: As of this time, Delicious have fixed the core issue of the password reset page being on HTTP. Kudos to the team for acting quickly. The secondary issue of third party scripts on this page still remains, but that's a policy decision for them, and not me.