TL;DR: I spent a little over 6 days building an internal URL shortener built around security and transparency that has been used nearly 1 million times. This had absolutely nothing to do with my usual work at Salesforce!

One of the great benefits provided to technology employees here at Salesforce is the ability to spend 6 days a year on any sort of project we want, whether it’s adding a feature that hasn’t been prioritized to one of our products or doing something completely unrelated. This program is called Paid Time On (PTOn!) and the intent is to give engineers time to do things they are passionate about with the goal of improving careers for employees (and maybe even have Salesforce benefit from some of those efforts).

I found myself in a transition period between projects and decided to do something that several people had been requesting for a while: an internal URL shortener.

Why did we need Yet Another URL Shortener™?

The problem with most URL shorteners is that you have no idea where you are going to end up until you are already there (e.g., url.shortener/randomurl could easily redirect you to a malicious site and you wouldn’t know it until the redirect had already happened.) I wanted to build something that considered transparency and security from the beginning.

Initial Development

Since this was a side project, I didn’t want to spend a ton of time worrying about how and where to host/scale it. I was also interested in getting experience with a new technology/platform, so I chose to host the application on Heroku.

Heroku is great because deployment is as simple as a git push and it supports a wide variety of popular languages. It’s also awesome because it’s part of the Salesforce family 🙂

Next, I needed to decide on what language I was going to use.

Keeping with the theme of  wanting to learn something new (but realizing I only had 6 days) I chose Java (a language I’m very familiar with) but I also chose the Play Framework (something I had no experience with at all). It turns out Play is incredibly easy to use but it does have some performance issues (potentially a topic for another post).

Now that I had my hosting and technology stack determined, it was time to start writing code.

I started off writing the Base62 algorithm for doing the actual URL shortening, writing the models for interacting with the database (incredibly easy with Play,) and throwing a simple UI (powered by Twitter Bootstrap) on top of it all. From deciding on Heroku until this point, I had invested about 1.5 days and had a functioning URL shortener.

But what about security and transparency?

Security

Because the audience for Shrink was intended to be only Salesforce employees, it made sense to have a domain whitelisting feature: only allow URLs to be shortened that were part of a limited list of domains.

In addition, I integrated with Google’s Safe Browsing API to prevent the shortening of any known spyware/malicious sites.

Lastly, only employees that had signed in to the Salesforce Single Sign On system would be allowed to add URLs.

The whitelist and Safe Browsing checks happen not only at the time the URL is added but also each time the redirect occurs. This ensures that URLs were safe not only at the time they were shortened but that they remain safe in the future (or the redirect will not be allowed to happen).

Transparency

Just because the URLs made it through the security checks doesn’t mean that the concept of blind redirection is a good one.

Therefore, I chose to insert an interstitial page that is displayed to the user just before the redirect happens.

This page tells the user where they are going to be redirected to and gives the user 5 seconds to stop the redirect if they don’t feel comfortable.

The user can choose to continue, to stop the redirect, or do nothing at all and be redirected automatically after 5 seconds. The user also has the option of skipping the interstitial for all future redirects if they feel so inclined.

Initial Launch

By this time, my 6 days were up so I went ahead and launched my URL shortener, throwing out an announcement about it to our internal Chatter instance.

The response was amazing.

I immediately starting getting all sorts of feedback. I knew I was going to have to spend some more time on this project so I started thinking of ways to get more time to work on it.

Fortunately, the answer was kind of obvious: Hackdays!

Additional Features (Hackday!)

One of the biggest feature requests I received was the ability to track stats for each shortened URL, such as total number of clicks, referrers, browsers, etc.

When the next hackday came around, I knew that was going to be what I worked on.

The question was, how did I want to display these stats to the user?

I started off having a custom stats page for each URL, using JavaScript to render the charts. Then I realized we have this awesome new analytics product called Wave that was perfect for this sort of thing, so I started pushing all of the stats into a custom Wave application:

Using the power of Wave, any Shrink user can go in and find all sorts of information using several different vectors.

Results

Shrink originally launched in April of 2014 and is limited to use by only Salesforce employees (~16,000).  As of August 2015, there have been nearly 1 million redirects! I never expected this kind of adoption, but I am incredibly thankful that Salesforce gave me the opportunities with PTOn! and Hackdays to be able to make such a large impact on our employee base.

If you’d like to work at an awesome company that encourages you to do awesome work, know that Salesforce is hiring! Visit http://www.salesforce.com/tech to find your #dreamjob.