5 ms·
Also, using a numerical auto-incrementing ID in the URL will expose how many users you have so far. Not a problem for Stack Overflow, but I’ve had clients (star
by adrianmsmith 7y ago
Also, using a numerical auto-incrementing ID in the URL will expose how many users you have so far. Not a problem for Stack Overflow, but I’ve had clients (startups) who wanted to put IDs in the URL, when you sign up and your URL is /profile/432 it’s quite clear the product doesn’t have many users.
- adjkant 7y agoAn easy solution to that is simply not to start at zero/one and pick a random number somewhere around 5-6 digits. Can do that at the database level or programatically.
- jstanley 7y agoIt's still easy for anyone to work out how fast you're gaining users. Just sign up for an account every day and note how much higher the new id is.
- thecatspaw 7y agoyou can also add zeroes (or other digits which get stripped before used for querying) at the end, that way the gain looks orders of magnitudes faster
- jstanley 7y agoSure, but anyone signing up for 3 accounts in quick succession can probably figure out what you're doing. All of these problems go away if you just assign random numbers instead.
- TeMPOraL 7y agoWhy would honest people want to spend time implementing ways to lie to their users? Because that's what we're talking about here. (And I know I'm asking a rhetorical question.)
- jstanley 7y agoAssigning random ids isn't lying to your users, unless you also make representations that the user id corresponds to the number of users that there are.
- verbify 7y agoWhile there might be some edge cases (e.g. startups associated with a high profile brand/person), in most cases there are usually better things for a startup to do than obfuscate the number of users they're gaining.
- treve 7y agoA slightly more advanced version of this to XOR the number with some other number.
- codetrotter 7y agoSimply doing XOR on two integers doesn’t really provide meaningful obfuscation if one of the inputs are constant as I assume they would be in this case. For example: for i in range(25): 167535774 ^ i 167535774 167535775 167535772 167535773 167535770 167535771 167535768 167535769 167535766 167535767 167535764 167535765 167535762 167535763 167535760 167535761 167535758 167535759 167535756 167535757 167535754 167535755 167535752 167535753 167535750 for i in range(250000,250025): 167535774 ^ i 167752718 167752719 167752716 167752717 167752714 167752715 167752712 167752713 167752710 167752711 167752708 167752709 167752706 167752707 167752704 167752705 167752766 167752767 167752764 167752765 167752762 167752763 167752760 167752761 167752758
- eli 7y agoAt that point your requirements seem to require a number with no pattern, so it should probably just be a random unique number or string. But for a lot of use cases the ability to measure growth or enumerate URLs doesn't matter.
- petepete 7y agoALTER SEQUENCE users_id_seq RESTART WITH 54321; "Wow, this service is probably mature, well-tested and reliable!"
- zepolen 7y agoAmateur - you have to do over 1 million or you're not web scale.
- lifthrasiir 7y agoNote that there is a legitimate reason to set the initial sequence in this way: oftentimes the system works fine with 31/32-bit numbers but not with larger ones. Starting with the large sequence number (we have frequently used 10 billion) proactively eliminates this problem.
- koolba 7y agoAnd then come back a week later to see that 500001 => 500004...
- TeMPOraL 7y agoThe number of users who notice the user ID is a small fraction of your total users. The number of users who would notice the ID didn't grow much over the week is a small fraction of that fraction.
- zAy0LfpBZLC8mAC 7y agoNamely, cour competition that tries to figure out what to do about you or whether to even care, yes.
- dexterdog 7y agoExactly. I have done this in research on competition many times.
- deleted 7y ago[deleted]
- ponytech 7y agoThis is why I always obfuscate IDs using Hashids: https://hashids.org https://hashids.org
- zepolen 7y agoHashids are slow though
- branko_d 7y agoJust use GUIDs instead. And if you want to keep using integer IDs internally, put the GUIDs into an alternate key.
- varelaz 7y agoGUIDs are really unreadable and long. You can read and remember some numeric ID, but GUID/UUIDs – totally impossible. I hated them after Microsoft COM.
- joshstrange 7y agoI'm not sure I need "readable and short" to be qualities of my unique identifiers. I copy/paste and UUID/GUID I come across and if you have foreign keys setup you can jump around the DB in most GUI clients with ease, never even having to copy/paste. Furthermore when I'm talking with my coworkers we always just read off the 2nd "set" of numbers/letters in the UUID. In the example of `c495d443-cc7d-4030-840c-8f7e4e0289c3` I will just say "cc7d", 99.9% of the time that is enough to uniquely identify a UUID when we are only dealing with a handful of them and want to pick one out by eye quickly. For anything else I just send them a chat with the UUID and they can query on it, grep, or find it in the results with Ctrl+F or whatever their tools support doing.