A Taste of Insecurity /  by Paulo Fierro

This weekend marks the 25th Taste of Cayman — a food and wine festival put on by the Cayman Islands Tourism Association (CITA).

This year you can buy the tickets online on their site built by Netclues. However, the purchase process is entirely insecure. Taking customers' credit card details in this manner is both irresponsible and unprofessional and it also violates the Payment Card Industry's (PCI) Data Security Standard requirements to protect cardholder data (point #4). I'm no lawyer but I believe if the card details were to fall into the wrong hands they would also be financially liable.

I tweeted at CITA and Netclues but they didn't reply.

When we help clients build anything, be it a site or an app it falls on us as the designers and developers to educate and inform them about issues like this. I am appalled that the people in charge of developing this site would roll out a payment solution without something as basic as an SSL certificate in place — trying to visit the tickets page over HTTPS results in a 404 error (page not found).

If a relatively inexpensive SSL certificate is not installed then I do wonder how much care and attention has been put in place behind the scenes to store credit card details in a safe and secure manner. 

Its 2013 — we should know better. We should expect better.

In any case, we are looking forward to attending the event but purchased our tickets the old-fashioned way.

In person.

What lurks on port 7682? /  by Paulo Fierro

I was using Charles earlier to monitor some HTTP requests and noticed that every few seconds a request would show up trying to ping 127.0.0.1 (localhost) on port 7682. This was odd so I did a quick search and found that I had actually tweeted about this approximately 112 days ago — and had completely forgotten.

So if you see this, simply disable the Adobe Edge Inspect extension in Chrome in the Extensions settings.

Let's see if I remember this time.

Creating a simple Sinatra app on Heroku /  by Paulo Fierro

I am a big fan of Sinatra and have been writing a few apps using this lightweight Ruby framework. Deploying them on Heroku is a breeze and painless but I always seem to forget a step so this is more of a note for future me.

I wrote a template that sets up a very basic Sinatra app that outputs JSON — perfect for when I need to set up a basic API for an iOS app. There's no database, so DataMapper is nowhere to be found and there's no tests either, just extreme simplicity.

Assumptions:

  1. you already have a Heroku account and have the Heroku Toolbelt installed
  2. you are on a Mac, though I'm sure its not too dissimilar for Windows folk
  3. You have the Bundler and Shotgun gems already installed

So with that out of the way,

  1. Download the template, and unzip it into your new apps' folder
  2. Navigate to the folder in Terminal and then run bundle install
  3. Check that everything is working by running shotgun. Then fire up a browser and navigate to http://127.0.0.1:9393
  4. Next we need to create the local git repository: git init
  5. Now we add all of the files: git add .
  6. Then we commit them: `git commit -m 'first commit'

Now we're ready to create the app on Heroku. For this example lets call it "myapp".

  1. In the Terminal create the app (the default stack nowadays is Cedar which is what we want): heroku apps:create myapp
  2. Because the git repository already exists, the Heroku toolbelt should have set up a remote for us, but lets double check: git remote -v
  3. Double check that the remotes look like heroku git@heroku.com:myapp.git for both fetch and push
  4. Deploy! git push heroku master

Now if you navigate to http://myapp.herokuapp.com you should see some successful JSON output.

Now go build your app!

Setting a photo's creation date to the date it was taken /  by Paulo Fierro

First a little back story.

The other day my mom called me up saying that her 11" MacBook Air was out of space and running slow wondering what we could do about it. Knowing that OS X runs pretty terribly without some free space I figured I'd run some of the Onyx cleanup scripts, check out where the space was being used up with Daisy Disk and get rid of some of the crap.

Onyx cleared a few gigs, and Daisy Disk said that iPhoto was the main culprit — the library being nearly 80GB,  67% of the total space on the disk.

Firing up iPhoto I created a Smart Album to see how much space videos were taking up.

The Smart Album conditions

Turns out there was nearly 10GB in videos, so I selected all of the items in the Movies album and exported them to an external disk. After removing these from the library, emptying the iPhoto trash and the actual Trash the disk had about 15GB free.

Success!

Not so fast

Of course not. After handing the laptop back my mom complained that iPhoto was running really sluggish. I got it back, checked it out and it was unusable. Scrolling had a 5-6 second lag and the UI responsiveness was generally pretty terrible.

My guess is that removing those videos screwed up the library somehow, so I opened up iPhoto holding down CMD+OPT to get the repair menu up and ran each item on the list (repairing permissions, rebuilding thumbnails, reindexing photos, repairing the library). Many, many hours later everything was still terrible so I decided to start from scratch.

My mom's iPhoto library is fairly large — nearly 15,000 photos. Initially I thought her 11" may not be able to handle that many photos so I figured exporting all of the photos and only importing the ones from the last two years would be a way of seeing if that was the case.

I left the laptop overnight exporting the 15,000 photos, backed up the library and deleted the original. Now I just had to find the photos taken within the last two years.

What should be easy...

Once again foiled. All of the exported photos had date of creation and modification set to yesterday. The sub-folders were all album names and not really indicative of when the photos were taken. I peeked inside the iPhoto library package contents to the Original and Modified folders where the photos live but found duplicates, terrible names and general cruft so I figured the actual exported photos had to be salvaged somehow.

Then I remembered EXIF data. Every photo you take contains metadata about what camera was used to take it, the model, ISO, exposure time, etc. One of those fields is the date it was taken. So if I could figure out how to read the date taken I could write a script to "fix" the photos.

ExifTool to the rescue!

With ExifTool in hand I went off to Automator and wrote some Ruby that would loop through a set of folders and change the date modified to the date the photo was taken as dictated by its EXIF data. It looked like so (download it here):

I tested this on a folder and it worked! I could follow along what was going on in Console.app and all was good.

Then I ran it on the main folder and encountered an interesting bug:

Run Shell Script failed - too many arguments.

Automator was passing in the path names to all of the photos to Ruby as arguments, but someone could only handle 4096 of these. Well below the 15,000 items I wanted to process.

Having spent enough time on this already I decided to be lazy and just run it a few times. Due to the logging to the Console I could see how far it had got and simply resume it from there with a next batch. There's also a bug where photos with single quotes or ampersands had to be renamed to be processed, which I could have fixed but again, lazy.

Now only the modified date was supposed to be changed, but I guess OS X doesn't allow a creation date to be later than its modified date so they both changed as a bonus.

Now for some Spotlight magic...

Now that the photos finally had their dates back I could make a simple search for files that were JPEGs and created in the last two years.

Importing these into a new iPhoto library took a while but once it was done scrolling was fluid and the app was generally responsive. Great! So I backed up this library and decided to try importing the rest of the photos.

A few hours later all of the photos were back in iPhoto and the app was still scrolling smoothly. What the fuck?

My guess is that removing the videos screwed up the original library in a way that iPhoto itself couldn't fix. Maybe deleting the video files themselves from the disk would have been better — leaving orphans in the iPhoto library. I have no idea.

In any case it was a learning experience and yet again proof that Automator is truly a hidden gem that I don't use enough.

You can download the Automator app (open it in Automator to edit it if you like), but remember you must have ExifTool installed first.