The other side of the moon

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.

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.

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.