Hacker News Reader

Comment by progne | Hacker News Reader

In a Ruby app we just convert to a high base, like

  > 1234567890.to_s(36)
  => "kf12oi"

That gets us most of the way there, but Sqid has a Ruby library and lets you set a much higher base, including upper case characters, and I suppose, emoji. We're going to need much bigger numbers before that space savings makes much difference. I like it, but it's hard to know when something like that is worth adding a dependency.

View on HN

BaseEmoji is a thing: https://github.com/amoallim15/base-emoji

Ironically its default encoding is base 55. I figured if you're going to use emoji you should at least use the size of the space to maximize the numbers of bits per grapheme beyond what is possible with ASCII, but apparently not.

Which I guess is the part where senior (citizen) programmers like me get triggered as promised in the README.

I believe a big part of the idea is for the hash to be unpredictable as well.

If I figure out you're using (36) then I know the next number 1234567891 is "kf12oj".

Not the case with Sqids.

You can easily brute-force this. Sqids also says it's not good for sensitive data.

It looks like an easy brute force too, there's no compute-hard operations here. I guess you could scramble your alphabet? Otherwise Uk always comes after bM, etc.

My understanding is that you can re-order the source alphabet, and encode numbers with swapped characters. Unless you know of 36 numbers that they're exactly 1 id apart, you will always have uncertainty to what the ids actually map to.I guess given a large, large number of ids along with the order they're assigned (which might be given through the time at which they're assigned), you could create a pribabilistic statement on the actual order of the 36 characters based on the fact that most numbers increase/decrease faster the bigger they are. (this fact is e.g. used to detect fabricated bank statements - if the first digit of any number in the statement is equally likely to br 1 or 9, the numbers are randomly generated whereas if they're real, 9 is less likely than 1)

Scambling the source alphabet should have an effect similar to a monoalphabetic substitution cypher. This is not strong cryptography. If the attacker has any ability to generate IDs quickly, like by creating user accounts or other resources they can create many IDs with known ordering. Likely effective against non-serious attempts.

Yeah this is very much the bad kind of DIY crypto.

I'd prefer to use crockford-encoded entropy with Stripe-style token prefixes to create unique ID namespaces. Run in through a bad words filter, and it's perfect.

user_1hrpt0xpax7ps

file_xpax7psaz0tv6az0tv6

Etc.

In distributed systems you can use the trailing bytes to encode things like author cluster, in case you're active-active and need to route subsequent writes before create event replication.

Easy to copy, debug, run ops/incall against. If you have an API, they're user-friendly.

Of course you still want to instruct people the prefixes are opaque.

Yeah don’t forget the bad words filter. I worked on an IKEA mailing where the list processing house was adding an autogenerated discount code to the address label. The customers received codes with BOOB, DICK, TWAT, and CUNT embedded within. People were not happy.

Did they never make an IKEA purchase after that or did they get over it like a normal adult?

I don't work retail, but something tells me people will make a stink out of just about anything if it meant potentially free products or other compensation.

Plus, are you filtering just English curse words or all curse words for countries that use Latin characters?

The risk is not in offending someone, but in that someone posting the rude string on social media in real or mock indignation, causing the outrage machine to turn on your brand. There’s a steady supply of bottom-feeding journalists waiting to write the article “IKEA’s new system is sending hate messages to customers”.

Can you cite an example of a journalist writing an article that makes such an accusation?

We caught it about 2 million into a 15 million print run. I had to go through the control files and change the offending value or identify the pallet and bundle of mail it was in so we could remove and readdress the catalog. It was about 10 years ago and anyone who complained got a coupon.

The mailing house that did the work was fired though.

this is very interesting. do you know how amazon creates its order id ? they are all numeric

Correct me if I'm wrong, but, It cannot be unpredictable, which makes the library redundant for security concerns, which would be the one business case to seek for anything other than an UUID (which is already built into Ruby).

No, squids are predictable, you can't use them to hide information.

They call it out on their front page.

I haven't looked at the implementation yet but HashIds (the former project name) required a salt. It would be weird if they changed that.

The `salt` in hashids just shuffled the alphabet. Now they removed the `salt`, but you can have the same level of "obfuscation" as before if you shuffle the alphabet yourself before calling the library.

They're weakly unpredictable.

Obfuscated

I didn't think of that, but this is a nice trick!

Reply on news.ycombinator.com