First LinkedIn Intro, then BonzyBuddy 2.0

Last week, LinkedIn published an indepth technical explanation of how their new LinkedIn Intro mobile product works on iOS. What Intro does is basically display LinkedIn data about your contacts directly in your email client – similar to what Rapportive did for gmail. It’s a cool app but the implementation details LinkedIn shared ignited an Internet firestorm, especially among the startup/hacker crowd.

How Intro works is it basically modifies the users normal iOS email client so that it connects through a LinkedIn proxy server instead of interacting with their webmail provider directly. What this does, is allow LinkedIn to dynamically modify a user’s email before it reaches their mail client, depending on if the user is connected to the sender on LinkedIn. From a IT security standpoint, introducing a third party that would sit between a user and the mail server they’re connecting to undoubtedly introduces a new attack vector but what really caught my interest was how LinkedIn was achieving this. In order to smoothly update the user’s proxy settings, LinkedIn is using a iOS feature known as Configuration Profiles.

I’m not familiar with the iOS SDK or APIs so this was the first time I’d heard about Configuration Profiles. In short, what they allow an app to do is install a set of settings on an iOS device – from email and web proxy settings to additional credentials and SSL keys. Configuration profiles are typically used in enterprise environments to allow a company’s IT department to quickly configure the settings on an employee’s iOS device. When provisioning a new device, IT would basically use the configuration profile to install things like a VPN, internal credentials, etc. So what’s the problem?

Well according to the LinkedIn post and comments from users that have used profiles before, the user experience of installing a profile which radically alters your iOS system settings is surprisingly unassuming. As a user, you click through a couple of prompts and boom, all of a sudden Safari is using a proxy server to fetch websites. So what nefarious things could you do by routing iOS mobile traffic through a proxy server? Unsolicited injected display advertising.

On the desktop web, unscrupulous extension developers have been monetizing their install base by injecting display ads into the browsing experience of their users for years. From companies like Bonzi Buddy to newer companies like PageRage, the model is tried, true, and profitable. However, on mobile there isn’t an obvious opportunity to inject ads and get access to the rapidly growing number of mobile web impressions. It seems like using configuration profiles would be the perfect vector to change this. Crapware iOS developers could quietly prompt their users to install a configuration profile to get access to “hot new features” and then surreptitiously start injecting display ads into websites on the proxy server.

I’m not familiar enough with iOS development to speak to how easy developing an app like this would be or if it would get past the app store approval process, but if it’s feasible someone is certainly going to do it. If anyone is familiar with an app already doing this, I’d love to know about it.

HTML5: Masking file inputs with CSS3

This morning, I was implimenting an AJAX “profile photo uploader” using the new HTML5 File object. With the new File object, you’re able to do a file upload using an AJAX request instead of requiring a form submission to upload the file.

This works great with the caveat that there still needs to be a <input type="file" /> on the page in order for the user to select a file. This presents a UI/UX issue because there isn’t much leway in styling HTML file inputs and consequently the input was looking out of place on our form.

After poking around for a bit I ran across jQuery File Upload which seems to solve this problem. Inspecting the CSS, the CSS “masks” the file input by using a CSS3 “transform” and then setting the opacity value to 0 so the input is visually hidden.

Implimenting the transform+opacity trick was pretty straightforward but the issue I ran into was that I couldn’t get the mouse cursor being displayed to appear as a “hand”, I kept seeing the “text selector” cursor. I had changed the transform being used and unfortunately the jQuery File Upload CSS didn’t have any comments explaining what it was actually doing to get the cursor part of the CSS to work.

It turns out what you want to do is use the CSS3 “transform” function to skew the file input so that the “Browse” button is covering the element that you want to use to trigger the “select file” behavior and then just set the opacity to 0 to make the file input invisible.

You can see the progression here The first container has no styling applied on the file input, the second one has the “Browse” button skewed into the right spot and finally the last one has the opacity set to 0. If you change the “cursor” CSS directive on the file input you’ll notice that in the 2nd and 3rd examples the cursor will change wherever your mouse is in the container. Also, you’ll notice that if you click anywhere in the container the “select a file” dialog will get triggered as expected.

Anyway, as always comments/feedback/questions are welcome!

FanFeedr Widgets Are Live!

Over the past few weeks we had the opportunity to work with FanFeedr to put together some widgets for their sports news platform. Previously, FanFeedr had been using Sprout to build their widgets but this required someone to hand build a Flash widget for every “resource” on FanFeedr (there are a lot). In addition, since the Sprout widgets are Flash they aren’t easily crawled by search engines.

Our widgets are different. They allow FanFeedr to generate widgets on the fly for any of their pages and allow users to customize the color schemes. Check out a widget builder for the NY Yankees here.

Basically, our widget builder works by allowing users to customize the size and colors used in the widget. This data is serialized as a JSON object and then base64 encoded so that it can be sent to the “generator” on the server. Then, the server unpacks the payload and builds a widget according to the data specified in the JSON object. In addition, our embed code includes a noscript tags so that search engines pick up the links in the widget as well.

Anyway, working with FanFeedr was a great experience and we hope to continue our relationship moving forward. Go build yourself a widget!

99designs and Amazon. Design. Crowd sourced.

A week or so ago my Dad asked if we could have our designer put together a logo for him. Unfortunately, our guy was buried under a mound of work and generally couldn’t help us out. We haven’t always had the best luck with Craigslist so I was ready to try something new.

Over the last few months, I’ve been seeing a good amount of chatter surrounding “spec” design sites especially After taking a look around the site I figured now was a good time to give it a shot. We were on a tight budget, tight time line, and my Dad didn’t have much direction for the logo.

I posted up a contest last Sunday here and we were looking at entries by Monday afternoon. Now things got more difficult. We were having a hard time coming up with “star ratings” and constructive feedback in general. My Dad’s staff was having a hard time not getting pigeon holed by the submitted designs and Setfive wasn’t doing a great job helping them along.

We did our best and we felt like the entries were moving in the right direction. Then the contest closed. In the last 8 hours of the contest the number of entries nearly doubled. With 70 entries we now had the problem with objectively picking a winning logo.

At this point, I wanted some more input on what people thought about the logos. I decided to create a set of Amazon Mechanical Turk tasks to get some feedback.

After about a day, I had 200 responses asking for user’s top three logos and any additional comments they had.

Some of the comments I got back were insightful and moving:

  • Don’t pick any of the logos on the second page. They all look terrible.
  • Due to nature of your business I would prefer a sober and serious looking logo.
  • I chose these three because they are visually appealing, and convey a sense of being able to ease pain.
  • I suffer from cronic pain. I wish you the best of luck in finding your logo. People that do your type of work are a life line for people like me. Hope I hope have helped.

I tallied up the results by weighting +3, +2, +1 for first, second, and third choices respectively. The results were interesting.

  • Every logo received at least one vote.
  • The top ten logos accounted for just about 41% of all the votes.
  • Only counting the top choice caused 3 logos to fall out of the top ten.

The top ten logos as voted by the Amazon Mechanical Turks were:

Entry ID Votes URL



















Personally, I like the top ten logos and my Dad’s staff seems to like many of the same logos that were voted up. It’s been an interesting experiment almost exclusively using the “crowd” to design and then select a logo. I’m not sure if we’ll use 99designs in the future but it has been a pleasant experience.

We still haven’t picked a winning logo but I’ll update once we do!


We finally picked a winner! We decided to go with the crowd and selected as the winning logo.

Client side RSS aggregator

One of our clients came to us a few days ago asking us if we could build something to aggregate several RSS feeds and then display it on their site.

Easy enough. Except the caveats were 1) This had to be done on a shoe string budget and 2) We had no permission to script on the server side (only client side scripting allowed kids).

We put our heads together and realized that Yahoo Pipes would provide the functionality to easily combine several RSS feeds, sort them, filter them, ect. And best part? It’s all built and all free. Pipes also provides the functionality to export a pipe as a JSON feed (as opposed to RSS).

So that takes care of problem 1 and almost fixes problem 2. Of course the remaining problem is getting around the cross domain XHR restrictions on the JSON. I did some poking around the Yahoo Pipes documentation and it turns out you can add a _callback parameter to the URL and bang it wraps the JSON in a JS callback!

Issues solved. The final part was to mix in a little jQuery to load the JSON+callback feed into a <script> tag and then display it.

Total lines of code: 27 lines of javascript.

EDIT. Now with code!