only 32bits, so 4 billion guesses per microsecond... Even if youtube has 1 million videos per microsecond you would never guess them before rate limits.

▲

8organicbits 8 hours ago | parent | next [-]

You're mixing a couple things. The 32 bit random occurs in the Python implementation, which uses a millisecond counter.

The numbers you provided are suspicious, but seem quite feasible to attack. 1M IDs in 4B means each guess has ~ 1-in-4000 chance. You can make 4000 requests in an hour at a one-per-second rate. A successful attack can guess one ID, it doesn't need to enumerate all of them.

	▲	bearjaws 6 hours ago \| parent [-]
		Ah I was looking at the pg_uuidv7 python package. The backwards compatibility is a wild trade off. Either way my comment was hyperbole, but the concept is the same, 10000 records per millisecond and you get the point. For 99.999% of SQL use cases UUIDv7 is good. I only advocate for UUID so much because 3 separate times in my career I have been the one to have to add UUIDs so we don't leak number of patients, let users scrape the site by just incrementing (amongst other protections). So much easier to just UUID everything.

▲

Incipient 5 hours ago | parent | prev [-]

Not sure if this is helpful here, but you're still looking at 32 bits of randomness, regardless of the time window. Use it for anything that you feel that's enough randomness to secure - a private home video of a cat braking a cup? Sure.

File sharing endpoints for a business? No. Use another uuid4 based 'sharing uuid' that you map internally to the PK uuid7.