Obfuscate your Company
Time to read:
May 28, 2009
Autor:in:
Dieser Beitrag ist Teil des Twilio-Archivs und enthält möglicherweise veraltete Informationen. Sehen Sie sich unsere neuen Beiträge an, um über aktuelle Innovationen und Einblicke von Twilio auf dem Laufenden zu bleiben.
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!
Ähnliche Ressourcen
Twilio Docs
Von APIs über SDKs bis hin zu Beispiel-Apps
API-Referenzdokumentation, SDKs, Hilfsbibliotheken, Schnellstarts und Tutorials für Ihre Sprache und Plattform.
Ressourcen-Center
Die neuesten E-Books, Branchenberichte und Webinare
Lernen Sie von Customer-Engagement-Experten, um Ihre eigene Kommunikation zu verbessern.
Ahoy
Twilios Entwickler-Community-Hub
Best Practices, Codebeispiele und Inspiration zum Aufbau von Kommunikations- und digitalen Interaktionserlebnissen.