I’m writing a script that scrolls through the site, scrapes the UUIDs, and stores them in an AWS S3 bucket. I’ll let you know when it finishes.
What will be the bill?
I think all the money
Every V4 UUID
351–360 of 381 posts
Re: Every V4 UUID
#352Very useful! I'll refer to it when I forget my UUIDs, I use this site all the time to remember my bitcoin private key [0] [0]: https://privatekeys.pw/keys/bitcoin/1
I'm sure there are people who will search for their actual private key, potentially leaking it.
Re: Every V4 UUID
#353Earlier quoted context omitted.
See also: https://keys.lol/
I was going to "see also also" you with https://libraryofbabel.info/ but RIP for it is dead. https://en.wikipedia.org/wiki/The_Library_of_Babel_(website)
Wow I hope that's temporary - I looked at the site less than a month ago and it was still up.
Re: Every V4 UUID
#354perfect website for mouse scroll wheel benchmark
Re: Every V4 UUID
#355Barely related tangent - but the speed of how quickly this site populated the full list of all these UUIDs (it's likely static) made me remember this site https://unicode.org/emoji/charts/full-emoji-list.html which seems to programmatically generate the page every single time (are there that many new emojis that this is needed) and as a result the page takes minutes to load (I've never let it finish).
Re: Every V4 UUID
#356Earlier quoted context omitted.
Sufficiently advanced technology is indistinguishable from magic, as the saying goes.
But the Terry Pratchet quote above indicates that magic is only skin deep
We might then interpret Pratchet to be commenting on the floor and mode of "sufficiently advanced" ("skin deep")!
Re: Every V4 UUID
#357Earlier quoted context omitted.
I'm really happy that the trick was magical to you - I was so surprised and delighted when I realized that this was possible, and I wasn't really sure if anyone else would feel the same way! And of course, I'm proud to be providing so much utility here - finally we can find and use UUIDs tailor-fit to our needs
FWIW, "search" doesn't work on mobile (Chrome on Android): I go to "Find in Page" and none of the magic happens. It's also bypassed on desktop when I manually open the search box via Edit->Find->Find... instead of using Ctrl+F. I wonder if there's (yet) a browser API you could hook into: the same way browsers allow JavaScript to manipulate the history [1], maybe there's a way to manipulate the Ctrl+F/find-in-page sea…
There's a button in the bottom right so you can access the search functionality from the UI that allows you to use their search on mobile.
This may have been added after your comment.
Re: Every V4 UUID
#358Earlier quoted context omitted.
PINs can be up to 6 digits (at least here in the UK, but I doubt it's country specific), even though the ones they give you by default are only ever 4. So that's only a leak of 1% of them.
It helps, but only temporary. I wouldn't be surprised if all 6 digit PINs will be leaked within a few decades.
Not to worry. We'll just switch to 8 digit PINs and we'll be safe once and for all.
Re: Every V4 UUID
#359Earlier quoted context omitted.
PINs can be up to 6 digits (at least here in the UK, but I doubt it's country specific), even though the ones they give you by default are only ever 4. So that's only a leak of 1% of them.
Does that not cause problems on some card machines? I've come across a few that definitely don't let you put in more than four digits.
Surprisingly, no, or at least it's not common.
I'm from a country that has 6-digit PINs on most cards, and I've traveled to e.g. the United States where people are surprised that credit card PINs can be more than 4 digits, but in my experience, terminals accept them just fine. It seems like they are designed to suggest a PIN is only 4 digits but they will happily accept more. So while you're entering your PIN, the display looks something like:
[....]
[*...]
[**..]
[***.]
[****]
[*****]
[******]
Re: Every V4 UUID
#360Earlier quoted context omitted.
The full text search is a little confusing because it doesn't actually search them in order, though it appears to at first. And if you click "next" a few times and then "prev" the same number of times, you don't necessarily end up back at the same UUID you were at before. It's a neat-seeming trick though.
It’s an interesting question whether that could be fixed. I think the answer is Yes. If the author didn’t do any scrambling, and just displayed UUIDs in numeric order, then it’s trivial to enumerate search results in order. Likewise, if you do something like adding a constant mod 16 to each hex digit, you could do the same thing when you generate UUIDs matching a substring. So the question becomes whether you could f…
Yes, it's possible with certain restrictions on the function. Here's an example:
u128 uuid_iter(u128 x) {
b = (x * x | 0x5) + x;
c = prf(x);
return (b ^ (c You can invert this by just running the function N times to test each bit from LSB to MSB against the result. If you know certain bits, you don't have to run those tests and you can order the matching UUIDs by the values of the K unknown bits from 0 to 2^(N - K) - 1.
You also don't need to keep track of the position with this method either, only a stopping point. Unlike the feistel network, this function also produces a full cycle when iterated as x_i+1 = f(x_i), only repeating after all numbers are produced. That means you could run this without a counter at all, just generating until the first value is produced again, for any bit length.