[philiptellis] /bb|[^b]{2}/
Never stop Grokking

Wednesday, December 12, 2012

A correlation between load time and usage

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?

Thursday, October 25, 2012

Startup Lessons: What should you optimise?

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.

Friday, June 29, 2012

iOS, Google WiFi and 2 factor auth -- clearly untested UX

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?

Saturday, June 09, 2012

Password reset over HTTP -- Part 3

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 \

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.

Friday, January 27, 2012

Saving a PDF that doesn't allow saving form contents

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:
    Print & Fax
  2. Then open the Print Queue and pause it
    HP Deskjet F4200 series
  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.

Wednesday, January 25, 2012

Password reset over HTTP -- Part 2

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:

livemocha - password reset over http

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

livemocha - password reset submitted over http

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.

Tuesday, January 24, 2012

HTTPS for login but HTTP for password resets

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:
    delicious login over ssl
  2. The Forgot password page, where you enter your username is also over HTTPS. Not strictly required, but good all the same:
    delicious - forgot password over HTTPS
  3. This sends you an email with a link to reset your password. This page is not over HTTPS:
    delicious - reset password page -- not over HTTPS
  4. And submitting this form also goes to a page that is not over HTTPS:
    delicious -- form submit over http

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.