Obfuscate your Company
Time to read:
May 28, 2009
Redactado por
Esta publicación es parte del archivo de Twilio y puede contener información desactualizada. Siempre estamos construyendo algo nuevo, así que asegúrate de revisar nuestras publicaciones más recientes para obtener la información más actualizada.
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!
Recursos relacionados
Twilio Docs
Desde API hasta SDK y aplicaciones de muestra
Documentación de referencia de API, SDK, bibliotecas auxiliares, inicios rápidos y tutoriales para su idioma y plataforma.
Centro de Recursos
Los últimos libros electrónicos, informes de la industria y seminarios web
Aprenda de los expertos en participación del cliente para mejorar su propia comunicación.
Ahoy
Centro de la comunidad de desarrolladores de Twilio
Mejores prácticas, ejemplos de códigos e inspiración para crear comunicaciones y experiencias de participación digital.