4 ms·

Skipping profanity seems like a liability in this design. It means in order to preserve the encoding you need to make the banned word list immutable, otherwise

Skipping profanity seems like a liability in this design. It means in order to preserve the encoding you need to make the banned word list immutable, otherwise old sqids will decode to the wrong thing when you get them back.

Etheryte 3y ago
I don't think this holds, you can enforce filtering in the encoding step, i.e. be strict about what you output, but always decode, even if the input is profanity. This means you can also be backwards compatible if you update the list etc. So in short, the old maxim of be strict about your outputs and lenient about your inputs.
- fimdomeio 3y ago
  From their FAQ: "The best way to ensure your IDs stay consistent throughout future updates is to provide a custom blocklist, even if it is identical to the current default blocklist."
  - Etheryte 3y ago
    In that case it sounds like a shortcoming on their part. There is no fundamental reason to have that limitation. I understand it can make the implementation easier to not have it, but in my opinion being blocklist change agnostic would be a much better value offering.
  - lights0123 3y ago
    The *encoding* changes. The decoding stays consistent: > Decoding IDs will usually produce some kind of numeric output, but that doesn't necessarily mean that the ID is canonical. To check that the ID is valid, you can re-encode decoded numbers and check that the ID matches. The reason this is not done automatically is that if the default blocklist changes in the future, we don't want to automatically invalidate the ID that has been generated in the past and might now be matching a new blocklist word.
runlevel1 3y ago
The stupid simple way I did this ages ago was: 1. Start with a-z. 2. Drop all vowels, numbers, most homoglyphs, and the letter 'x'. 3. Map digits 0-9 to one of the remaining letters. 4. Stringify the integer and replace the digit in each decimal place with its corresponding character. For my use-case, all the numbers were >7 digits long, so the odds of you getting an offensive acronym were reasonably low unless you started combining them. But there's no perfect solution. As this dataset shows, you can find offense in almost anything if you look hard enough: California Personalized License Plate Requests Flagged for Review 2015-2016: https://docs.google.com/spreadsheets/d/18IUVU9Q4uN_lxqNd5AsNvsdT8V3L4IUA2Nz_VWA7Lzs/edit?usp=sharing https://docs.google.com/spreadsheets/d/18IUVU9Q4uN_lxqNd5AsN...
- arp242 3y ago
  Many of those reviewer comments are utterly moronic. And that is my polite opinion. How does this work? Is there a review board? Is it put to public review? A few of them like "dick out" and "shtlord" are reasonable, but many of them seem so bonkers it looks like the work of trolls. Anyway, TIL that 1970s Intel was a MS-13 gang outfit and that Octocat really means "eight vaginas".
  - Zecc 3y ago
    > Many of those reviewer comments are utterly moronic. Reason for review: hostile, insulting, or degrading /s
    - arp242 3y ago
      WONTFIX: behaves as intended.
- air7 3y ago
  > California Personalized License Plate Requests Flagged for Review 2015-2016: https://docs.google.com/spreadsheets/d/18IUVU9Q4uN_lxqNd5AsN https://docs.google.com/spreadsheets/d/18IUVU9Q4uN_lxqNd5AsN... Wow this is a funny peek into a weird perdicment where people need to justify that they have a good reason to have a specific license plate. Some seems obviously ok such as: INT13H 314 PI And some are obviously not: DRY(hand emoji)JOB DICK OUT Come to think of it: Can license plates have emojis now?!
8organicbits 3y ago
Agreed, this is a big risk made worse that the default word list can change over time. https://sqids.org/faq#future-blocklist https://sqids.org/faq#future-blocklist
- rafram 3y ago
  It should at least take a blocklistVersion parameter (or similar), even if passing the wrong version just generates an error.
kaetemi 3y ago
It's a base62 encoder that takes multiple integers as input. Probably a bit-length prefixed encoding. I am assuming it just pads an extra junk integer to re-roll the encoded number.

Etheryte 3y ago

I don't think this holds, you can enforce filtering in the encoding step, i.e. be strict about what you output, but always decode, even if the input is profanity. This means you can also be backwards compatible if you update the list etc. So in short, the old maxim of be strict about your outputs and lenient about your inputs.

fimdomeio 3y ago
From their FAQ: "The best way to ensure your IDs stay consistent throughout future updates is to provide a custom blocklist, even if it is identical to the current default blocklist."
- Etheryte 3y ago
  In that case it sounds like a shortcoming on their part. There is no fundamental reason to have that limitation. I understand it can make the implementation easier to not have it, but in my opinion being blocklist change agnostic would be a much better value offering.
- lights0123 3y ago
  The *encoding* changes. The decoding stays consistent: > Decoding IDs will usually produce some kind of numeric output, but that doesn't necessarily mean that the ID is canonical. To check that the ID is valid, you can re-encode decoded numbers and check that the ID matches. The reason this is not done automatically is that if the default blocklist changes in the future, we don't want to automatically invalidate the ID that has been generated in the past and might now be matching a new blocklist word.

runlevel1 3y ago

The stupid simple way I did this ages ago was: 1. Start with a-z. 2. Drop all vowels, numbers, most homoglyphs, and the letter 'x'. 3. Map digits 0-9 to one of the remaining letters. 4. Stringify the integer and replace the digit in each decimal place with its corresponding character. For my use-case, all the numbers were >7 digits long, so the odds of you getting an offensive acronym were reasonably low unless you started combining them. But there's no perfect solution. As this dataset shows, you can find offense in almost anything if you look hard enough: California Personalized License Plate Requests Flagged for Review 2015-2016: https://docs.google.com/spreadsheets/d/18IUVU9Q4uN_lxqNd5AsNvsdT8V3L4IUA2Nz_VWA7Lzs/edit?usp=sharing https://docs.google.com/spreadsheets/d/18IUVU9Q4uN_lxqNd5AsN...

arp242 3y ago
Many of those reviewer comments are utterly moronic. And that is my polite opinion. How does this work? Is there a review board? Is it put to public review? A few of them like "dick out" and "shtlord" are reasonable, but many of them seem so bonkers it looks like the work of trolls. Anyway, TIL that 1970s Intel was a MS-13 gang outfit and that Octocat really means "eight vaginas".
- Zecc 3y ago
  > Many of those reviewer comments are utterly moronic. Reason for review: hostile, insulting, or degrading /s
  - arp242 3y ago
    WONTFIX: behaves as intended.
air7 3y ago
> California Personalized License Plate Requests Flagged for Review 2015-2016: https://docs.google.com/spreadsheets/d/18IUVU9Q4uN_lxqNd5AsN https://docs.google.com/spreadsheets/d/18IUVU9Q4uN_lxqNd5AsN... Wow this is a funny peek into a weird perdicment where people need to justify that they have a good reason to have a specific license plate. Some seems obviously ok such as: INT13H 314 PI And some are obviously not: DRY(hand emoji)JOB DICK OUT Come to think of it: Can license plates have emojis now?!

8organicbits 3y ago

Agreed, this is a big risk made worse that the default word list can change over time. https://sqids.org/faq#future-blocklist https://sqids.org/faq#future-blocklist

rafram 3y ago
It should at least take a blocklistVersion parameter (or similar), even if passing the wrong version just generates an error.

kaetemi 3y ago

It's a base62 encoder that takes multiple integers as input. Probably a bit-length prefixed encoding. I am assuming it just pads an extra junk integer to re-roll the encoded number.