Hacker News Reader

Comment by blotter_paper | Hacker News Reader

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.

View on HN

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

[1] https://pex.com

Since it's not listed on the site, what are the costs for the services pex offers?

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-19ec...

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.

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.

>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.

Reply on news.ycombinator.com