Obfuscate your Company
Time to read: 2 minutes
May 29, 2009
Written by
When I was at Amazon, I remember a story from the days of yore, it went like this.
Amazon was about to go public, and all sorts of analysts were trying to determine Amazon’s sales and customer growth, obviously things the company would closely hold. At some point, some crafty analyst cracked open his browser (IE 3?) cookies from Amazon.com to find, and I’m cookie-paraphrasing here, the following contents:
CustomerId: 12345
Hrm, so Amazon had exactly 12345 customers as of the moment he signed up some while back. So, then he signed up for another account, and got a CustomerId 23456. Hrm, now he knew how many customers Amazon had gained. And by registering a new account every day, he could figure out their growth rate!
Company Secrets Fail.
So Amazon started obfuscating their customer ids in any customer-accessible places, like cookies, urls, etc.
So jump a head 10+ years, and I see see plenty of companies, often startups, who expose primary key values for things like customers, messages, orders, etc. in their URLs.
For example, I got this link today to an internal messaging system from a very young company:
I’ve redacted some of the variable names, so people can’t figure out which company it is. However, you can see primary keys for the message… and I received message #4! Hrm, now I know how popular the company, or this particular feature is. Interesting information.
I’ve always taken the view that such information is private to the company… and that leaking it out can come to give your customer, and more importantly, competitors an unwarranted view into your operations.
For example, another company in the telecom space, one you might call competitive to Twilio, happily shows me my integer, auto-incrementing Developer ID right on their dashboard:
Thanks for the intel, suckas!
At Twilio, we skip the easy INT AUTO INCREMENTs, and use MD5 hashes of good random strings to get consistent length, collision free distributed primary keys. They’re easy to generate in a distributed manner, no matter how many app-servers or databases you’re running, and they don’t leak any information about us as a company. For example, here’s one way to generate a random, fixed-length key in PHP:
md5(uniqid(rand(), true))
So, in my opinion, you’re best keeping private information private, and while you’re at it, get a nice distributed key generating system in place. But feel free to ignore this advice, your competitors will thank you!
Related Resources
Twilio Docs
From APIs to SDKs to sample apps
API reference documentation, SDKs, helper libraries, quickstarts, and tutorials for your language and platform.
Resource Center
The latest ebooks, industry reports, and webinars
Learn from customer engagement experts to improve your own communication.
Ahoy
Twilio's developer community hub
Best practices, code samples, and inspiration to build communications and digital engagement experiences.