Dealing with ROT13 Encoded URLs

3 minute read

DailyStory tracks link clicks in emails sent out in our customer’s email marketing campaigns. Recently we were auditing these click logs and noticed some weird URLs:


After a bit of Googling we figured out that these were URLs that were first URL-encoded then run through a ROT13 substitution cipher.

First a little background on DailyStory tracking links.

DailyStory Tracking Links

When you create an email in DailyStory and the email contains links those links are replaced with a tracking link. When a link is clicked some information is sent back to DailyStory and then the browser is redirected to the original URL.

For example, below is a URL that could be included in an email:

First we encode the original URL:


Next that URL is appended to the redirect tracking link which is inserted into the email.


When someone clicks on the URL in the email they make a quick stop at DailyStory. They are then immediately redirected to the original URL.

Later, DailyStory logs the URL the browser was redirected to. Now DailyStory customers can see what links are getting clicked in the emails they send out.


So how did we end up with a ROT13 URLs in our logs that look like this:


And what is ROT13 and why are URLs showing up like this with a uggc protocol?

After a bit of Googling we discovered something called the Encrypted Hypertext Transfer Protocol.

Encrypted Hypertext Transfer Protocol

This specification dates back to 2001. And let’s be really clear: nothing about this is encrypted. This appears to be a specification that predates Secure HTTP.

Here is a summary of the purpose of uggc URLs:

It’s a known fact that web surfing has become a much more important activity in the net than what was expected six years ago. Anti-prying measures have been taken in other services (mail encryption, for example), but haven’t been in WWW: anyone can spy at what another user is browsing at the moment by intercepting his packets and looking at their content (“sniffing”). This document proposes a method that guarantees it won’t happen anymore, by discouraging the act of sniffing.

A new URL, ‘uggc’, is defined, which is a sort of twin brother to ‘http’. The former works in the very same way as the latter does, with the following exception: both URLs and the data travelling [SIC] from the client to the server and vice versa are encrypted. The data retrieved is equivalent, once decrypted back.

Apparently, as best we can tell, some anti-malware technologies have chosen to implement the Encrypted Hypertext Transfer Protocol.

This specification uses the ROT13 substitution cipher to make the parts of a URL hidden so that would-be-attackers who are able to access the URL  cannot infer the meaning.

The basis of the specification is use ROT13.

What is Rot13?

From Wikipedia: ROT13 (“rotate by 13 places”, sometimes hyphenated ROT-13) is a simple letter substitution cipher that replaces a letter with the 13th letter after it, in the alphabet. ROT13 is a special case of the Caesar cipher which was developed in ancient Rome.

ROT13 takes text such as:

Why did the chicken cross the road?

And converts it into:

Gb trg gb gur bgure fvqr!

Again, nothing about ROT13 is creating any kind of encryption.

Working backwards from uggc and ROT13

I’ll admit, it took a few hours to figure out what in the world was going on with these URLs. Clearly they were URL encoded, but the encoding made no sense.

We used to decode the ROT13 encoded version. After that it was obvious it was a valid URL encoded string.

We’re planning to add support for ROT13 URLs. If we detect that the URL is a uggc link, we’ll decode it and make sure the link works as it should.

Helpful links if you’re reading up on ROT13:


Want to receive more great content like this for free?

Subscribe to our newsletter to get best practices, recommendations, and tips for digital marketers