3 ms·

What do you like about the Vine ID alphabet? I don't see the appeal, it cuts out some characters yet still includes potentially confusing ones (I/l/1 and O/0, w

What do you like about the Vine ID alphabet? I don't see the appeal, it cuts out some characters yet still includes potentially confusing ones (I/l/1 and O/0, which can look identical or nearly identical in some fonts). If not human readability, why did they cut out standard characters thus making IDs longer than necessary? I suspect there is a perfectly reasonable explanation, but I'm missing it.

doh 7y ago
My guess is that they used this as a security through obscurity [0]. They hoped that nobody will be able to reverse back the alphabet if they don't get their hands on real IDs. Because we [1] crawl every video/audio site, we had all the links for vine. I just took 1,000 consequential IDs (based on creation time) and then worked backwards on the alphabet. Took maybe 10 minutes to write the code. [0] https://en.wikipedia.org/wiki/Security_through_obscurity https://en.wikipedia.org/wiki/Security_through_obscurity [1] https://pex.com https://pex.com
- trenning 7y ago
  Since it's not listed on the site, what are the costs for the services pex offers?
  - doh 7y ago
    Depends on the service. We are currently closed to only certain customers, although our attribution engine [0] is completely free to _all_ rightsholders. [0] https://blog.pex.com/introducing-the-attribution-engine-19eccd3441a9 https://blog.pex.com/introducing-the-attribution-engine-19ec...
crazygringo 7y ago
To me the randomized characters are a clever way of hiding "autoincrement" to users, so it would be non-trivial to calculate the number being produced daily. Picking base 49 (a seemingly random number) seems to be perhaps a similar security-through-obscurity thing? I've written code to produce random (non-sequential) ID's for storage in a database, but it's surprisingly non-trivial to produce a performant INSERT that will work without ever producing collisions. Relying on the database's AUTOINCREMENT but obfuscating the value through a baseXX encoding seems actually much easier, when the only "security" you're trying to provide is against reporters and business analysts trying to estimate the site's usage/popularity, and they're quite unlikely to bother to reverse-engineer your encoding scheme.
- doh 7y ago
  Can vouch for the non-triviality of collisions. We have around 500k inserts a second and wanted to have time sensitivity between them (so essentially basic in on a timestamp) and fit it into 64bit unsigned integer. We managed to get a safe space of around 50M per second, so we could safely use shard_id to prevent collisions.
- gruez 7y ago
  >Relying on the database's AUTOINCREMENT but obfuscating the value through a baseXX encoding seems actually much easier I don't buy this explanation. If you really cared about security, you'd encrypt the number (preferably through a block cipher). Using a weird encoding system only provides marginal security, as evidenced by this post.

doh 7y ago

My guess is that they used this as a security through obscurity [0]. They hoped that nobody will be able to reverse back the alphabet if they don't get their hands on real IDs. Because we [1] crawl every video/audio site, we had all the links for vine. I just took 1,000 consequential IDs (based on creation time) and then worked backwards on the alphabet. Took maybe 10 minutes to write the code. [0] https://en.wikipedia.org/wiki/Security_through_obscurity https://en.wikipedia.org/wiki/Security_through_obscurity [1] https://pex.com https://pex.com

trenning 7y ago
Since it's not listed on the site, what are the costs for the services pex offers?
- doh 7y ago
  Depends on the service. We are currently closed to only certain customers, although our attribution engine [0] is completely free to _all_ rightsholders. [0] https://blog.pex.com/introducing-the-attribution-engine-19eccd3441a9 https://blog.pex.com/introducing-the-attribution-engine-19ec...

crazygringo 7y ago

To me the randomized characters are a clever way of hiding "autoincrement" to users, so it would be non-trivial to calculate the number being produced daily. Picking base 49 (a seemingly random number) seems to be perhaps a similar security-through-obscurity thing? I've written code to produce random (non-sequential) ID's for storage in a database, but it's surprisingly non-trivial to produce a performant INSERT that will work without ever producing collisions. Relying on the database's AUTOINCREMENT but obfuscating the value through a baseXX encoding seems actually much easier, when the only "security" you're trying to provide is against reporters and business analysts trying to estimate the site's usage/popularity, and they're quite unlikely to bother to reverse-engineer your encoding scheme.

doh 7y ago
Can vouch for the non-triviality of collisions. We have around 500k inserts a second and wanted to have time sensitivity between them (so essentially basic in on a timestamp) and fit it into 64bit unsigned integer. We managed to get a safe space of around 50M per second, so we could safely use shard_id to prevent collisions.
gruez 7y ago
>Relying on the database's AUTOINCREMENT but obfuscating the value through a baseXX encoding seems actually much easier I don't buy this explanation. If you really cared about security, you'd encrypt the number (preferably through a block cipher). Using a weird encoding system only provides marginal security, as evidenced by this post.