Edit to add: I'd only tried searching for an exact UUID when I wrote this comment. I didn't realize it supports full text search! Now I'm even more impressed.
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
> If we didn’t care about generating valid UUID v4s, we could just generate 2^128 numbers, scramble them, convert the resulting bits into a hex string, and intersperse some dashes.
You can do that anyway. You'd only need the twiddling if you wanted to limit the amount of numbers you generate to 2^122. Since you're willing to generate 128 bits:
// get encrypted value
uint128 bits = encipher(seed);
// clear zero bits
bits &= 0xFFFFFFFF FFFF 4FFF BFFFFFFFFFFF; // instead of 4 and B, you can use 0 and 3
// set one bits
bits |= 0x00000000 0000 4000 800000000000; // these have to be 4 and 8
But since you're generating more numbers than you need, you're going to end up with 64 copies of each UUID in your final stream. This won't matter because no one will ever be able to notice, as long as your faux search functions avoid pointing it out.
Exercise for further development: modify substring search so that it follows the expected behavior of finding matches in order within the page. [I don't recommend attempting this.]
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 search results.
That is, right now you're capturing the Ctrl+F keypress and opening your own custom thing to read the user's search string and act on it. But what we'd really like is a way to be notified "The user just asked to search for 'xyz'. Would you like to capture that event, or let it go through to the browser's default behavior?"
A quick Google search found nothing like that exists yet. I then asked ChatGPT about it, hoping that ChatGPT would at least hallucinate a plausible design for the API — and had mixed feelings when it didn't. It just printed that 'Browsers do not provide a way to listen for the "Find in Page" search event due to privacy and security concerns' and suggested capturing the Ctrl+F keypresses exactly as you have done.
As someone else said, it would also be more like full-text search if you also considered the primary-key column, e.g. searching for "0390814603917539994005679487460590835" should jump to the 390814603917539994005679487460590835th row. (Highlighting-to-select pieces of the text also doesn't work: I'm not sure why not, since I would have thought the browser gives you at least that part for free.)
Besides "search" not working on mobile, the styling on mobile is such that the "scrolling" does not convince: to my eyes it looks too obviously like "changing the values in the cells of a fixed table" as opposed to "scrolling through the table itself." You could maybe mitigate that by animating quickly among three different page layouts with the table vertically offset by different amounts.
It occurs to me that if JavaScript has something like Python's `random.sample`-without-replacement, then you could set your `RANDOM_SEARCH_ITERATIONS` to 256 and achieve perfectly consistent (and exhaustive) "search" when the user has entered all but 1 or 2 hex digits of their desired result. And/or, you could just have the page secretly keep a history of the search results the user has already seen: this would prevent the user from finding out so quickly that "search + next + next + prev + prev" doesn't always get them back to where they started.
Speaking of exhaustive search results: With a bit more (probably equally algorithmically interesting) work, you could emulate the browser search's "7/256" by tallying up the number of UUIDs satisfying the constraint, e.g. if the user has typed "1234567" then you could display "1234567 (158456324585806817418058661888 results)" and maybe even fake up a convincing position indicator like "1234567 (17415833585801881134805987465/158456324585806817418058661888)". I guess if you display it as "1234567 (1.742e28/1.585e29)" then you don't even have to cheat that much. :)
A great example of Teller's observation that "sometimes magic is just someone spending more time on something than anyone else might reasonably expect."
My favorite of these was a trick where someone picked a card out of a deck and then Teller revealed a large version of that same card in an unexpected area in the vicinity, It turns out that what he had done was hide a complete set of large cards in the area before the trick and memorized the location of every one of them so, e.g., the king of hearts would be at the top of a palm tree, the three of spades under a drink tray, etc.
The explanation for full-text search was actually slightly more intelligent than what I initially assumed. I figured it just generated UUIDs until it found one that was in the correct direction of search (for the next/previous button), since I had observed that walking forwards and backwards in search results was giving different results each time, but in fact the author did the slightly better thing which is to just generate a bunch of possible results and then pick the best (I wonder how many results it generates for this?).
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 find something like that that gives a sufficiently convincing illusion of entropy but is still reversibile when you hold a subset of the digits constant. And it seems like it should be.
Searching is very similar to a common approach for building a naïve spellchecker: given an input, generate all the possible matches it can be part of. You're not searching in a corpus, you're using the input to generate indices into the corpus (list of UUIDs here, list of words in the dictionary in a spellchecker).
For the even more curious, UUID has 5316 decillion 911 nonillion 983 octillion 139 septillion 663 sextillion 491 quintillion 615 quadrillion 228 trillion 214 billion 121 million 397 thousand 304 values. Imagine the fact that there aren't as many kms to reach GN-Z11 (farthest known galaxy in the Universe I think) as there are digits above
The UIA (Universal Internet Authority) is worried that by using UUIDs we are left with only around 34 trillion UUIDs per star and planet in the observable Universe. So the cosmic router might become DHCP-leasing dark matter.
I searched for 1337, and then 13371337, and then 133713371337, and I was flabbergasted they've got a search setup for this (which ctrl-f opens up). Thanks for posting the blog post!
> The fact that the search works impressed me more than anything. Of course, like every great magic trick, it seems so simple once it is explained.
> Edit to add: I'd only tried searching for an exact UUID when I wrote this comment. I didn't realize it supports full text search! Now I'm even more impressed.
But the trick to the full-text search is that it doesn't work.
This is neat, although I pushed it later with incremental search and it seems to be skipping results as it only found ~50 when searching for `-000000000000`.
Yeah, I at first, I though I knew exactly how it worked. Then I saw the search field, and I suddenly had no idea what the hell was going on. Now, the big question, do I want to spoil the magic trick and read how this was done, or should I keep being astonished and flabbergasted?
I disagree with my sibling comment. The trick is beautiful. If you generate UUIDs such that each bit in the result can be reliably traced back to a single bit in the input, then you can take a substring of the UUID and use that to infer which bits of the input integer must be set to produce that substring. So you can produce a whole list of input bytes that meet the criteria and those become your search results.
The real magic trick here is that the uuids on the page only look random to us because of some bit twiddling and XOR trickery. If we had a better intuition for such things we would notice that successive UUIDs are just as correlated as successive integers.
Agreed. Everyone love puzzles that are worthy of an entire section in a blogpost for their interview questions, rather than stuff actually relevant to the job.
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.
Haha, I have a file in my home directory that has every possible SSN because I wanted to be able to tell a friend “I have your SSN in a file on my computer.”
I think this is a joke, but I think it is a problem if someone finds any sensitive uuid here, because the list on this website is a tiny subset of all possible uuids, so it provides a useful rainbow table for anyone attempting brute force attacks. I.e. generating and using random uuids would have an astronomically small success rate, whereas trying the ones on this site may not (depending on where they came from, which I'm not sure of).
> depending on where they came from, which I'm not sure of
They're coming straight out of your processor :)
Careful where you scroll: Your password and your crypto wallet recovery phrase are in there somewhere too! (Unless you have one of those fancy 24 word long ones.)
All possible UUIDs are in this page, it’s not a tiny subset.
They are generated by your device on the fly as you move through the list so you can’t really use it as a rainbow table any more than manually creating the table yourself.
At work our clickstream data carries an 'event_uuid' column which combines uuid, bigint, account numbers and about 10 other identifiers. It makes joining really convenient when you don't know what column to use.
> Browsers do not want to render a window that is over a trillion trillion pixels high, so I needed to handle scrolling and rendering on my own
What’s fun is what actually happens when you try to do these things. It’s disappointing, you can’t even get anywhere near one trillion pixels.
The limits I found five years ago when working at Fastmail, after a customer using IE found their scrollbar broke when they had around 200,000 emails in a mailbox (plus I just checked a couple of them again now):
• Firefox: a few years ago, ignored declarations that resolved to a value higher than 17,895,697 pixels (a smidgeon under 2³⁰ sixtieth pixels). Now, it clamps at that point instead, but maybe three pixels more or less, not immediately clear quite what’s going on and I can’t be bothered investigating. (All browsers seem to have inconsistencies in how clientHeight/getBoundingClientRect/dev tools/whatever report things, that close to the boundaries of possibility. It’s mildly fascinating.)
• IE: ignores declarations that resolve to a value equal to or higher than 10,737,418.23 pixels (2³⁰ − 1 hundredth pixels).
• WebKit: clamps values somewhere around 2²⁵ (~33,554,432) pixels.
• Chromium: matched WebKit when I tested, now it’s clamping around 22,360,882 pixels, but I’m on a 1.5× display, so the 2²⁵ could be connected with device pixels or such. But I think I was on a 2× display when I did the initial testing!
Ah this is great - I tried finding a modern-ish list of max browser heights while writing the blog. Do you mind if I link your comment in an update?
(I'm also super curious how those numbers were chosen and about what would start breaking if the limits weren't there - maybe your example of weirdness around clientHeight etc gets at that)
I'd like to announce my new `npm` package called `get-uuid`. Behind the scenes, it loads `everyuuid.com`, picks a random row number, and returns that UUID.
That's a terrific idea, I'll also create a npm package, that consumes yours and returns the Guid but without the '-' between the digits. Go code reuse!
It's a fun implementation inspired by the short story https://en.wikipedia.org/wiki/The_Library_of_Babel and "At present it contains all possible pages of 3200 characters," though the character set is limited (no dash) so you won't find these UUIDs there.
Weissman score doesn't really have meaning anymore if the input is constrained. For example this website is 200KB as per the network traffic and I can beat it handily with ten-line script to generate every UUID. Or even verbally by just saying "every UUID".
oh hm, i thought I had fixed every case where that popped up. I can't reproduce the issue on any browser on my machine - how did you jump to the bottom (hotkey, scrollbar, scrolling for a trillion years) and what platform are you on (if you don't mind sharing)?
Chome on Windows. Grab the right scroll bar and pull to the very bottom. Once at the bottom try to scroll down with mouse scroll wheel. Screen goes blank and the error appears in the console.
If the browser has 1080 vertical pixels, the scrollbars has max say 1000 possible positions. According to my napkin math* if you scroll over 100 uuids per second it would take up to ~1.7 septillion or ~1 700 000 000 000 000 000 000 000 years to scroll to an uuid of which you know the position if you hit the spot exactly on the scrollbar.
HN recently (last few months) had an article explaining how large a number was. The number was something like busy beaver or 128 bit integers or something else.
It illustrated how large the number was by creating activities you would do, incrementing the counter as you did them. The sequence went something like this:
Walk, and every time you take a step. Add 1
After you have circled the earth, place a sheet of paper on a pile, and start walking again.
Continue, until the paper pile reaches the sun, then place a grain of sand in the Grand Canyon and start over.
Continue until you have filled the Grand Canyon, etc etc
It continued for a lot of such steps until you finally counted up to the number in question.
And then do that in parallel for 10 billion people.
And for each of their devices, and servers or other supporting infrastructure.
And do it multiple times per second (e.g. for every log message, every datapoint, ...)
I've seen "thought experiments" (not sure they're quite that, but close enough) like that for a variety of things. The big numbers I've seen that done for most often are: unique shufflings of a deck of playing cards (about 10^68), atoms in the universe (about 10^80), and a googol (10^100). I've definitely seen the playing card one involve the walk around the world, pile of paper, grand canyon, etc (also drain the ocean a drop at a time, IIRC).
A "proper" search while still retaining sufficiently-looking randomness might be achievable via an SMT solver, by asking it to find an index above the current position, below a binary-searched top boundary, that contains the search term. I think SMT solvers should be clever enough to be able to work the search around some ciphers.
Maybe an SMT solver is a rather heavy-weight approach, but I think it fits the task of searching through 2^122 values :)
Edit: even with no cipher, it takes said approach ~1.6s to find that after 0x1067D3DC2F4951AEA8DB8D0108D7D65 the first occurrence of 0xABCD is at 0x1067D3DC2F4951AEA8DB8D0108DABCD with Z3 (cvc5 and Bitwuzla are slightly slower), which is perhaps a bit too slow.. perhaps it could be improved to something more reasonable by restricting the search to near the end until that fails, and reducing the matchable positions based on the dashes, but that's back to effort.
Edit 2: slightly more effort later:
cipher: 0x15FD586DF0CE258730098B94325ACE7 * (val ^ 0x93C324915DB2B3C4D4CD8135C0DDF1)
inverse: (0x1D52334877384DE3A6DAA4A3312A6D7 * val) ^ 0x93C324915DB2B3C4D4CD8135C0DDF1
example first 10 entries:
0: 2839676B79617D5B9FDF9D43CFB3077
1: 123C0EFD889357D46FD611AF9D58390
2: 143418475AFDC869FFF2B46C3468A45
3: 3E36BFD96A2FA2E2CFE928D8020DD5E
4: 002EC9233C9A13786005CB94991E413
5: 2A3170B54BCBEDF12FFC400066C372C
6: 2C2979FF1E365E86C018E2BCFDD3DE1
7: 162C21912D6838FF900F5728CB790FA
8: 18242ADAFFD2A995202BF9E562897AF
9: 0226D26D0F04840DF0226E51302EAC8
binary search max set to `10 * 2**search_bit_width` after after the chosen start
trying to find a match only in the last 3 possible places (i.e. searching WXYZ only matches *****WXYZ, ****WXYZ*, ***WXYZ**)
searching for 0xFF00FFCC after index 0xAAAAAAAAAAAAAA:
nearest match found at: 0xAAAAAAAD04E3DA
ciphered: 0x0E9399CC39B716BC96348AFF00FFCCD
time taken: 0.7s (bitwuzla or cvc5), or 1s (z3)
But alas I'm stupid, and searching doesn't care about lexicographic ordering, and you necessarily have to search all possible places, not just the end, and that's a ton slower. Perhaps dash placement could reduce them enough, but that's even more effort.
This is funny I like it. Basically just captures the scroll input and iterates through int128s and their UUIDs on a static page to fake a scroll. My feature request would be to add smooth scrolling.
I use this all the time but someone decided to disable it by default. For those who haven't turned it on after a reinstall yet, or haven't discovered the setting: about:preferences -> search autoscrolling
It depend on the UUID version you're using. Version 4 (Random) will always have that value be 4 as per RFC 9562. So 99999999-9999-9999-9999-999999999999 is a valid UUID but not a valid UUID v4. If you wanted to be pedantic the website should have been named https://everyuuidv4.com/
The values are hexidecimal, so all "9s" isn't the biggest UUID, but all "f's". Specifically, I think: `ffffffff-ffff-4fff-bfff-ffffffffffff`.
The "4" in the 3rd block is the only permitted value as these UUIDs are using the GUIDv4 format. I'm not sure what's going on in the 4th block, but the references and linked RFC in the Wikipedia article might reveal more details: https://en.wikipedia.org/wiki/Universally_unique_identifier#...
One important feature is missing: From a proper search function I would expect to know how often my string is found. It could be that my password is rare, or that it is rather common. I need to know! Could the search also display the number of hits?
Jokes aside - you know the number of digits of the search string and if it is still a valid uuid. So computing the number of "matches found" should be possible...
For the implementation of the core logic, I probably would have gone for the lazy solution of iterating AES until the output is <2^122 (64 times on average).
Alternatively just use standard Format-Preserving-Encryption, which is usually a Feistel Network, similar to what they ended up with, but built on a standard algorithm, instead of a homebrew round function.
Thank you for finally giving me a name for this concept. I've run into lots of code implementing them badly, but there's a bit of a semantic hill for others when you don't have a better name than "1-cycle permutation".
Love it! I can't help but think there's still a way to use native scrolling though. You could start with a tall document, say, 10k pixels and grab the scroll position and multiply it out when it moves to get sort of a macro scroll position. That would handle the arrows and clicking or grabbing the scroll box.
But the wheel would be tricky because you want to scroll by only one or a few items, not items/10k. With a static viewport-sized DIV set to overflow-y:scroll and large vertical content size, positioned so you don't see the scroll bar, when the mouse is over it it should capture wheel movement which you could translate to an offset from your macro scroll position.
Just a thought. Either way, love the thinking here, fun work :)
We may be lucky that it didn't work. It appears from GNU units that printing this all out on paper would be about a hundred solar masses. Maybe about fifty solar masses if you print double-sided.
Your comment is needed as a parent / top-level for the discussion. A lot of people were confused about the 'V' portion in particular. Thanks for the insight.
I don't think f is a valid UUID version. One of these positions should be 1–6 or so (not sure who's the authority on which version works how, IETF maybe?)
Barely 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).
It seems to skip a lot for substring search. For example if you search for 'aaaa' there's maybe 100 jumps to get to the bottom. So i'd assume that it's just a uniform random over the entire range to some limit, then filter idx > cur. But I feel like you could constrain the search more. The 'close next' should have exactly the same characters at the front. Like in your example '4AAB-' you would search valid position 14 first.
edit: actually this doesn't work because having the same start does not mean they are close together.
>Maybe this is silly to you. But framing the problem as “come up with a function that looks like it adds entropy but is reversible” was a lot easier for me to think about than “preserve bijectivity between these two sets.
IMO that's half of "real work" - figuring out how to think about a problem. Insights are funny that way - stuff that is obvious to one person is game-changing to others.
> And of course I’m still very curious whether there’s a cryptanalysis approach that lets me achieve more effective search over a random-ish ordering of UUIDs. I’m gonna do some more reading there.
I think that's definitely possible. Especially if you realise that you only need a random-ish looking order, not a cryptographically secure random order.
This could use a “scrubbing” control, where when scrolling by dragging vertically, the scrolling speed depends exponentially on the horizontal position. (Meaning, for example, dragging 10 screen units vertically when the pointer is at horizontal position x would scroll by 10^(x/10) entries.)
> It’s a little awkward to take our two chunks of 61 bits and map it onto the available bits here.
Does it say anything about code-AI that a problem which should be (is!) very easy for machines, but very difficult for front-endy people, seems to also be very difficult for Claude?
It's interesting insight that if you encrypt something in a way that the cipher-text is exactly as long as plain-text (counted in bits) it's as if you just listed all possible inputs and mixed them randomly.
"bijectivity", there is a term from high school I thought I would never hear in real live, still remember having injection, surjection & bijection explained in math class 20 years ago.
I know I shouldn’t be surprised that uuids like 00000000-0000-4000-8000-000000000000 or 12345678-0123-4567-8901-234556789012 exist, but being able to search for them and find them still feels amazing.
Feels to me like Pandora's box to UUID collisions. Even though UUID space is so huge human mind is always so tiny, as it is always subject to some bea5 (pronounce it "bias").
For some reason, I was expecting the search to filter the results instead of just work like Ctrl+F. It'd be nifty if it could collapse non-matching UUIDs.
He's using a bijection between the number on the left (which are ordered) and the UUID that's designed to produce something random-looking. The simple fact that bijection cannot produce the same output out of two inputs (or it's not a bijection) means that all the UUIDs are unique.
UUID is a 128-bit value, of which 122 bits are available for actual data. UUID was conceived as a way to mark an intersection point between two dimensions, originally for Apollo Computer's RPC system where the two dimensions were time and hardware identifier (originally originally Apollo hardware serial number, later commonly 802.3 address). The additional bits are metadata telling you that a particular 128-bit value is a UUID, not just a coincidental jumble of bits, and which type of UUID.
This site is specifically about “V4” UUIDs where the two dimensions are random and also-random. If you scroll all the way to the bottom you will see that the last table row is numbered the same value as the maximum 122-bit number, so the site is flipping every possible bit-combination within that space combined with the metadata bits that say “Hello I am a V4 UUID”:
They are not, 100% strictly speaking, “ensured”. But they are 128bit numbers, so you have realistically no chance of generating a uuid that someone else has already. Age-of-the-universe type chances of duplicating one.
UUIDs aren't technically unique, they're just designed in such a way that the chance of collisions is very small.
A big part of this is that the possibility space is very large, so the chance of collisions is low. Many UUID versions also determine parts of the UUID via MAC addresses and timestamps, to ensure that different servers are highly unlikely to generate the same UUID.
Thanks!
I guess strictly you'd have to include this page, which would put the total internet data in the (roughly) ronnabyte or quettabyte range, with nearly all of it being this page.
I didn't think v4 uuid's were completely random over that 128bit space for some reason, and this was wrong, but interestingly.
for a uuid like 414c1bde-b676-4242-be35-887f01a24f10, if I take its suffix 887f01a24f10 (12 chars, 48 bits) there are still 19 chars (76 bits) to the left of it. (barring the constant 13th char identifier 4)
There still are 2^76 uuid's with that suffix to search through. It made sense with ipv6 addresses and cryptography, but for some reason I had this idea that uuid's didn't use an CRNG that covered the whole 128 bit space. A lot of wrong stuff rattling around in my memory for some reason, thanks for clarifying.
You were so preoccupied with whether you could, you never stopped to ask if you should.
This will be the goto reference for hackers everywhere. Think of how much faster they'll compromise my McDonald's order with all 2^122 possibilities already computed!
Oh my. Brings me back to my internship at a web development firm in Venlo. Someone "hacked" the company (somehow knew the master password used for everything) and deleted half the websites. Could restore from backup iirc but you know what the solution was?
Add an exclamation mark to the password
—
Which in turn reminds me of another internship where a computer upstairs got "hacked". Everything on the desktop was messed up, icons moved, random programs open, some files moved into folders at random... why'd anyone do that? The boss left it as-is for me to take a look at how this could happen—yes, including the thematic porn sites hinting 17-year-old me at what happened to his marriage. Not finding any hints, I started sorting the stuff back out and business continued as usual
Come afternoon, I was working on the computer when the mouse moved. Like, not me, I didn't move it. Was it the hacker? How are they connected? After a bit it moved again, but it didn't make any sense. I don't remember how I put 2 and 2 together but, going downstairs and seeing him at the media station using a wireless mouse downstairs, I got a dark suspicion
Yes of course it was an insider threat =) We bought a different wireless receiver for the mouse that day
The fact that the search works impressed me more than anything. Of course, like every great magic trick, it seems so simple once it is explained.
For the curious, here's the linked blog post describing how the project works: https://eieio.games/blog/writing-down-every-uuid/
Edit to add: I'd only tried searching for an exact UUID when I wrote this comment. I didn't realize it supports full text search! Now I'm even more impressed.
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
> If we didn’t care about generating valid UUID v4s, we could just generate 2^128 numbers, scramble them, convert the resulting bits into a hex string, and intersperse some dashes.
You can do that anyway. You'd only need the twiddling if you wanted to limit the amount of numbers you generate to 2^122. Since you're willing to generate 128 bits:
But since you're generating more numbers than you need, you're going to end up with 64 copies of each UUID in your final stream. This won't matter because no one will ever be able to notice, as long as your faux search functions avoid pointing it out.
Exercise for further development: modify substring search so that it follows the expected behavior of finding matches in order within the page. [I don't recommend attempting this.]
3 replies →
Memorable UUIDs? I think you're on to something here! (Also, dibs on 00000000-0000-4321-abcd-000000000001!)
14 replies →
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 search results.
[1] - https://developer.mozilla.org/en-US/docs/Web/API/History_API
That is, right now you're capturing the Ctrl+F keypress and opening your own custom thing to read the user's search string and act on it. But what we'd really like is a way to be notified "The user just asked to search for 'xyz'. Would you like to capture that event, or let it go through to the browser's default behavior?"
A quick Google search found nothing like that exists yet. I then asked ChatGPT about it, hoping that ChatGPT would at least hallucinate a plausible design for the API — and had mixed feelings when it didn't. It just printed that 'Browsers do not provide a way to listen for the "Find in Page" search event due to privacy and security concerns' and suggested capturing the Ctrl+F keypresses exactly as you have done.
As someone else said, it would also be more like full-text search if you also considered the primary-key column, e.g. searching for "0390814603917539994005679487460590835" should jump to the 390814603917539994005679487460590835th row. (Highlighting-to-select pieces of the text also doesn't work: I'm not sure why not, since I would have thought the browser gives you at least that part for free.)
Besides "search" not working on mobile, the styling on mobile is such that the "scrolling" does not convince: to my eyes it looks too obviously like "changing the values in the cells of a fixed table" as opposed to "scrolling through the table itself." You could maybe mitigate that by animating quickly among three different page layouts with the table vertically offset by different amounts.
It occurs to me that if JavaScript has something like Python's `random.sample`-without-replacement, then you could set your `RANDOM_SEARCH_ITERATIONS` to 256 and achieve perfectly consistent (and exhaustive) "search" when the user has entered all but 1 or 2 hex digits of their desired result. And/or, you could just have the page secretly keep a history of the search results the user has already seen: this would prevent the user from finding out so quickly that "search + next + next + prev + prev" doesn't always get them back to where they started.
Speaking of exhaustive search results: With a bit more (probably equally algorithmically interesting) work, you could emulate the browser search's "7/256" by tallying up the number of UUIDs satisfying the constraint, e.g. if the user has typed "1234567" then you could display "1234567 (158456324585806817418058661888 results)" and maybe even fake up a convincing position indicator like "1234567 (17415833585801881134805987465/158456324585806817418058661888)". I guess if you display it as "1234567 (1.742e28/1.585e29)" then you don't even have to cheat that much. :)
1 reply →
[dead]
A great example of Teller's observation that "sometimes magic is just someone spending more time on something than anyone else might reasonably expect."
My favorite of these was a trick where someone picked a card out of a deck and then Teller revealed a large version of that same card in an unexpected area in the vicinity, It turns out that what he had done was hide a complete set of large cards in the area before the trick and memorized the location of every one of them so, e.g., the king of hearts would be at the top of a palm tree, the three of spades under a drink tray, etc.
7 replies →
> Ninety per cent of most magic merely consists of knowing one extra fact.
-- Night Watch by Terry Pratchett
1 reply →
Sufficiently advanced technology is indistinguishable from magic, as the saying goes.
2 replies →
The explanation for full-text search was actually slightly more intelligent than what I initially assumed. I figured it just generated UUIDs until it found one that was in the correct direction of search (for the next/previous button), since I had observed that walking forwards and backwards in search results was giving different results each time, but in fact the author did the slightly better thing which is to just generate a bunch of possible results and then pick the best (I wonder how many results it generates for this?).
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 find something like that that gives a sufficiently convincing illusion of entropy but is still reversibile when you hold a subset of the digits constant. And it seems like it should be.
14 replies →
Searching is very similar to a common approach for building a naïve spellchecker: given an input, generate all the possible matches it can be part of. You're not searching in a corpus, you're using the input to generate indices into the corpus (list of UUIDs here, list of words in the dictionary in a spellchecker).
The blog write-up is incredible -- technically interesting, hilarious, and perfect in both tone and scope. Well done!
Love both the project idea and the writing!
The way that post explains each step in a unique laconic tone is very enjoyable to read.
> Or maybe the site could feature “trending UUIDs” that are particular popular across the world right now.
For the even more curious, UUID has 5316 decillion 911 nonillion 983 octillion 139 septillion 663 sextillion 491 quintillion 615 quadrillion 228 trillion 214 billion 121 million 397 thousand 304 values. Imagine the fact that there aren't as many kms to reach GN-Z11 (farthest known galaxy in the Universe I think) as there are digits above
yet I was able to scroll through them like scrolling through a 800-word web page
The UIA (Universal Internet Authority) is worried that by using UUIDs we are left with only around 34 trillion UUIDs per star and planet in the observable Universe. So the cosmic router might become DHCP-leasing dark matter.
I searched for 1337, and then 13371337, and then 133713371337, and I was flabbergasted they've got a search setup for this (which ctrl-f opens up). Thanks for posting the blog post!
> The fact that the search works impressed me more than anything. Of course, like every great magic trick, it seems so simple once it is explained.
> Edit to add: I'd only tried searching for an exact UUID when I wrote this comment. I didn't realize it supports full text search! Now I'm even more impressed.
But the trick to the full-text search is that it doesn't work.
This is neat, although I pushed it later with incremental search and it seems to be skipping results as it only found ~50 when searching for `-000000000000`.
Yeah, I at first, I though I knew exactly how it worked. Then I saw the search field, and I suddenly had no idea what the hell was going on. Now, the big question, do I want to spoil the magic trick and read how this was done, or should I keep being astonished and flabbergasted?
I disagree with my sibling comment. The trick is beautiful. If you generate UUIDs such that each bit in the result can be reliably traced back to a single bit in the input, then you can take a substring of the UUID and use that to infer which bits of the input integer must be set to produce that substring. So you can produce a whole list of input bytes that meet the criteria and those become your search results.
The real magic trick here is that the uuids on the page only look random to us because of some bit twiddling and XOR trickery. If we had a better intuition for such things we would notice that successive UUIDs are just as correlated as successive integers.
Elegant stuff
1 reply →
If you're an Everettian, roll https://www.jrussellhuffman.com/quantumdice/ and read it only if the die is odd. You can have your cake and eat it too.
1 reply →
As with any magic trick, reading the explanation might leave you a little disappointed here.
1 reply →
full-text search? you see the int next to the str on the left, no such thing..
reminds of me this daniel dennett quote
Real magic, in other words, refers to the magic that is not real, while the magic that is real, that can actually be done, is not real magic.
Awesome - this will be my new coding interview question
Agreed. Everyone love puzzles that are worthy of an entire section in a blogpost for their interview questions, rather than stuff actually relevant to the job.
4 replies →
Cool Blogpost
Seems like some hacker leaked all UUIDs.
Check if your UUIDs are part of the leak.
This is the biggest hack since every ATM PIN was leaked: https://pastebin.com/SmJRB8eQ
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.
24 replies →
Haha, I have a file in my home directory that has every possible SSN because I wanted to be able to tell a friend “I have your SSN in a file on my computer.”
Holy shit, my PIN is on there. How the hell did that get that?? I was told it was a 1/10,000 chance of someone guessing it.
4 replies →
I am sure our IT security department would jump right on to that if informed of it...
Looking forward to a "havemyuuidsbeenpwned.com" service :))
>10b82756-f8b4-4fee-a508-adeadbeef5eb
Oh well, time to reformat
2016 called, they want their "Side of Beef" jokes back.
With the way things are at work right now I simply don't have time to mitigate this leak in my personal data security. I've officially given up.
I hope this gets incorporated into haveibeenpwned.com.
Wait till someone files a CVE
Nerd hacker politics, but SSN leaks are no joke.
Agreed: The real joke is any organization using SSNs as an authentication mechanism (as opposed to an identifier).
1 reply →
I had a database of all SSNs for a while, but it was on a work laptop, so I didn't get to keep it.
4 replies →
I think this is a joke, but I think it is a problem if someone finds any sensitive uuid here, because the list on this website is a tiny subset of all possible uuids, so it provides a useful rainbow table for anyone attempting brute force attacks. I.e. generating and using random uuids would have an astronomically small success rate, whereas trying the ones on this site may not (depending on where they came from, which I'm not sure of).
You should check out the author's blog post about the site — it is quite literally every UUID, computed and rendered on demand.
https://eieio.games/blog/writing-down-every-uuid/
2 replies →
> depending on where they came from, which I'm not sure of
They're coming straight out of your processor :)
Careful where you scroll: Your password and your crypto wallet recovery phrase are in there somewhere too! (Unless you have one of those fancy 24 word long ones.)
All possible UUIDs are in this page, it’s not a tiny subset.
They are generated by your device on the fly as you move through the list so you can’t really use it as a rainbow table any more than manually creating the table yourself.
Very 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
Nice one.
Random key: balance is zero.
Real key: balance is (now) zero
Thanks for this, I didn't know that people create weak BTC keys for fun. I guess some are also used as bot honeypots?
Back in the day people used to SHA256 a passphrase and create a Bitcoin private key from it.
Definitely! Takes a bit of time to go through all of them, though.
I think people don’t get what I mean. A key with just 0s and a 1 at the last digit is very weak. Yet someone created a wallet with it for fun.
I'm sure there are people who will search for their actual private key, potentially leaking it.
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)
3 replies →
Sometimes I feel bad when I generate a UUID without using it for anything. Like I've wasted it.
You're not the only one who feels this way: https://wasteaguid.info/
This is just perfect.
There's enough of them that you're saving a scarcer resource by not recording it anywhere.
how bad do you feel about all the uuids you didnt generate so were never born?
At work our clickstream data carries an 'event_uuid' column which combines uuid, bigint, account numbers and about 10 other identifiers. It makes joining really convenient when you don't know what column to use.
I once used `SELECT TOP 1` ... `ORDER BY NEWID()` to pick a record from a table of millions.
Millions of UUIDs generated! All so one would randomly be picked as the lowest valued and the attached record returned. Such a waste!
Seriously, this just seems like a frivolous waste of a precious and rapidly dwindling resource…
> Browsers do not want to render a window that is over a trillion trillion pixels high, so I needed to handle scrolling and rendering on my own
What’s fun is what actually happens when you try to do these things. It’s disappointing, you can’t even get anywhere near one trillion pixels.
The limits I found five years ago when working at Fastmail, after a customer using IE found their scrollbar broke when they had around 200,000 emails in a mailbox (plus I just checked a couple of them again now):
• Firefox: a few years ago, ignored declarations that resolved to a value higher than 17,895,697 pixels (a smidgeon under 2³⁰ sixtieth pixels). Now, it clamps at that point instead, but maybe three pixels more or less, not immediately clear quite what’s going on and I can’t be bothered investigating. (All browsers seem to have inconsistencies in how clientHeight/getBoundingClientRect/dev tools/whatever report things, that close to the boundaries of possibility. It’s mildly fascinating.)
• IE: ignores declarations that resolve to a value equal to or higher than 10,737,418.23 pixels (2³⁰ − 1 hundredth pixels).
• WebKit: clamps values somewhere around 2²⁵ (~33,554,432) pixels.
• Chromium: matched WebKit when I tested, now it’s clamping around 22,360,882 pixels, but I’m on a 1.5× display, so the 2²⁵ could be connected with device pixels or such. But I think I was on a 2× display when I did the initial testing!
See also https://news.ycombinator.com/item?id=34299569 where I wrote more about it, with links to relevant source code.
Ah this is great - I tried finding a modern-ish list of max browser heights while writing the blog. Do you mind if I link your comment in an update?
(I'm also super curious how those numbers were chosen and about what would start breaking if the limits weren't there - maybe your example of weirdness around clientHeight etc gets at that)
there's also similarly limits on width of elements, which I found out recently when trying to set a width to "45678910px" [1]
[1] https://thewisenerd.com/works/45678910px.html
I'd like to announce my new `npm` package called `get-uuid`. Behind the scenes, it loads `everyuuid.com`, picks a random row number, and returns that UUID.
That's a terrific idea, I'll also create a npm package, that consumes yours and returns the Guid but without the '-' between the digits. Go code reuse!
> That's a terrific idea
I think you meant 'terrific' in the old original meaning.
Please, only try to break the library's api 5 times a month, otherwise it's just too much
And look forward to my realising your package doesn't quite do want I want and forking it
I'd prefer if it used AI to pick one that was aesthetically pleasing. I can file a PR if you like?
Could you please add a function to check if a uuid exists?
reminds me of https://libraryofbabel.info/ (which seems to be down at the moment try Archive https://web.archive.org/web/20241112121646/https://libraryof...).
It's a fun implementation inspired by the short story https://en.wikipedia.org/wiki/The_Library_of_Babel and "At present it contains all possible pages of 3200 characters," though the character set is limited (no dash) so you won't find these UUIDs there.
There's also a variation of this book called
A Short Stay in Hell (2009) by Steven L. Peck
It's a fun and scary read. Especially if you understand very big numbers.
I was gonna mention that so people have something to read when they finished the UUIDs.
I thought this was going to be a list of every .com domain that is a valid uuid. Now I'm wondering how many of those exist?
Update: Another commenter already shared: https://news.ycombinator.com/item?id=42342653
Compression is now so advanced, we can browse web pages weighing over 340 undecillion bytes.
We truly live in an age of wonders.
I am pretty sure this sets a new record for highest Weissman score
Middle-out truly is revolutionary
Weissman score doesn't really have meaning anymore if the input is constrained. For example this website is 200KB as per the network traffic and I can beat it handily with ten-line script to generate every UUID. Or even verbally by just saying "every UUID".
Meh. Years ago I had my bakeries churning out undecillions of units no problem in Cookie Clicker. No big deal!
They just don't make em like they used to...
Wow, it's a website which has more than a screen-full of stuff on it at one time and scrolling doesn't introduce a seconds-long loading animation.
I wonder if modern web developers of modern web applications could somehow harness this technology.
100% this. I thought the same thing immediately, "wow, this is fast and smooth and responsive!!"
It's ludicrous how our computer hardware is 1000x faster than it was 30 years ago in 1995, but software is so bloated that it is still slower!
Relevant: "Will Software Stop Getting Slower?" Jonathan Blow https://www.youtube.com/watch?v=4ka549NNdDk
It's merely a trick of windowed scrolling.
Jumped to the bottom and the page locked up. Console shows:
oh hm, i thought I had fixed every case where that popped up. I can't reproduce the issue on any browser on my machine - how did you jump to the bottom (hotkey, scrollbar, scrolling for a trillion years) and what platform are you on (if you don't mind sharing)?
Chome on Windows. Grab the right scroll bar and pull to the very bottom. Once at the bottom try to scroll down with mouse scroll wheel. Screen goes blank and the error appears in the console.
7 replies →
use the scroll bar to get to the "end" then use scroll wheel. that's how I managed to hit it reliably.
Every uuid dot com except if greater than 2^122 -1 doesn’t have the same ring ;)
There aren't more than 2^122 UUIDv4s.
1 reply →
It's the void that comes after the last particle in the known universe.
OMG thank you!! I was looking for one that goes well with my shoes and I finally found the one - 346c7747-a421-4073-881e-7a7282b6150b.
EDIT: That one is MINE. PLEASE DO NOT USE IT.
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.
Something tells me S3 was not designed for that and will break, and then everything will break.
And because StackOverflow broke too, there's nobody available to fix it.
What will be the bill?
I think all the money
Want to find the actual UUIDs that are a dot com?
https://www.merklemap.com/search?query=*-*-*-*-*.com&page=0
Well, some of them are :)
Does it index subdomains by certs issued? What about wildcard certs? Or sites that accept all possible subdomains?
I spent far too much time being childish with this, but I am quite pleased that:
69420694-2069-4206-9420-694206942069
is a valid UUID.
I wonder how many test suites this is going to show up in...
you just need to set the two metadata positions to specific values, the rest are all valid
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
M = 4
N = 8,9,a,b
x = 0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f
My inner middle schooler is also satisfied
B00B1E5f-7117-4a61-816d-92710147f63f
[flagged]
If the browser has 1080 vertical pixels, the scrollbars has max say 1000 possible positions. According to my napkin math* if you scroll over 100 uuids per second it would take up to ~1.7 septillion or ~1 700 000 000 000 000 000 000 000 years to scroll to an uuid of which you know the position if you hit the spot exactly on the scrollbar.
* https://www.wolframalpha.com/input?i=ROUND%5B2%5E122%2F1000%...
Edit: Use 122 bit instead of 128 due to UUIDv4
I took the first one, nobody else take it or it will no longer be a UUID.
You can sell it as an NFT. That way it is still unique but you can pass it along.
The creator should add a button to mint an nft on his custom side chain.
1 reply →
Please add a button to export to Excel.
Tangentially related:
HN recently (last few months) had an article explaining how large a number was. The number was something like busy beaver or 128 bit integers or something else.
It illustrated how large the number was by creating activities you would do, incrementing the counter as you did them. The sequence went something like this:
It continued for a lot of such steps until you finally counted up to the number in question.
What was the number? What were the steps?
The number you're thinking of is 52! (52 factorial) and how long it would take for 52! seconds to pass by.
Vsauce has a great video on this, and might be where that example was taken from.
https://www.youtube.com/watch?v=ObiqJzfyACM
That example starts 16 minutes into the video:
https://www.youtube.com/watch?v=ObiqJzfyACM&t=964s
But it's worth watching the whole thing.
And that number is relevant because it's the number of possible ordering of a standard deck of 52 cards. There are... a lot of them.
I found a text version of the same (?) thing: https://czep.net/weblog/52cards.html
Yes! Nice find thank you.
It was 52!, the number of possible permutations of 52 cards: https://czep.net/weblog/52cards.html
And then do that in parallel for 10 billion people. And for each of their devices, and servers or other supporting infrastructure. And do it multiple times per second (e.g. for every log message, every datapoint, ...)
That's why we need 128 bit numbers.
I've seen "thought experiments" (not sure they're quite that, but close enough) like that for a variety of things. The big numbers I've seen that done for most often are: unique shufflings of a deck of playing cards (about 10^68), atoms in the universe (about 10^80), and a googol (10^100). I've definitely seen the playing card one involve the walk around the world, pile of paper, grand canyon, etc (also drain the ocean a drop at a time, IIRC).
Jeff Bezos' net worth?
https://www.tiktok.com/@mrgeemath/video/7353832903404490027?...
Nice. I’ve added a few favourites just to keep track of them, you never know!
It would be great if there was an API because I’m working on an UI that needs UUID autocomplete. Thank you!
They should set up a reservation database and sell vanity UUIDs for trendy LA people
There's a fine line between a hacker's cool personal project and a schizophrenic's magnum opus
A "proper" search while still retaining sufficiently-looking randomness might be achievable via an SMT solver, by asking it to find an index above the current position, below a binary-searched top boundary, that contains the search term. I think SMT solvers should be clever enough to be able to work the search around some ciphers.
Maybe an SMT solver is a rather heavy-weight approach, but I think it fits the task of searching through 2^122 values :)
Edit: even with no cipher, it takes said approach ~1.6s to find that after 0x1067D3DC2F4951AEA8DB8D0108D7D65 the first occurrence of 0xABCD is at 0x1067D3DC2F4951AEA8DB8D0108DABCD with Z3 (cvc5 and Bitwuzla are slightly slower), which is perhaps a bit too slow.. perhaps it could be improved to something more reasonable by restricting the search to near the end until that fails, and reducing the matchable positions based on the dashes, but that's back to effort.
Edit 2: slightly more effort later:
But alas I'm stupid, and searching doesn't care about lexicographic ordering, and you necessarily have to search all possible places, not just the end, and that's a ton slower. Perhaps dash placement could reduce them enough, but that's even more effort.
This is funny I like it. Basically just captures the scroll input and iterates through int128s and their UUIDs on a static page to fake a scroll. My feature request would be to add smooth scrolling.
> iterates through int128s
Have you read the blog post? I wouldn’t summarize it like that, it’s a little more involved than just iterating. I learned something today.
And support autoscroll too, if possible (where you click middle mouse to scroll)
I use this all the time but someone decided to disable it by default. For those who haven't turned it on after a reinstall yet, or haven't discovered the setting: about:preferences -> search autoscrolling
This needs an “I’m Feeling Lucky” button.
Please remove my UUID 039a69dc-b0a1-4be0-b424-5e45aca8d3fb from the list. I spent a lot of money on it
Hey, one of my database passwords is in here. How the heck did you get access to it????????
Who do I contact about this breach? I want names and addresses.
I'm so sorry - we'll start working on a feature to redact UUIDs after we figure out how to handle GDPR compliance
The name and address is at everyUTF8string.com. You might have to scroll a while, though...
Thank you. I started scrolling 4 hours ago and am yet to encounter my first address.
I found the Pi UUID: 185e45bc-750b-43d7-91ee-314159265358
There are a lot. like this: aac8022d-350a-4c3e-9012-314159265358
Btw, one suggestion to make the scrolling look more believable would be to let people scroll by fractions of a line.
(Just like on HN, I can scroll so that just the bottom part of the first line of text is visible.)
I tried to find the biggest UUID and if I got it right, it's
99999999-9999-4999-9999-999999999999
(note the 4 in the 3rd block)
I'm curious why it's not 99999999-9999-9999-9999-999999999999 (all 9s)?
It depend on the UUID version you're using. Version 4 (Random) will always have that value be 4 as per RFC 9562. So 99999999-9999-9999-9999-999999999999 is a valid UUID but not a valid UUID v4. If you wanted to be pedantic the website should have been named https://everyuuidv4.com/
https://datatracker.ietf.org/doc/html/rfc9562
The last line of https://xkcd.com/566/, except it's UUID formats.
6 replies →
The values are hexidecimal, so all "9s" isn't the biggest UUID, but all "f's". Specifically, I think: `ffffffff-ffff-4fff-bfff-ffffffffffff`.
The "4" in the 3rd block is the only permitted value as these UUIDs are using the GUIDv4 format. I'm not sure what's going on in the 4th block, but the references and linked RFC in the Wikipedia article might reveal more details: https://en.wikipedia.org/wiki/Universally_unique_identifier#...
If you're going by hex, the biggest UUID is entirely f's, 32 of them. It's defined specially and doesn't have version or variant.
2 replies →
But if it’s all Fs, that means you have the sign bit set, so it’s not the largest.
It’s the smallest that’s less than zero right?
2 replies →
Looks like it only generates v4 UUIDs, which is a bit of a ripoff.
Also you'll find that the first character of the 4th block is forced to be 8, 9, a, or b. That's true of standard UUIDs of any version.
The 4 indicates UUIDv4.
If you were looking for the biggest hexadecimal UUID, find one with f instead of 9.
Because the 4 is always “4”, it denotes the version (uuid v4)
Great idea and writeup!
One important feature is missing: From a proper search function I would expect to know how often my string is found. It could be that my password is rare, or that it is rather common. I need to know! Could the search also display the number of hits?
Jokes aside - you know the number of digits of the search string and if it is still a valid uuid. So computing the number of "matches found" should be possible...
I found a good UUID but immediately lost it because the custom scroll also interprets left and right scroll :(
(this also breaks browser forward and backward trackpad gestures)
For the implementation of the core logic, I probably would have gone for the lazy solution of iterating AES until the output is <2^122 (64 times on average).
Alternatively just use standard Format-Preserving-Encryption, which is usually a Feistel Network, similar to what they ended up with, but built on a standard algorithm, instead of a homebrew round function.
Thank you for finally giving me a name for this concept. I've run into lots of code implementing them badly, but there's a bit of a semantic hill for others when you don't have a better name than "1-cycle permutation".
Finally a use case for creating a table with a million rows in React.
You’re going to need a smidge more than that.
Love it! I can't help but think there's still a way to use native scrolling though. You could start with a tall document, say, 10k pixels and grab the scroll position and multiply it out when it moves to get sort of a macro scroll position. That would handle the arrows and clicking or grabbing the scroll box.
But the wheel would be tricky because you want to scroll by only one or a few items, not items/10k. With a static viewport-sized DIV set to overflow-y:scroll and large vertical content size, positioned so you don't see the scroll bar, when the mouse is over it it should capture wheel movement which you could translate to an offset from your macro scroll position.
Just a thought. Either way, love the thinking here, fun work :)
When I hit print in Firefox it only is one page long. :(
We may be lucky that it didn't work. It appears from GNU units that printing this all out on paper would be about a hundred solar masses. Maybe about fifty solar masses if you print double-sided.
I looked for deadbeef-f00d-f00d-deadbeef**
but did not find it. Search is just on active page, that gets ever longer?
deadbeef-f00d-f00d-deadbeef isn't a valid UUID v4
Aside from missing a grouping in the middle, you need the version and variant bits, ie:
XXXXXXXX-XXXX-4XXX-VXXX-XXXXXXXXXXXX
where V is 8, 9, A, or B
searching for deadbeef-f00d-400d-a00d-deadbeef does return the expected matches
Your comment is needed as a parent / top-level for the discussion. A lot of people were confused about the 'V' portion in particular. Thanks for the insight.
I don't think f is a valid UUID version. One of these positions should be 1–6 or so (not sure who's the authority on which version works how, IETF maybe?)
That’s not a valid UUID? The version and variant parts are missing.
Looks like the end boss of yak shaving. Very fun, silly idea and a great implementation.
Barely 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).
> Scrolling through a list of UUIDs should be exciting! I wanna see bb166283-2e09-4b72-ba32-70a43521c70e, not 00000000-0000-4000-8000-000000000000!
This was my favorite bit and speaks a lot about the craft behind this page! v cool <3
This is amazing! I can finally get that vanity UUID I was dreaming of for so long!
It seems to skip a lot for substring search. For example if you search for 'aaaa' there's maybe 100 jumps to get to the bottom. So i'd assume that it's just a uniform random over the entire range to some limit, then filter idx > cur. But I feel like you could constrain the search more. The 'close next' should have exactly the same characters at the front. Like in your example '4AAB-' you would search valid position 14 first.
edit: actually this doesn't work because having the same start does not mean they are close together.
Oof, mine are on there. Guess I'll have to rotate them now :/
The ability to bookmark your favorite ones, now that's art.
>Maybe this is silly to you. But framing the problem as “come up with a function that looks like it adds entropy but is reversible” was a lot easier for me to think about than “preserve bijectivity between these two sets.
IMO that's half of "real work" - figuring out how to think about a problem. Insights are funny that way - stuff that is obvious to one person is game-changing to others.
This is like if Wes Anderson was a computer scientist.
I love this kind of thing!
Now all I need to do is hold my finger on the down arrow and keep watching for a *little* while to see every V4 UUID.
> And of course I’m still very curious whether there’s a cryptanalysis approach that lets me achieve more effective search over a random-ish ordering of UUIDs. I’m gonna do some more reading there.
I think that's definitely possible. Especially if you realise that you only need a random-ish looking order, not a cryptographically secure random order.
This could use a “scrubbing” control, where when scrolling by dragging vertically, the scrolling speed depends exponentially on the horizontal position. (Meaning, for example, dragging 10 screen units vertically when the pointer is at horizontal position x would scroll by 10^(x/10) entries.)
This is excellent.
29113161-136d-411e-9efd-5b24a910c307
I'm going to take this one if no one minds, please select something else for your purposes.
Typical, I'm always late and the good ones are already taken
> It’s a little awkward to take our two chunks of 61 bits and map it onto the available bits here.
Does it say anything about code-AI that a problem which should be (is!) very easy for machines, but very difficult for front-endy people, seems to also be very difficult for Claude?
I'm going to take these, please mark them as taken
ec971907-4564-46ec-b28b-d76f1a2233c8
58737c1a-9294-4ffa-8082-b5364923a59c
ba6ca980-b405-48b9-9770-252611d40ef1
Thanks!
np, I'm taking deadbeef-beef-4000-beef-deadbeefdead
Neat idea, excellent implementation!
Now I kind of want to do this for "every 12 character password"...
It's interesting insight that if you encrypt something in a way that the cipher-text is exactly as long as plain-text (counted in bits) it's as if you just listed all possible inputs and mixed them randomly.
"bijectivity", there is a term from high school I thought I would never hear in real live, still remember having injection, surjection & bijection explained in math class 20 years ago.
I know I shouldn’t be surprised that uuids like 00000000-0000-4000-8000-000000000000 or 12345678-0123-4567-8901-234556789012 exist, but being able to search for them and find them still feels amazing.
Every social security number!
Feels to me like Pandora's box to UUID collisions. Even though UUID space is so huge human mind is always so tiny, as it is always subject to some bea5 (pronounce it "bias").
The search seems to be missing `c12a7328-f81f-11d2-ba4b-00a0c93ec93b`
That's a version 1 UUID, site only has version 4's
I got it to search e1e1e0 and got it up to twice.
Repeating it three times though I couldn’t (even with dashes added). :) I am sure I am holding the phone wrong.
0d42d789-fd08-44ec-a46e-e1e10e1e10e1
For some reason, I was expecting the search to filter the results instead of just work like Ctrl+F. It'd be nifty if it could collapse non-matching UUIDs.
This probably shows that I don't know much about UUIDs, but how come when I search for "asd" or "den", there are no matches?
UUIDv4s use hexadecimal digits which are the characters 0-9 and then a-f so neither of 's' or 'n' could be contained in a UUIDv4.
These are hexadecimal digits, so only 0-9 and a-f are allowed.
Its hex. Only characters A-F are used.
What am I missing here? What is the purpose of this?
It seems that 00000000-0000-4000-8000-000000000000 is the "smallest" UUID generated by 2645248903793120745936665251644898482.
Would love it if the scrollbar was draggable on iOS! I thought it was broken until I realized you can click on a spot to scroll to.
At first I thought this was a list of all the domain names that were in UUID form. Which would be equally as useful to many people.
A testament of how optimized web browsers are.
Seems like the only feature missing (besides social sharing mentioned in the blog post) is deep linking to specific UUIDs.
I own d12bf171-1ded-4bf6-a87c-b62c202f9e4b now nobody use it thank you.
Edit: and the following 2^8-1 for friends and family, thank you.
A very nice demo of how to render a page. If it weren't for that I would be very confused why this exists
I starred my UUID of choice. Now I can't find it. Help, I've been scrolling for three days.
You can also use something like DES3 to get a bijection. Easier if it fits in 64 bits so you only need one block.
Hehe 12345678-b00b-4123-b00b-b00b13551234
my ref notes on UUID for those interested https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20No...
Damn, looks like my db has been leaked
It can't be a coincidence that, as I read this UUID page, there are 255 comments before mine.
Can someone ELI5? How's he ensuring uniqueness of a UUID when they are randomly generated?
He has a writeup of it here: https://eieio.games/blog/writing-down-every-uuid/
He's using a bijection between the number on the left (which are ordered) and the UUID that's designed to produce something random-looking. The simple fact that bijection cannot produce the same output out of two inputs (or it's not a bijection) means that all the UUIDs are unique.
UUID is a 128-bit value, of which 122 bits are available for actual data. UUID was conceived as a way to mark an intersection point between two dimensions, originally for Apollo Computer's RPC system where the two dimensions were time and hardware identifier (originally originally Apollo hardware serial number, later commonly 802.3 address). The additional bits are metadata telling you that a particular 128-bit value is a UUID, not just a coincidental jumble of bits, and which type of UUID.
This site is specifically about “V4” UUIDs where the two dimensions are random and also-random. If you scroll all the way to the bottom you will see that the last table row is numbered the same value as the maximum 122-bit number, so the site is flipping every possible bit-combination within that space combined with the metadata bits that say “Hello I am a V4 UUID”:
They're not randomly generated. They're generated using a Feistel cipher. [1]
He's ensuring the uniqueness by indexing from 0, and applying the cipher to come up with a more "random" looking UUID.
[1] https://eieio.games/blog/writing-down-every-uuid/#toc:feiste...
They are not, 100% strictly speaking, “ensured”. But they are 128bit numbers, so you have realistically no chance of generating a uuid that someone else has already. Age-of-the-universe type chances of duplicating one.
They are; the blog post explains why.
UUIDs aren't technically unique, they're just designed in such a way that the chance of collisions is very small.
A big part of this is that the possibility space is very large, so the chance of collisions is low. Many UUID versions also determine parts of the UUID via MAC addresses and timestamps, to ensure that different servers are highly unlikely to generate the same UUID.
What percentage of the 100+ Zettabytes of data now on the internet does this page take up?
Around 9,400,000,000,000,000,000%
Thanks! I guess strictly you'd have to include this page, which would put the total internet data in the (roughly) ronnabyte or quettabyte range, with nearly all of it being this page.
I remember seeing one of these for Bitcoin addresses a long time ago... Very funny :)
Super weird coincidence but I spotted a UUID in here that I had previously used!
These were all, of course, already available in Borges' library.
Who needs infinite scroll when you can have technically finite scroll!
ah the 0xdeadbeef of UUIDs deadbeef-6265-4780-9167-555689902667
Can this be turned into a SAAS? I'm tired of copying ids.
This is a major incident. All of our uuids were leaked!
how many sequential chars of a uuid do you need to calculate the rest of it, or infer the rest of it from a smaller set of all possible ones?
All of them, more or less. There are a few marker bits but the rest are pure data. There is no error correct or redundancy.
I didn't think v4 uuid's were completely random over that 128bit space for some reason, and this was wrong, but interestingly.
for a uuid like 414c1bde-b676-4242-be35-887f01a24f10, if I take its suffix 887f01a24f10 (12 chars, 48 bits) there are still 19 chars (76 bits) to the left of it. (barring the constant 13th char identifier 4)
There still are 2^76 uuid's with that suffix to search through. It made sense with ipv6 addresses and cryptography, but for some reason I had this idea that uuid's didn't use an CRNG that covered the whole 128 bit space. A lot of wrong stuff rattling around in my memory for some reason, thanks for clarifying.
1 reply →
You fool! You destroyed the universal uniqueness now!
You were so preoccupied with whether you could, you never stopped to ask if you should.
This will be the goto reference for hackers everywhere. Think of how much faster they'll compromise my McDonald's order with all 2^122 possibilities already computed!
This is beautiful.
Shoutout `deadbeef-91c5-4ef3-b6d9-0a1c95775b4d`
lol I misunderstood, I thought someone had searched for every domain name that happens to be a valid UUID
I found the Pi UUID:
185e45bc-750b-43d7-91ee-314159265358
Ha. Math geek.
b00bb00b-b00b-4444-b00b-b00bb00bb00b
for a minute I thought this was a domain reseller that was offering .com uuid domains
Only has type 4 UUIDs. ;-)
Looks like they just changed the subtitle from "In case you forgot one" to "Well, only the V4 ones".
:-)
Actually, it looks like it alternates between those two phrases.
damn, my password is here
that's ok, just add a "1" and an exclamation to the end, that'll make it super secure, the hackers won't figure that one out.
Oh my. Brings me back to my internship at a web development firm in Venlo. Someone "hacked" the company (somehow knew the master password used for everything) and deleted half the websites. Could restore from backup iirc but you know what the solution was?
Add an exclamation mark to the password
—
Which in turn reminds me of another internship where a computer upstairs got "hacked". Everything on the desktop was messed up, icons moved, random programs open, some files moved into folders at random... why'd anyone do that? The boss left it as-is for me to take a look at how this could happen—yes, including the thematic porn sites hinting 17-year-old me at what happened to his marriage. Not finding any hints, I started sorting the stuff back out and business continued as usual
Come afternoon, I was working on the computer when the mouse moved. Like, not me, I didn't move it. Was it the hacker? How are they connected? After a bit it moved again, but it didn't make any sense. I don't remember how I put 2 and 2 together but, going downstairs and seeing him at the media station using a wireless mouse downstairs, I got a dark suspicion
Yes of course it was an insider threat =) We bought a different wireless receiver for the mouse that day
Seems like I got lucky – I have a "G" in mine!
can someone explain how this manages to list all 2^122 uuids?
wow. this is so cool
TIL aaaaaaaa-aaaa-4aaa-aaaa-aaaaaaaaaaaa is a valid uuid
I think we broke it :(
perfect website for mouse scroll wheel benchmark
UUIDs are the best.
this brings me joy.
Holy shit it’s a real life library of babel!!
I'm now the proud owner of 69ac8bd2-4ca0-4dd9-82b5-60fabec0b404.com
but why?
This only contains V4 UUIDs. Disappointed.
now sort them alphabetically
Sorting them lexically would be trivial. Just calculate the index via the reverse permutation, similar to how search works.
[dead]
[dead]