[HN Gopher] Every V4 UUID
___________________________________________________________________
Every V4 UUID
Author : LorenDB
Score : 1294 points
Date : 2024-12-06 18:11 UTC (1 days ago)
(HTM) web link (everyuuid.com)
(TXT) w3m dump (everyuuid.com)
| mpeg wrote:
| 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
| manmal wrote:
| Thanks for this, I didn't know that people create weak BTC keys
| for fun. I guess some are also used as bot honeypots?
| therein wrote:
| Back in the day people used to SHA256 a passphrase and create
| a Bitcoin private key from it.
| lxgr wrote:
| Definitely! Takes a bit of time to go through all of them,
| though.
| manmal wrote:
| 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.
| wild_pointer wrote:
| Nice one.
|
| Random key: balance is zero.
|
| Real key: balance is (now) zero
| ayaros wrote:
| See also: https://keys.lol/
| lelandfe wrote:
| 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)
| bspammer wrote:
| Wow I hope that's temporary - I looked at the site less
| than a month ago and it was still up.
| Jabbles wrote:
| I'm sure there are people who will search for their actual
| private key, potentially leaking it.
| animal_spirits wrote:
| Damn, looks like my db has been leaked
| swyx wrote:
| my ref notes on UUID for those interested
| https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20No...
| LCoder wrote:
| Jumped to the bottom and the page locked up. Console shows:
| Uncaught Error: Index out of range - must be less than 2^122
| eieio wrote:
| 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)?
| LCoder wrote:
| 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.
| eieio wrote:
| OH! Thanks for the precise reproduction steps, I had done
| my testing with a trackpad and had missed that! Writing a
| little fix now (I'd hate for you to not be able to see the
| last UUID)
| jonny_eh wrote:
| > I'd hate for you to not be able to see the last UUID
|
| No spoilers, but the last one's a doozy!
| efdee wrote:
| Number #553752677 will surprise you!
| saagarjha wrote:
| It's actually number
| #5316911983139663491615228241121378304 if you were
| keeping count.
| blahyawnblah wrote:
| Same for me on Firefox windows
| eieio wrote:
| alright, a fix that I think covers this crash and a few
| others I found as a result is rolling out now.
|
| for a while I thought I had an off by one error, which was
| pretty funny to think about in the context of trillions of
| items. but in fact I was just doing some bad react state
| management.
| rel_ic wrote:
| fixed for me! Brave MacOS
| gabeio wrote:
| use the scroll bar to get to the "end" then use scroll wheel.
| that's how I managed to hit it reliably.
| xyst wrote:
| Every uuid dot com except if greater than 2^122 -1 doesn't have
| the same ring ;)
| anamexis wrote:
| There aren't more than 2^122 UUIDv4s.
| hikarikuen wrote:
| This reminds me of some code I stumbled on recently, where
| someone had implemented a custom exception they could throw
| if their 32-bit loop counter was greater than the maximum
| value of a 32-bit integer.
| CodeWriter23 wrote:
| It's the void that comes after the last particle in the known
| universe.
| epistasis wrote:
| I took the first one, nobody else take it or it will no longer be
| a UUID.
| fmbb wrote:
| You can sell it as an NFT. That way it is still unique but you
| can pass it along.
| all2 wrote:
| The creator should add a button to mint an nft on his custom
| side chain.
| HanyouHottie wrote:
| I hate and love this idea simultaneously. Thank you.
| Eikon wrote:
| 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 :)
| sureglymop wrote:
| Does it index subdomains by certs issued? What about wildcard
| certs? Or sites that accept all possible subdomains?
| ekzy wrote:
| 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!
| dylan604 wrote:
| They should set up a reservation database and sell vanity UUIDs
| for trendy LA people
| chis wrote:
| 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.
| worble wrote:
| And support autoscroll too, if possible (where you click middle
| mouse to scroll)
| Aachen wrote:
| 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
| manmal wrote:
| > 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.
| perdomon wrote:
| I think we broke it :(
| rosmax_1337 wrote:
| The ability to bookmark your favorite ones, now that's art.
| buremba wrote:
| damn, my password is here
| lxgr wrote:
| Seems like I got lucky - I have a "G" in mine!
| atonse wrote:
| 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.
| Aachen wrote:
| 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
| jherskovic wrote:
| Looks like the end boss of yak shaving. Very fun, silly idea and
| a great implementation.
| croes wrote:
| Seems like some hacker leaked all UUIDs.
|
| Check if your UUIDs are part of the leak.
| sureIy wrote:
| Wait till someone files a CVE
| Traubenfuchs wrote:
| I am sure our IT security department would jump right on to
| that if informed of it...
| kibwen wrote:
| This is the biggest hack since every ATM PIN was leaked:
| https://pastebin.com/SmJRB8eQ
| tombert wrote:
| 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.
| ethanjstark wrote:
| Mine too.
|
| Takes me back to when my password was leaked:
|
| https://github.com/danielmiessler/SecLists/pull/155
| 0xbadcafebee wrote:
| could we fix this by adding '\n' to the password? then it
| wouldn't be guessed, the hackers would just think it was
| the end of the password
| Y_Y wrote:
| That's why I put a newline in my username.
| hk1337 wrote:
| Don't worry, I already checked your account and there
| wasn't anything there to take.
| quietbritishjim wrote:
| 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.
| extraduder_ire wrote:
| 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.
| jiggawatts wrote:
| That provides very valuable information: DO NOT TRUST
| this machine to be secure!
|
| Similarly, any web site or app that can't correctly
| handle a space character at the end of the password
| should never be trusted with anything of consequence.
| quietbritishjim wrote:
| Are you really worried that a card machine is going to
| leak your PIN? That doesn't seem to be a common attack
| vector compared to a third-party skimmer being attached
| or someone just mugging you and demanding your PIN under
| threat of physical violence.
|
| To answer the actual question: I don't know because I
| left my PIN at 4 digits, despite knowing I could use
| more, precisely because I didn't think it would really
| make my life any more secure.
| jiggawatts wrote:
| I'm not worried specifically about the PIN leaking.
|
| The concern is that a 4-digit max PIN length is certainly
| implemented by someone who couldn't be bothered to _read
| the spec_ for secure credit card transaction handling.
|
| It's the equivalent of the "No brown M&Ms" clause or
| "Canary in the coal mine" test.
|
| Nobody _actually_ cares about the M &M color or some dumb
| bird.
| lxgr wrote:
| "Must support 6-digit PINs" is not part of "the spec for
| secure credit card transaction handling" - which is also
| not a (or at least one) thing: There are dozens of card
| networks, and many of them have tons of regional
| variations.
|
| In some markets, issuers only allow 4 digit PINs, and
| customers don't expect to have to press an "enter" key
| when they're done entering their 4 digit PIN - so the
| reasonable implementation is to allow only 4 digit PINs,
| or you'll be left with people staring at the ATM/POS
| terminal, waiting for something to happen.
| jiggawatts wrote:
| 4 is the _minimum_ number of digits required, but there
| are over a dozen different PIN block standards, and most
| allow between 4..9 and 4..16 digits:
| https://www.eftlab.com/knowledge-base/complete-list-of-
| pin-b...
|
| Making an ATM that can accept cards from _multiple
| issuers_ (which is the norm these days) and allowing
| _only_ 4 digits is the same category of error as
| requiring that the first character of someone 's last
| name start with a capital letter, or to block symbol
| characters in names.
| alexvitkov wrote:
| > or to block symbol characters in names.
|
| People tend to very very quickly their mind on that one
| once they get a few right-to-left control characters that
| flip over the text layout of the entire program.
| jiggawatts wrote:
| "We'll just not do business with anyone named O'Neill,
| that's just a made-up name designed to trick the database
| with SQL injection."
|
| Also: https://www.ancestry.com.au/name-
| origin?surname=null
| lxgr wrote:
| Are you arguing to just allow any byte in names (which
| are ultimately user-defined input data), including 0x00,
| Unicode byte order markers etc., in a thread about a
| perceived correlation between developers' lack of i18n
| awareness and security bugs no less?
|
| The reality is that there is often a tradeoff between
| keeping your test and edge cases simple via constraining
| allowable inputs and internationalization.
|
| So I think you've got it exactly the wrong way around:
| These limitations might have happened precisely because
| somebody wanted to do the right thing from a
| safety/security perspective by doing overly strict input
| validation, at the expense of
| internationalization/compatibility.
|
| Not saying that that's a good tradeoff in every case, but
| I really don't think you can draw any conclusions about a
| system's security by looking at whether it arbitrarily
| disallows some inputs (or if anything, maybe the
| opposite).
| lxgr wrote:
| I agree: An annoying/avoidable implementation
| shortcoming, but arguably relatively orthogonal to
| security.
|
| > there are over a dozen different PIN block standards
|
| You almost certainly don't need to support all of these
| inside the PIN pad or even ATM/POS. If necessary,
| translation can happen in other parts of the system.
| quietbritishjim wrote:
| Ok, but that doesn't answer my question: what specific
| problem are you worried about that would allow someone to
| steal your money, that isn't incomparably unlikely
| compared to other methods? I'm just not aware of any
| problem that has happened in practice from poorly written
| card reader software.
| lxgr wrote:
| Why? PINs are limited to 4 digits in many markets, so
| it's not exactly extreme for a developer to not consider
| the (to them) edge case of 6 digit PINs on foreign cards.
|
| Conversely, it seems very possible to support 6 digit
| PINs and yet still make a ton of horrible implementation
| mistakes, security and otherwise.
| lobsterthief wrote:
| Why is the space thing inherently insecure? I'm thinking
| bad form validation could trip it up and be considered
| "not handled" vs concerns suggesting plaintext storage
| lxgr wrote:
| It most certainly does.
| hakfoo wrote:
| For some reason, a lot of credit card processing APIs are
| still oriented around physical card machines, so they
| have a lot of fields devoted to self-declaration of the
| available features.
|
| Some of the APIs allow the machine to say "I can accept a
| PIN up to 12 digits".
|
| However, I don't know if anyone 1) actually delivered on
| it and 2) how you'd know in advance just poking random
| devices in stores.
| sltkr wrote:
| 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: [....] [*...]
| [**..] [***.] [****]
| [*****] [******]
|
| And then you hit OK and the PIN is accepted.
| tomtomtom777 wrote:
| It helps, but only temporary. I wouldn't be surprised if
| all 6 digit PINs will be leaked within a few decades.
| banku_brougham wrote:
| No with the rate of development of quantum computers that
| estimate is down to the next few years.
| sltkr wrote:
| Not to worry. We'll just switch to 8 digit PINs and we'll
| be safe once and for all.
| bookstore-romeo wrote:
| My card doesn't even let me include repeating digits in its
| PIN. I suppose it can make a one-off guess more likely than
| one in a thousand to correctly guess my PIN.
| lenocinor wrote:
| Is it repeating in the whole PIN, or in digits next to
| each other? I'm trying to resist the nerd snipe of what
| the total number of possibilities would be in the latter
| case...
| squarehead11 wrote:
| I believe it would be 7290, or more generalized, S(N) =
| 10 * 9 ^(N-1) with N being the length of the code and S
| being the number of combinations (assuming that a decimal
| system is used)
|
| And from there, with variable lengths ranging from L to
| H, S(L, H) = 5/4 * 9 ^(L-1) * (9^(U-L+1) - 1)
|
| So if the bank allows combinations from 4 - 6 digits,
| there would be a total of 663390 combinations to choose
| from.
|
| Now, of course, the bank may decide to go from decimal to
| hexadecimal in the future - or maybe, there systems allow
| only duodecimal. In any case, the formula can be
| generalized further to account for all number systems -
| with B being the base of the system:
|
| S(L, H, B) = (B/(B-2)) * (B-1) ^(L-1) * ((B-1)^(U-L+1) -
| 1)
|
| This is only defined for B > 2 - in binary system,
| there's only ever two combinations which fit the
| constraint
| lxgr wrote:
| Which is honestly not a bad idea, given that somebody
| shoulder surfing or trying to read smudges on the PIN pad
| becomes much easier in the case of repeated numbers.
|
| "1111" would just leave a fingerprint on a single key,
| for example, and only one possible PIN (or maybe 3, if
| the bank/card allows 6 digit PINs).
| hamburglar wrote:
| 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."
| layer8 wrote:
| I hope this gets incorporated into haveibeenpwned.com.
| banku_brougham wrote:
| 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.
| TZubiri wrote:
| Nerd hacker politics, but SSN leaks are no joke.
| greggyb wrote:
| 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.
| cbsks wrote:
| Here you go; every SSN:
| https://github.com/panzertime/every_ssn
| greggyb wrote:
| Thanks. Now I can always double check mine!
| TZubiri wrote:
| It's missing names and addresses and credit scores and
| emails and phones
| lxgr wrote:
| Agreed: The real joke is any organization using SSNs as an
| authentication mechanism (as opposed to an identifier).
| TZubiri wrote:
| Nothing>door>door with lock
|
| Both in terms of security, and in the crime of vulnerating
| it.
| snypher wrote:
| >10b82756-f8b4-4fee-a508-adeadbeef5eb
|
| Oh well, time to reformat
| Dalewyn wrote:
| 2016 called, they want their "Side of Beef" jokes back.
| nomilk wrote:
| 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).
| kbhomes wrote:
| 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/
| nomilk wrote:
| Oh.. ha, gotcha. Thanks for explaining. Incidentally, glad
| uuid's computed on the fly (as opposed to pre-computed) as
| I think the site would require a very (impossibly?) large
| database.
| lxgr wrote:
| If it weren't impossible to store 2^122 128 bit values,
| things would look pretty dire for most cryptographic
| algorithms we use.
| maronato wrote:
| 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.
| lxgr wrote:
| > 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.)
| borplk wrote:
| Looking forward to a "havemyuuidsbeenpwned.com" service :))
| tobyjsullivan wrote:
| 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.
| writtenAnswer wrote:
| Cool Blogpost
| InsideOutSanta wrote:
| 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?
| manmal wrote:
| As with any magic trick, reading the explanation might leave
| you a little disappointed here.
| noman-land wrote:
| I'm the opposite. The magic is not in what the magician
| shows, but in what they elegantly manage to hide.
| sameoldtune wrote:
| 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
| thaumasiotes wrote:
| > 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.
|
| ...but that has nothing to do with what the website is
| doing. The accompanying article specifically calls out the
| fact that it can't be done while maintaining the appearance
| of an unordered list, and therefore it isn't attempted.
| kirubakaran wrote:
| 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.
| InsideOutSanta wrote:
| Genius.
| eieio wrote:
| 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
| lxgr wrote:
| Memorable UUIDs? I think you're on to something here! (Also,
| dibs on 00000000-0000-4321-abcd-000000000001!)
| Nihilartikel wrote:
| We can just make an NFT of each one to make sure they stay
| unique too!
| cubefox wrote:
| Can we make one that says something funny? "B00B" could be
| included.
| kstrauser wrote:
| That's amazing! I've got the same IPv6 address on my
| luggage!
| cubefox wrote:
| The most offensive sentence I could come up with
| leetspeak/hexspeak is this one:
| fe11a710-babe-4150-ace5-b19b1accd1cc
|
| (Yes it's a valid UUID)
|
| (I am so sorry)
| flkiwi wrote:
| Terrible day to be a very specific kind of literate.
| cubefox wrote:
| What a horrible night to have a curse.
| martijnvds wrote:
| You could call it.. l33terate
| kstrauser wrote:
| Have my angry upvote.
| cubefox wrote:
| 1337312473
| kshri24 wrote:
| Got the rest but what is ace5? Aces?
| salawat wrote:
| What? Someone likes Lackadaisy. Nothing wrong with that.
| cubefox wrote:
| Yeah. I could have used "aced" instead ... and perhaps
| "c0ed" instead of "babe". Would have made a bit more
| sense together. Well.
| bmacho wrote:
| fellatio-babe-also-aces-bigblackdicc?
| thaumasiotes wrote:
| > 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.]
| eieio wrote:
| I considered this, but I'd just be so unsatisfied if I
| finished scrolling through all 2^128 rows and realized I'd
| seen some duplicates!
| thaumasiotes wrote:
| I liked the approach movpasd suggested:
| https://news.ycombinator.com/item?id=42346076
|
| With a linear algebra library, you can guarantee that
| you've found the next, or the previous, match in
| sequence. I don't know what the state of the art is for
| fast linear algebra in javascript, though.
|
| (The matrix approach also has the advantage that, when
| your full-text search problem has 2^115 solutions, you
| can compute the one you want, the next one after some
| index, without having to compute them all.)
| eieio wrote:
| I need to learn more linear to be able to appreciate
| this! Gonna do some reading.
|
| very fun to have received so many pointers here,
| hopefully I'll be able to do a follow up blog once I've
| finally let people find all the good UUIDs
| quuxplusone wrote:
| 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 (17415833585
| 801881134805987465/158456324585806817418058661888)". I guess
| if you display it as "1234567 (1.742e28/1.585e29)" then you
| don't even have to cheat that much. :)
| mrastro wrote:
| 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.
| srockets wrote:
| Searching is very similar to a common approach for building a
| naive 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).
| lilyball wrote:
| 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?).
| re wrote:
| 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.
| cyanmagenta wrote:
| 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.
| eieio wrote:
| FWIW I am super interested in this question but feel like I
| don't know how to derive a satisfying answer, maybe because
| the one of my goals here (add "enough" entropy) is a real
| fuzzy "I know it when I see it" sort of thing.
|
| But I'm gonna try to get a few more crypto-knowledgeable
| friends to chat with me about this and write up what I
| learn!
| movpasd wrote:
| My first thought was to use linear transformations over
| Z_2 as a field, as that would create a natural
| interpretation of fixing certain bits as taking a linear
| subspace. Interestingly this leads to the property that
| XOR is preserved.
|
| I implemented this in a very quick and hacky way for 32
| bits. I generated a random boolean matrix M invertible in
| Z_2. To turn an input number x into a corresponding
| number y in an N-bit space, I convert x to binary and
| turn that into a vector of 1s and 0s, then multiply it by
| that randomized matrix to get y. Here are the first few
| y's corresponding to x=0, 1, ...:
|
| 00000000000000000000000000000000
|
| 0xx0x000xx00x0xx000xxx00xxx0x000
|
| x0xx000xxxx0xxx00x000xxx0xx0xx0x
|
| xx0xx00x00x00x0x0x0xx0xxx0000x0x
|
| x0xx0x00xxx0xx0x00xx0x0xx0xx00x0
|
| xx0xxx0000x00xx000x0x00x0x0xx0x0
|
| 00000x0x000000xx0xxx00x0xx0xxxxx
|
| 0xx0xx0xxx00x0000xx0xxx000xx0xxx
|
| ...
|
| (Hoping the non-monospace font doesn't ruin the alignment
| too much.)
|
| Which looks... random-ish? I expect that turning these
| into UUIDs may result in more random-looking sequences.
|
| Not sure how to solve the problem of search with this,
| but the hope would be that the linear structure gives you
| what you need, since fixing bytes on UUIDs should
| correspond to considering linear subspaces of the y
| vectors. Perhaps this can also be used to apply
| lexicographic order on the corresponding x vectors (i.e.:
| ordering the indexes), so that you could jump to each
| UUID matching the search in order.
| thaumasiotes wrote:
| I did some fooling around with this and it seems
| promising.
|
| The first problem is that, when your enciphering function
| is a matrix, f(0) = 0. This looks bad, but we can easily
| solve that problem by starting the webpage sequence at an
| index higher than 0.
|
| I tried to work through a much smaller version of the
| problem* by hand, and it looks like this:
|
| We have our enciphering matrix N: [[1 1
| 1 1 1] [1 0 0 1 1] [1 1 1 0 0]
| [0 1 1 1 0] [1 0 1 0 0]]
|
| and our deciphering matrix D, the inverse of N:
| [[1 1 1 0 0] [0 0 1 0 1] [1 1 1 0 1]
| [1 1 0 1 0] [0 1 1 1 0]]
|
| We want to find the next index whose encipherment ends in
| -110. This sets up a system of equations Dx = y, where
| x_3 = 1, x_4 = 1, x_5 = 0, and y tells us the index of x.
| By multiplying that out, we get: y_1 =
| x_1 + x_2 + 1 y_2 = 1 y_3 = x_1 + x_2 + 1
| y_4 = x_1 + x_2 + 1 y_5 = x_2
|
| So we can freely choose any values for y_1 and y_5, and
| the rest will be filled in by constraints.
|
| Assuming we want the least possible value for y, this
| means we will pick y_1 = 0 and y_5 = 0, which then tells
| us that we want index [0 1 0 0 0], and we can jump to
| there. If we wanted the least possible value for y above
| a threshold (such as the current viewport), we'd pick y_n
| values accordingly.
|
| Instinct tells me that libraries should exist for quickly
| solving systems of linear equations like this.
|
| (For full full-text search, we'd need to do this several
| times, also finding solutions for the enciphered values
| 110xx, and x110x. This multiplies the work we need to do
| and the storage we need to use by an amount that is
| linear in the difference in length between the search
| string and the full UUID, which is still a lot better
| than trial-and-error.)
|
| * I ended up doing it in 5 bits because every random 4x4
| matrix I generated was noninvertible.
| thaumasiotes wrote:
| Following up, using this encipherment scheme and starting
| from a 5-bit seed of 17, you produce values in this
| sequence:
|
| 5, 7, 31, 10, 18, 16, 8, 11, 19, 17, 9, 28, 4, 6, 30, 0,
| 24, 26, 2, 23, 15, 13, 21, 22, 14, 12, 20, 1, 25, 27, 3,
| 29.
|
| This might pass an eyeball test for random when viewed as
| decimal numbers. (Although there sure are a lot of cases
| where adjacent values are 2 apart!) It looks much worse
| as binary. Here's every ones digit, all concatenated into
| a hex string, starting from 17 again:
| e1e01e1f
|
| Let's note that ~(e1e0) = 1e1f. Start from 16 instead and
| you'd see f0f00f0f. Here are the eights:
| 3332bbbc
|
| Individual bits show pretty striking patterns. Since the
| UUID is reported in hex, that can be mitigated a little
| by the fact that each hex digit combines four binary
| columns. But so far it seems pretty likely that this
| would result in the list of UUIDs looking decidedly
| nonrandom. There might be quite a bit of shared material
| between adjacent UUIDs.
| thaumasiotes wrote:
| correction: the run of the eights is 3332cccd, not
| 3332bbbc.
| eieio wrote:
| Hi! I do not know enough of the relevant math to
| appreciate what you're doing here (yet); I am going to
| try to do some reading to understand this better, but if
| you have any advice on where I should start I will gladly
| take it.
| kittoes wrote:
| You've sniped me and I'm going to try and tackle this
| over the weekend. What's the best way to exchange things
| for you? Also, have you explored modular multiplicative
| inverses at all?
| eieio wrote:
| eieiogames@gmail.com is great (or whatever's best for you
| on https://eieio.games/whats-my-deal)
|
| I think the biggest rabbit hole I went down was trying to
| use FEAL (which is very breakable) and exploiting the
| things that make it breakable. But this is very much not
| my area of expertise - I was learning as I was working -
| so it's very possible either that that was a dumb idea or
| that it was a great idea that I didn't figure out.
|
| I also considered things like "focus on add lots of
| entropy to groups of 200 or so UUIDs, but have obvious
| patterns beyond that" which I think would be a reasonable
| strategy; here I just kind of ran out of time (I told
| myself I'd make this in a week)
|
| Did some light reading about a few other things but
| nothing substantial
| mckeed wrote:
| Would it be easier if only the lowest bits of the index
| contributed to the "entropy"? Like if the 2^16th UUID was
| the one right after the first and n + 2^16 was the one
| after the nth. You wouldn't notice the pattern but it'd
| be easier for the computer to handle. I guess if you were
| searching for a substring you might notice the ones
| surrounding the matches look almost the same from match
| to match...
| eru wrote:
| Let me cook something up for you. It's an interesting
| puzzle.
|
| I think you can get pretty far, if you compromise on your
| entropy: it only has to look random, not actually be
| random. (I mean it doesn't have to be cryptographically
| secure randomness.)
| AlotOfReading wrote:
| 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 << 2)) & u122_mask;
| }
|
| This is a T-function, a function where the Kth bit only
| depends on the K-1 lower bits. prf() is a pseudo-random
| function that can be anything you like as long as it's
| another T-function. A standard LCRNG like (48271 * x) %
| 2147483647 works just fine for instance.
|
| 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.
| lxgr wrote:
| A great example of Teller's observation that "sometimes magic
| is just someone spending more time on something than anyone
| else might reasonably expect."
| Terr_ wrote:
| > Ninety per cent of most magic merely consists of knowing
| one extra fact.
|
| -- _Night Watch_ by Terry Pratchett
| shwouchk wrote:
| Thanks for this reference to one of my favorite books of
| all time, out of one of my favorite series of all time
| Dalewyn wrote:
| Sufficiently advanced technology is indistinguishable from
| magic, as the saying goes.
| sorokod wrote:
| But the Terry Pratchet quote above indicates that magic is
| only skin deep
| albedoa wrote:
| We might then interpret Pratchet to be commenting on the
| floor and mode of "sufficiently advanced" ("skin deep")!
| dhosek wrote:
| 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.
| lxgr wrote:
| The best part is that that kind of trick usually becomes
| more, rather than less, impressive when its inner working
| is revealed. I recently got to see them perform live, and
| my favorite trick by far was one of that kind.
| js2 wrote:
| Penn only agreed to the "Red Ball" trick after Teller hit
| on the idea to tell the audience how it works at the
| start.
|
| https://lasvegasweekly.com/news/2008/nov/20/man-ball-
| hoop-be...
|
| https://www.thisamericanlife.org/619/transcript
|
| https://www.youtube.com/watch?v=dhnATlPdG6A
|
| Here they are showing how they do ball & cups by using
| clear cups and it's no less amazing:
|
| https://www.youtube.com/watch?v=8osRaFTtgHo
| dhosek wrote:
| I love these and my kids who are a little obsessed with
| stage magic right now are at the perfect age for Penn &
| Teller videos so I need to stash these for the next time
| I have them. There's definitely skill levels involved,
| even at the professional level (and Penn & Teller are
| definitely among the best out there). We've been to two
| professional magic shows in the last year, one in
| Wisconsin Dells, the other in Lake Geneva (both venues
| starring their owners) and it was apparent that the Dells
| guy was much better than the Lake Geneva guy (although
| the second magician the Lake Geneva guy had some
| impressive work to show).
| bsder wrote:
| Watching Teller do the cups and balls trick with
| transparent cups is mesmerizing.
|
| Yes, you can see everything. No, you still can't follow
| it.
|
| Sure, you can see that "something changed" after the fact
| when it is stable. However, Teller is so damn smooth and
| fast that any active change looks like teleportation.
| aidenn0 wrote:
| There was a video of a magic trick I saw where the trick
| was almost certainly accomplished by false shuffles. I
| know how to do a few false shuffles, in theory, but, the
| magician (Ricky Jay, I think?) was just so good at the
| false shuffles that I was more impressed than if I didn't
| know how it was done.
| instalabs wrote:
| Awesome - this will be my new coding interview question
| Freedom2 wrote:
| 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.
| ljm wrote:
| So I just brute forced every UUID in existence on my RTX
| GPU and loaded the dataset into a HA opensearch cluster on
| AWS. It took about 5 years of calling 'uuid.Random()' to
| effectively cover about 64% of the keyspace which is good
| enough.
|
| To facilitate full-text search I created a langchain
| application in python, hosted on kubernetes, that takes
| your search query and generates synonymous UUIDs via GPT
| o1-preview before handing over to opensearch.
|
| Opensearch returns another set of UUIDs, which I look up in
| my postgres database: "SELECT uuid FROM uuids WHERE id IN
| (...uuid_ids)"
| saagarjha wrote:
| Did future aliens send you their quantum GPUs or what?
| schobi wrote:
| I could imagine some candidates starting with their
| default tools like this, and start complaining about the
| cluster performance after a few weeks.
|
| You need a certain way of thinking to have a gut feeling
| "this could be expensive" and then go back, question your
| assumptions and confirm your requirements. Not everyone
| does that - better to rule them out.
| moritzwarhier wrote:
| 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.
| thaumasiotes wrote:
| > 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.
| nharada wrote:
| The blog write-up is incredible -- technically interesting,
| hilarious, and perfect in both tone and scope. Well done!
| mackieem wrote:
| 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!
| vivzkestrel wrote:
| 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
| soheil wrote:
| yet I was able to scroll through them like scrolling through
| a 800-word web page
| soheil wrote:
| 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.
| dietr1ch wrote:
| 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`.
| belter wrote:
| 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.
| c0nsumer wrote:
| When I hit print in Firefox it only is one page long. :(
| schoen wrote:
| 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.
| cbsmith wrote:
| Only has type 4 UUIDs. ;-)
| CodesInChaos wrote:
| Looks like they just changed the subtitle from "In case you
| forgot one" to "Well, only the V4 ones".
| cbsmith wrote:
| :-)
|
| Actually, it looks like it alternates between those two
| phrases.
| junek wrote:
| Sometimes I feel bad when I generate a UUID without using it for
| anything. Like I've wasted it.
| evan_ wrote:
| You're not the only one who feels this way:
| https://wasteaguid.info/
| puttycat wrote:
| This is just perfect.
| extraduder_ire wrote:
| There's enough of them that you're saving a scarcer resource by
| not recording it anywhere.
| netcraft wrote:
| how bad do you feel about all the uuids you didnt generate so
| were never born?
| banku_brougham wrote:
| 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.
| zoky wrote:
| Seriously, this just seems like a frivolous waste of a precious
| and rapidly dwindling resource...
| billpg wrote:
| 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!
| kk3 wrote:
| Finally a use case for creating a table with a million rows in
| React.
| anyfoo wrote:
| You're going to need a smidge more than that.
| nom wrote:
| now sort them alphabetically
| CodesInChaos wrote:
| Sorting them lexically would be trivial. Just calculate the
| index via the reverse permutation, similar to how search works.
| wavemode wrote:
| Compression is now so advanced, we can browse web pages weighing
| over 340 undecillion bytes.
|
| We truly live in an age of wonders.
| 55873445216111 wrote:
| I am pretty sure this sets a new record for highest Weissman
| score
| impish9208 wrote:
| Middle-out truly is revolutionary
| saagarjha wrote:
| 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".
| function_seven wrote:
| Meh. Years ago I had my bakeries churning out undecillions of
| units no problem in Cookie Clicker. No big deal!
| xg15 wrote:
| They just don't make em like they used to...
| Devasta wrote:
| 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.
| worble wrote:
| Typical, I'm always late and the good ones are already taken
| ticulatedspline wrote:
| 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.
| RGamma wrote:
| I was gonna mention that so people have something to read when
| they finished the UUIDs.
| bufferoverflow wrote:
| 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.
| noncoml wrote:
| You fool! You destroyed the universal uniqueness now!
| NBJack wrote:
| 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!
| CodesInChaos wrote:
| 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.
| AlotOfReading wrote:
| 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".
| lxgr wrote:
| Oof, mine are on there. Guess I'll have to rotate them now :/
| a12k wrote:
| Super weird coincidence but I spotted a UUID in here that I had
| previously used!
| atonse wrote:
| 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.
| LeifCarrotson wrote:
| The name and address is at everyUTF8string.com. You might have
| to scroll a while, though...
| atonse wrote:
| Thank you. I started scrolling 4 hours ago and am yet to
| encounter my first address.
| eieio wrote:
| I'm so sorry - we'll start working on a feature to redact UUIDs
| after we figure out how to handle GDPR compliance
| n42 wrote:
| this brings me joy.
| lxgr wrote:
| Neat idea, excellent implementation!
|
| Now I kind of want to do this for "every 12 character
| password"...
| sidcool wrote:
| This is beautiful.
| sidcool wrote:
| Can someone ELI5? How's he ensuring uniqueness of a UUID when
| they are randomly generated?
| ARandumGuy wrote:
| 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.
| charlieboardman wrote:
| 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.
| saagarjha wrote:
| They are; the blog post explains why.
| function_seven wrote:
| 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...
| Lammy wrote:
| 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": irb> ::Array::new(122, 0b1).reduce { (_1
| << 1) | _2 } => 5316911983139663491615228241121378303
| Tuna-Fish wrote:
| 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.
| jonny_eh wrote:
| 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
| netcraft wrote:
| for a minute I thought this was a domain reseller that was
| offering .com uuid domains
| layer8 wrote:
| This needs an "I'm Feeling Lucky" button.
| a3w wrote:
| I looked for deadbeef-f00d-f00d-deadbeef**
|
| but did not find it. Search is just on active page, that gets
| ever longer?
| Aachen wrote:
| 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?)
| s4i wrote:
| That's not a valid UUID? The version and variant parts are
| missing.
| osamagirl69 wrote:
| 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
| taftster wrote:
| 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.
| cdfuller wrote:
| Please add a button to export to Excel.
| dumbfounder wrote:
| 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.
| sergiotapia wrote:
| 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!
| sjm wrote:
| np, I'm taking deadbeef-beef-4000-beef-deadbeefdead
| efitz wrote:
| 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.
| chrisandchris wrote:
| 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.
| usr1106 wrote:
| What will be the bill?
| efitz wrote:
| I think all the money
| zaptheimpaler wrote:
| 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.
| xg15 wrote:
| Who needs infinite scroll when you can have technically finite
| scroll!
| xg15 wrote:
| This is amazing! I can finally get that vanity UUID I was
| dreaming of for so long!
| gavinsyancey wrote:
| The search seems to be missing
| `c12a7328-f81f-11d2-ba4b-00a0c93ec93b`
| tln wrote:
| That's a version 1 UUID, site only has version 4's
| senko wrote:
| This only contains V4 UUIDs. Disappointed.
| modeless wrote:
| Seems like the only feature missing (besides social sharing
| mentioned in the blog post) is deep linking to specific UUIDs.
| jvanderbot wrote:
| 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: 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.
|
| What was the number? What were the steps?
| booleandilemma wrote:
| Jeff Bezos' net worth?
| redundantly wrote:
| 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.
| jvanderbot wrote:
| Yes! Nice find thank you.
| tempestn wrote:
| 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.
| jvanderbot wrote:
| I found a text version of the same (?) thing:
| https://czep.net/weblog/52cards.html
| tln wrote:
| https://www.tiktok.com/@mrgeemath/video/7353832903404490027?...
| concerndc1tizen wrote:
| 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.
| delecti wrote:
| 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).
| skrause wrote:
| It was 52!, the number of possible permutations of 52 cards:
| https://czep.net/weblog/52cards.html
| Arch-TK wrote:
| 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.
| gibibit wrote:
| 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
| tills13 wrote:
| It's merely a trick of windowed scrolling.
| zellyn wrote:
| You can also use something like DES3 to get a bijection. Easier
| if it fits in 64 bits so you only need one block.
| bicx wrote:
| 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.
| switch007 wrote:
| 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
| peterpost2 wrote:
| 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!
| qingcharles wrote:
| I'd prefer if it used AI to pick one that was aesthetically
| pleasing. I can file a PR if you like?
| sa-code wrote:
| Could you please add a function to check if a uuid exists?
| pie_flavor wrote:
| 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)
| theonewolf wrote:
| I found the Pi UUID:
|
| 185e45bc-750b-43d7-91ee-314159265358
| BubbleRings wrote:
| Ha. Math geek.
| theonewolf wrote:
| I found the Pi UUID: 185e45bc-750b-43d7-91ee-314159265358
| babyshark233 wrote:
| There are a lot. like this:
| aac8022d-350a-4c3e-9012-314159265358
| empty_space wrote:
| 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.
| globular-toast wrote:
| I wonder how many test suites this is going to show up in...
| therealdrag0 wrote:
| My inner middle schooler is also satisfied
|
| B00B1E5f-7117-4a61-816d-92710147f63f
| atulvi wrote:
| wow. this is so cool
|
| TIL aaaaaaaa-aaaa-4aaa-aaaa-aaaaaaaaaaaa is a valid uuid
| NathanaelRea wrote:
| 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.
| grahamj wrote:
| 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 :)
| retr0grad3 wrote:
| I'm now the proud owner of
| 69ac8bd2-4ca0-4dd9-82b5-60fabec0b404.com
| sam0x17 wrote:
| lol I misunderstood, I thought someone had searched for every
| domain name that happens to be a valid UUID
| Cotterzz wrote:
| What percentage of the 100+ Zettabytes of data now on the
| internet does this page take up?
| maronato wrote:
| Around 9,400,000,000,000,000,000%
| ForHackernews wrote:
| Shoutout `deadbeef-91c5-4ef3-b6d9-0a1c95775b4d`
| jongjong wrote:
| UUIDs are the best.
| TZubiri wrote:
| There's a fine line between a hacker's cool personal project and
| a schizophrenic's magnum opus
| layer8 wrote:
| 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.)
| NautilusWave wrote:
| 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.
| shayonj wrote:
| > 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
| chamomeal wrote:
| Holy shit it's a real life library of babel!!
| zaken wrote:
| 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)?
| savef wrote:
| 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#...
| Dylan16807 wrote:
| 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.
| savef wrote:
| I see what you mean, but I was going by the definition of
| "UUID" used on everyuuid.com. The UUID of 32 "f's" isn't in
| the list.
| MBCook wrote:
| 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?
| savef wrote:
| I guess it's pretty subjective, but not all numeric types
| are signed, so I'm happy with my answer.
| MBCook wrote:
| Your answer is good, mine was meant as a joke.
| shreddit wrote:
| Because the 4 is always "4", it denotes the version (uuid v4)
| Dylan16807 wrote:
| 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.
| ajsfoux234 wrote:
| The 4 indicates UUIDv4.
|
| If you were looking for the biggest hexadecimal UUID, find one
| with f instead of 9.
| dmlittle wrote:
| 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
| saagarjha wrote:
| The last line of https://xkcd.com/566/, except it's UUID
| formats.
| Dylan16807 wrote:
| Are you suggesting we should never have made the random
| one, and stuck with mac address plus timestamp forever?
| saagarjha wrote:
| I actually believe we shouldn't have made any of them
| Dylan16807 wrote:
| Oh okay. That's a pretty different suggestion from the
| comic.
|
| Would you suggest random 128 bit numbers, then? Otherwise
| it's hard to see what else would serve the same role
| without being UUID in a trenchcoat. And having
| identifiers is important.
| saagarjha wrote:
| Yeah I would really like if UUID was just 128 bits of
| randomness and nothing else. The whole version thing
| sucks, and my point (which you are right in that the
| ordering is a little off) is that UUIDv4 is the only good
| one and the rest basically should not exist. UUIDv4
| itself is ruined by the fact that it needs to have a
| version embedded in it because the other ones exist.
| zzo38computer wrote:
| I think object identifiers would be better, althoug they
| should add another arc that does not require
| registration, based on: (fixed prefix).(type of
| identifier).(number of days past epoch).(parts according
| to type of identifier).(optional extra parts). (I had
| partially written my proposal, and I would want ITU
| and/or ISO (preferably ITU) to approve it and then manage
| it.) For example, type 0 could mean international
| telephone numbers, type 1 could mean version 4 IP
| address, type 2 could mean domain names (encoding each
| part as bijective base 37, from right to left), 3 could
| mean a combination of geographic coordinates with radio
| frequencies, 4 could mean telephone numbers with auto-
| delegated telephone extensions, etc. (I had also
| considered such things as automatic delegation, clock
| drift, etc; it is more carefully considered than UUID and
| some other types of identifiers.)
| Dylan16807 wrote:
| Sounds like you're in the realm of URNs? I don't know
| about that description, I think there's a benefit to a
| short and fixed-size ID. Though maybe for the domain name
| example you could have an alternate form that hashes any
| domain that goes over 20-30 characters.
| 29athrowaway wrote:
| A testament of how optimized web browsers are.
| motohagiography wrote:
| 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?
| kevincox wrote:
| 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.
| motohagiography wrote:
| 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.
| Dylan16807 wrote:
| There are 6 fixed bits. The other two are in the 17th hex
| character.
|
| But overall you have that right. Every bit is either
| completely random or fixed. There are no reduced-randomness
| patterns unless you generated it wrong.
| scotty79 wrote:
| 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.
| pontifier wrote:
| I remember seeing one of these for Bitcoin addresses a long time
| ago... Very funny :)
| jonathrg wrote:
| Please remove my UUID 039a69dc-b0a1-4be0-b424-5e45aca8d3fb from
| the list. I spent a lot of money on it
| kixpanganiban wrote:
| Hehe 12345678-b00b-4123-b00b-b00b13551234
| jonstewart wrote:
| This is like if Wes Anderson was a computer scientist.
| mc10 wrote:
| 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.
| eru wrote:
| > 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.
| eru wrote:
| 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.)
| technoabsurdist wrote:
| can someone explain how this manages to list all 2^122 uuids?
| quink wrote:
| 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.
| jdlyga wrote:
| This is a major incident. All of our uuids were leaked!
| IncRnd wrote:
| It can't be a coincidence that, as I read this UUID page, there
| are 255 comments before mine.
| lacoolj wrote:
| A very nice demo of how to render a page. If it weren't for that
| I would be very confused why this exists
| chrismorgan wrote:
| > _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 230
| 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 (230 - 1 hundredth pixels).
|
| * WebKit: clamps values somewhere around 225 (~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.5x display, so the 225
| could be connected with device pixels or such. But I think I was
| on a 2x 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.
| thewisenerd wrote:
| 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
| eieio wrote:
| 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)
| textlapse wrote:
| 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
| dirkc wrote:
| 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.
| thih9 wrote:
| 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.
| adhamsalama wrote:
| Can this be turned into a SAAS? I'm tired of copying ids.
| dzaima wrote:
| 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.
| naranha wrote:
| 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
| wildlogic wrote:
| b00bb00b-b00b-4444-b00b-b00bb00bb00b
| schobi wrote:
| 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...
| twwwt wrote:
| 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").
| dsego wrote:
| "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.
| Cloudef wrote:
| ah the 0xdeadbeef of UUIDs deadbeef-6265-4780-9167-555689902667
| indulona wrote:
| but why?
| guandor wrote:
| 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?
| philippwoz wrote:
| Its hex. Only characters A-F are used.
| seafoamteal wrote:
| These are hexadecimal digits, so only 0-9 and a-f are allowed.
| atjallen wrote:
| 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.
| jari_mustonen wrote:
| It seems that 00000000-0000-4000-8000-000000000000 is the
| "smallest" UUID generated by
| 2645248903793120745936665251644898482.
| 082349872349872 wrote:
| > _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?
| dmd wrote:
| These were all, of course, already available in Borges' library.
| bartread wrote:
| What am I missing here? What is the purpose of this?
| Eriks wrote:
| perfect website for mouse scroll wheel benchmark
| IE6 wrote:
| 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).
| devoutsalsa wrote:
| Every social security number! (0..999999999).
| map { |i| i.to_s.rjust(9, "0") }. map { |i| i[0..2] +
| "-" + i[3..4] + "-" + i[5..9] }
| aftbit wrote:
| >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.
| wild_pointer wrote:
| I starred my UUID of choice. Now I can't find it. Help, I've been
| scrolling for three days.
___________________________________________________________________
(page generated 2024-12-07 23:01 UTC)