[HN Gopher] The UX of UUIDs
___________________________________________________________________
The UX of UUIDs
Author : jlaneve
Score : 92 points
Date : 2024-04-08 22:39 UTC (3 days ago)
(HTM) web link (unkey.dev)
(TXT) w3m dump (unkey.dev)
| compressedgas wrote:
| Except that UUIDs by themselves don't do this at all:
|
| > They provide a reliable way to ensure that each item, user, or
| piece of data has a unique identity.
|
| It is the registration of a UUID in a database which prohibits
| reuse that does that. If you aren't do doing that, ensuring that
| each use of a UUID is not a reuse of an already assigned UUID,
| they are not UNIQUE.
| umpalumpaaa wrote:
| Did you read the full article?
|
| "Reducing the length of your IDs can be nice, but you need to
| be careful and ensure your system is protected against ID
| collissions. Fortunately, this is pretty easy to do in your
| database layer. In our MySQL database we use IDs mostly as
| primary key and the database protects us from collisions. In
| case an ID exists already, we just generate a new one and try
| again. If our collision rate would go up significantly, we
| could simply increase the length of all future IDs and we'd be
| fine."
| roywiggins wrote:
| Strictly speaking you can't be sure that your UUIDv4 isn't
| (by pure luck) also in someone _else 's_ database, so it's
| not guaranteed to be _universally_ unique. It 's just very,
| very likely to be so.
| partdavid wrote:
| For some value of "strictly speaking", this is true; but
| it's not a very relevant value. You can't be "sure" your
| counter never produces a duplicate, either--strictly
| speaking--in reality. The bug-free program or the computer
| that isn't affected by external factors is like the
| friction-free surface: sometimes useful to think about but
| not something that exists in reality. And the likelihood of
| a cosmic ray causing a bit flip or a race condition in the
| way your counter updates is a lot higher (as in, we see it
| happen _all the time_ ) than the theoretical likelihood of
| a collision on a sufficiently large and random key.
| vesinisa wrote:
| > by pure luck
|
| No, even that is not true. If _all_ digital (and non-
| digital) storage media ever manufactured by humans -
| meaning all hard drives, tape drives, CDs, DVDs, BluRays
| etc. ever manufactured to date, and every book and word
| ever printed or written down. If those ALL were only filled
| in with UUIDv4s generated from a good random source .. you
| would still not see even one single collision!
|
| UUID collisions are only possible with currently known
| human technology if your randomness source is not good
| enough. And it will remain so unless there are some
| astronomical leaps in digital information storage
| technology - at least 10 orders of magnitude more storage
| than currently exists.
|
| EDIT: I thought of a way for programmers to mentally
| visualize how unlikely UUID collisions really are. Let's
| imagine that in some not-too-distant future, there are 10
| billion people on Earth. Each of them are given one
| thousand CPUs. These CPUs have 1024 cores each, and they
| run at 10 GHz (clock cycles per second). The CPUs implement
| a hypothetical instruction that can generate a totally
| random UUID in _one_ clock cycle.
|
| As an experiment, all people on Earth one day decide to
| program all their thousand CPUs each to run a tight loop
| that will indefinitely generate UUIDs on all 1024 cores and
| then immediately discard them.
|
| After continuing to run this experiment (whose electicity
| bill will make Bitcoin look like Earth Hour) all day, 24/7,
| for about 800 years, the likelihood of one UUID ever having
| been generated twice will have exceeded 50%.
| kwantam wrote:
| I'm sorry to say that your analysis is wildly incorrect.
|
| - 10 billion people =~ 2^33
|
| - 1000 CPUs =~ 2^10
|
| - 1024 cores =~ 2^10
|
| - 10 GHz =~ 2^33
|
| So: one second's computation by all of these people is
| 2^86 UUIDs generated. UUIDs are 128 bits. With
| probability essentially 1, there will be a collision
| within one second.
|
| The reason is known as the birthday paradox. If you
| sample random values from a set of size k, after you've
| chosen about sqrt(k) values you will have chosen the same
| value twice with probability very close to 1/2. By
| 10*sqrt(k) samples you'll have found a collision with
| probability well over 90%.
|
| In this case, after sampling 2^64 values you'll have a
| collision with probability 1/2. That happens in roughly
| 250 nanoseconds (2^-22 seconds) in your thought
| experiment.
|
| 2^64 sounds like a lot, but in many contexts it's not all
| that much. Every bitcoin block mined takes well in excess
| of 2^70 SHA evaluations. Obviously the miners are not
| dedicated to generating UUID collisions, but if they were
| they'd easily find thousands of them in the time it takes
| to mine one block (this neglects the fact that it is much
| easier to sample a UUID than to evaluate double-SHA256).
| vesinisa wrote:
| > The reason is known as the birthday paradox.
|
| Right. Forgot about that little thing. You're absolutely
| correct.
|
| With this taken into account a _single_ person with 1000
| pieces of 1000-core, 10 GHz CPUs generating UUIDs will
| generate a match in a few minutes.
| wongarsu wrote:
| If you ensure each UUID is generated to spec, using a good
| source for the random bits, they are astronomically unlikely to
| collide without any coordination. Choosing the same 124 bits at
| random just doesn't happen by chance.
|
| Of course you have to deal with the implications of people
| intentionally colliding UUIDs, so maybe don't generate them
| client-side.
| tossandthrow wrote:
| that is not correct and borders wrong.
|
| a reason to use uuid (eg v4) is that you can generate id's
| distributed without fearing collisions. it can happen, but is
| not likely.
|
| so the uniqueness comes from a property of the ID and not the
| database.
| partdavid wrote:
| In the real world, the likelihood that a bug in your database
| engine or ID-hander-outer (a race condition, storage edge case
| or the like) is a lot higher than the risk of collision on a
| sufficiently large and random key.
|
| The whole point of using UUIDs is that you can generate them
| locally without central coordination--if you want to coordinate
| your identifiers, you can use a much friendlier ID length
| (which is explained in the article).
| kevincox wrote:
| But you still need to be wary of malicious collisions. I have
| seen security vulnerabilities where the client generates a
| UUID ID and that was inserted into the database. However by
| picking an ID that corresponded to objects from other users
| it was possible to gain some access to those objects.
|
| So any UUID coming from an untrusted source (like a client
| application) should be checked for uniqueness. However your
| client apps can be written assuming that their randomly
| generated UUIDs never have collisions.
| echoangle wrote:
| Why would you let the client generate the IDs? If you have
| to check them anyways, just generate them on the server and
| only give the ID to the client.
| kevincox wrote:
| It can be very useful for offline work and latency
| hiding. For example the client can generate data
| structures with the final IDs then sync them to the
| server. This can also be useful for implementing
| idempotent updates.
|
| The alternative of having some sort of "placeholder ID"
| until the sever gets back to you (or you get back online)
| adds a lot of client complexity.
| echoangle wrote:
| Can't you just give the client a list of generated IDs on
| the first request and check if the IDs are from the
| pregenerated IDs afterwards? That should be a lot cheaper
| than checking all IDs you ever generated.
| kevincox wrote:
| You can do that I suppose. But I have found that in most
| cases I have a unique index on the ID anyways, as they
| are often table primary keys. So really I just have to
| ensure that it is either an INSERT or an UPDATE to a
| record that is owned by the user.
| echoangle wrote:
| Then you don't really have the problem this is about
| though, and which UUIDs are supposed to solve. The real
| pro of UUIDs is that you can issue them in distributed
| situations where you can't look up the already used IDs
| easily.
| pie_flavor wrote:
| You'll see your first duplicate already-assigned v4 UUID
| (anywhere on earth) in a few thousand years.
| vesinisa wrote:
| What part of "universally unique" in Universally Unique
| Identifier (UUID) you don't understand? They are specifically
| designed so that you can generate them locally without fearing
| collisions. That's like.. their entire point.
| cryptonector wrote:
| That's an aspiration, not a guarantee.
| dragonwriter wrote:
| One of the major motivations for UUIDs is that you can generate
| them in a decentralized fashion, without central registration,
| with a very high degree of confidence that they will not be
| repeated, a _very important_ feature in distributed systems
| where you don't want to rely on a either a central point of
| failure or the need for distributed consensus just to generate
| an ID for data elements.
| shinzui wrote:
| The author seems to be unaware of TypeID. You can use TypeID and
| ignore this article.
|
| https://github.com/jetify-com/typeid
| graypegg wrote:
| Is this particularly widely used? I don't think I'm aware of
| TypeID either. I don't see why the author's pretty light
| solution is inferior to this library.
| shinzui wrote:
| Because TypeIDs are compatible with UUIDv7 and are supported
| by libraries in many languages.
| layer8 wrote:
| Underscore has usability drawbacks.
| sparklingmango wrote:
| Like what?
| taco-hands wrote:
| It's 'oldskool' _ although, frankly, if someone can't find
| it on a keyboard, they should be condemned to a life full
| of auto-correct errors.
| paulddraper wrote:
| Or rather, the article is the explanation of typeid?
| ForHackernews wrote:
| I'm a big fan of the similarly obscure TagURI for unique
| identifiers https://taguri.org/
| djbusby wrote:
| Can use ULID to "fix" some issues
|
| https://github.com/ulid/spec
| fnord123 wrote:
| Ulid should wholly be deprecated now that uuidv7 is available.
| BiteCode_dev wrote:
| Ulid have a short representation that uuid7 could use but
| doesn't define. Also, has UUID7 been standardized already? I
| thought it was still in the pipeline.
| dagss wrote:
| As a Microsoft SQL user (not everyone can choose their DB..),
| UUIDv7 has the issue that people will (understandably, but
| ignorantly) store it in "uniqueidentifier", which shuffles
| bytes around and are no longer sorted on time... ..
|
| There is even a specific Microsoft SQL-time-ordererd UUID
| format which is sorted after byte shuffling..
|
| We store ULID in binary(16). Works nicely. Only difference
| from UUIDv7 is the version bits..
| hermanradtke wrote:
| Why? It does not suffer from some of the UX issues this
| article discusses.
| IncreasePosts wrote:
| Why would readability of a UUID matter? At most, users should by
| copy-pasting them, not reading them or trying to memorize them,
| so why should I and l and 1 looking similar matter?
| shhsshs wrote:
| The author mentions UUIDs are hard to copy/paste because of the
| hyphens.
| IncreasePosts wrote:
| Right, and that is a fine idea to get rid of the
| hypens(personally, I just triple click) - I'm talking about
| the next section.
| Terr_ wrote:
| The easy fix is underscores.
| partdavid wrote:
| Well, point one of the article is that they're unnecessarily
| hard to copy-paste.
| esafak wrote:
| It could help when you're manually inspecting a list of UUIDs?
| AirMax98 wrote:
| > TLDR: Please don't do this:
| https://company.com/resource/c6b10dd3-1dcf-416c-8ed8-ae56180...
|
| But like... why? This article literally does not explain the
| benefits beyond copying, they are just assumed. I'm not
| immediately sold on shorter === better, especially when the
| updated UUIDs are only marginally shorter and you have now
| introduced the overhead of a translation layer for one of the
| most basic building blocks in your application.
| mynameisvlad wrote:
| I thought it was fairly well reasoned in the article.
|
| Let's say you have a customer with that UUID as their ID. Do
| you expect them to recite their UUID perfectly to you every
| time? What if they made 5 transactions, each with their own
| UUIDs and you need to look them up, do you now expect them to
| read out 6 fairly unwieldy IDs?
|
| The article is about the _UX_ of UUIDs. Yes, there 's a
| translation layer and more dev work to implement, but the
| shorter size and use of non-ambiguous characters is a _massive_
| improvement in the usability for the end users.
| swyx wrote:
| i keep a list of UUID reading and desirable properties here!
| https://github.com/swyxio/brain/blob/master/R%20-%20Dev%20No...
| iimblack wrote:
| This is amazing thank you for sharing.
| mik3y wrote:
| Nice list, found a couple projects I hadn't seen before.
|
| My addition for your consideration:
| https://github.com/mik3y/django-spicy-id
| esafak wrote:
| It would be possible to bookmark and refer to individual
| articles if you'd used gist instead of github.
| Terr_ wrote:
| > One way to enhance the usability of unique identifiers is by
| making them easily copyable. This can be achieved by removing the
| hyphens from the UUIDs,
|
| No! That's throwing the baby out with the bathwater! Removing all
| separators means rare-but-important manual tasks of transcription
| or comparison become terrible, since there are no clear chunks.
|
| Instead use a different character which doesn't have the same
| problem, one that most software considers part of the same
| "word"... such as the classic underscore.
|
| For most people, double-clicking on this 123_456_789 will select
| all 9 important numbers. (And maybe a trailing space, but that's
| a separate problem.)
| ssl-3 wrote:
| Is there an unambiguous, accepted, monosyllabic way to verbally
| speak the _ character?
| mcherm wrote:
| No.
|
| There also isn't one for "w", yet we get by with that as a
| letter.
| lelanthran wrote:
| > There also isn't one for "w", yet we get by with that as
| a letter.
|
| Warning: Tangential rant ahead.
|
| I'm teaching my toddler to read (Distar alphabet).
|
| Even with the modified alphabet, it's a chore to "know" how
| to pronounce a letter.
|
| 'a' has at least 4 different pronunciations in words used
| by toddlers: apple, came, eat, bread.
|
| All the vowels are like that, and even some consonants ('y'
| has at the very least: baby, yesterday, cycle, buy)
|
| The only well-behaved letter in English is 'x': pronounced
| the same wherever you see it, as 'cks'[1].
|
| [1] For toddlers, anyway. I doubt a 4-year old would be
| interested in LaTeX :-)
| __float wrote:
| Unless it's at the beginning of a word, like xylophone?
| revlolz wrote:
| If "underscore" gets tedious I just say "tac"
|
| But I get that it's confusing with dashes.
| Terr_ wrote:
| Alas, no... however you might not need a sound if you can use
| tonal inflections and pauses to express the boundary instead.
| Particularly when chunks are short and when the receiver (or
| the software they're typing into) knows the format already...
| Although with a tech-illiterate relative you'll have bigger
| problems, like explaining what an underscore even looks like
| and where it is on their keyboard.
|
| Obviously I can't fully express it in text here, but try to
| imagine this as a coworker speaking to you: "Hey, write down
| this IP address. It's ten, seventy, one twentyyyyyTWO, five."
|
| They didn't _actually say_ "period" or even "dot", but I bet
| you'd type 10.70.122.5 .
| jareklupinski wrote:
| yes, but to confirm I'd repeat it back to them as "was that
| ten dot seventy dot one-twenty-two dot five?"
|
| having a clear seperator helps me say the numbers faster
| djbusby wrote:
| Unicode call it a lowline. PostScript calls it underscore and
| HTML says UnderBar.
| floating-io wrote:
| I feel like "slab" would work.
| v-yadli wrote:
| nono, was it slab or slash [over a 8k bandwidth phone
| call]?
| ubitaco wrote:
| I would back "blank" as the most likely to be understood by
| the other person.
| dheera wrote:
| Or at LEAST make the dashes evenly spaced.
|
| 0000-0000-0000-0000-0000-0000-0000-0000
| Terr_ wrote:
| I don't think we're talking about the same problem here.
|
| Regardless of how many dashes you have or how (ir)regularly
| they are spaced, to select the whole ID you must carefully
| click-drag-release around its boundaries, you can't just
| double-click anywhere in it to select.
| silvestrov wrote:
| Problem with using base58 is that it uses 24 letters (excl 'I')
| so you can end up with 4 letter words that the marketing/PR
| departments does not like.
|
| Hexadecimal is safe.
| earthboundkid wrote:
| I like Crockford 32. It has more letters than hex, but is
| resistant to swear words.
|
| https://www.crockford.com/base32.html
| throwaway35777 wrote:
| > resistant to swear words
|
| No it's not.
|
| Edit: downvoters, a tame example is 0x72b5473d5a567200.
| copper-float wrote:
| I have no idea what that is supposed to say.
| vesinisa wrote:
| Resistant might be a strong word. I can see it only has E, A
| and Y as vowels which maybe helps a little for English as
| long as you're not the SATAN himself.
| throwaway35777 wrote:
| It's also trivially easy to reroll ids until they don't
| contain a swear.
| vesinisa wrote:
| Collecting the dictionary of all swear words for all
| languages and their dialects might be less trivial.
| Keeping it up to date would probably take an institute
| worth of researchers.
| throwaway35777 wrote:
| And there's no "forward secrecy" - if a normal word
| _becomes_ a swear, then it 's often hard to go through
| and change all uuids.
|
| Which is why the standard has been base16 (or base10) for
| so long.
| zeven7 wrote:
| But what if deadbeef becomes a swear?
|
| /s... but only halfway
| hinkley wrote:
| They did naz1 that coming.
| jszymborski wrote:
| What's more, unlike b58, it's case insensitive.
|
| I usually favour b32 for IDs. There's also word encodings,
| but frankly those have more lewd combinations than they don't
| to a mind such as mine.
| Izkata wrote:
| Well, mostly. Still have to be careful of l33tsp34k, where you
| can end up with things like b00b.
| logifail wrote:
| > where you can end up with things like b00b
|
| Honestly, if seeing the character string "b00b" is a problem,
| you have bigger problems.
| __MatrixMan__ wrote:
| Maybe you have users which will spam one of your services
| until they get something that has b00b in it.
| sedatk wrote:
| More importantly, Base58 is orders of magnitude slower than
| Base64/Base32/Base16 due to O(N^2) algorithms required to
| encode/decode it. Blockchain software is already trying to get
| rid of it. Adopting Base58 now would be shortsighted.
| bityard wrote:
| > Hexadecimal is safe.
|
| Oh yeah?
|
| ABADBABE B16B00B5 0B00B135 BEEFBABE CAFEBABE DEADBEEF
|
| And a few others that I'm probably forgetting...
| throwaway35777 wrote:
| base58 is case sensitive which hinders readability. When devs
| work with uuids they typically remember the first few letters
| ("this is guid abc", "that one is guid 1ac"). Hard to do that in
| base58.
|
| The coarsest encoding to have this property is Base32 where it
| remains easy to memorize first few letters without needing to
| memorize case.
| tlrobinson wrote:
| A couple other potentially desirable properties you could
| incorporate:
|
| - K-sortable: ensures good locality when used as an id in a
| database (e.x. https://github.com/jetify-com/typeid
| https://github.com/segmentio/ksuid )
|
| - checksum: primarily useful when an id might be conveyed
| verbally (e.x. customer support) or transcribed (e.x. Bitcoin
| wallet backup, BIP-39)
| treyd wrote:
| The bech32 format is a favorite of mine because it uses an
| alphabet that's designed to be unambiguous and its checksum is
| designed specifically to guarantee catching few character
| mistakes and make it possible to suggest where the mistake
| likely is. It also has a builtin human-readable purpose prefix
| at the front. Since it's all lowercase it also fits into the QR
| alphanumeric mode, which doesn't support mixed case so QR codes
| of bech32 IDs are more efficient.
| TehShrike wrote:
| > One way to enhance the usability of unique identifiers is by
| making them easily copyable.
|
| No matter what your identifiers look like, if you want them to be
| easily copyable you should add `user-select: all` to the element
| containing them.
|
| If you do this, all of the text will be selected automatically
| when you click on the element.
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/user-select
| blue_pants wrote:
| That's true, but there are a lot of places where ids live, but
| where I can't add `user-select: all`. For example, in terminal
| (logs), Studio3t (db client) etc.
| cess11 wrote:
| I find double click to select word, triple to select line or
| buffer, in surprisingly many contexts. Does this work for
| you?
| saurik wrote:
| The whole point of this article is that double-click to
| select a word doesn't work with a UUID... though, I think
| this should just be fixed: I have XTerm set up where double
| clicking selects a word, triple clicking selects a filename
| (which can include a hyphen, but not a slash), quadruple
| clicking selects a URL or path, and quintuple clicking
| selects the rest of the line.
| iaaan wrote:
| The workaround I've landed on is double-click and hold,
| then drag in the correct direction. Precise enough to
| just grab the UUID, imprecise enough to be quick and not
| annoying
| mynameisvlad wrote:
| The example used is a URL. I don't believe there is an
| equivalent for the address bar. Plenty of other examples exist,
| but that one is pretty easily reachable by users.
| BeFlatXIII wrote:
| I support all extension makers who strip user-select: none from
| all stylesheets.
| christophilus wrote:
| Wow. TIL. I've been using JavaScript for that.
| pphysch wrote:
| Thanks, I was looking this up yesterday and only found a bunch
| of JS that didn't work.
| sgarland wrote:
| > In our MySQL database we use IDs mostly as primary key
|
| Clustered index with random data stored as chars as the PK, what
| a great time! You will surely not regret this decision later.
| esafak wrote:
| What do you recommend?
| sgarland wrote:
| If you can't model the table with a natural key (or it would
| be so large as to inhibit performance), then a simple, normal
| monotonic integer is best. MySQL even lets you use unsigned
| ints, so if you use a bigint, you can go all the way up to
| 2^64-1.
|
| For those who think this doesn't work in distributed systems,
| it absolutely does - PlanetScale uses them internally [0]. If
| what is likely the largest MySQL (under Vitess) cluster in
| the world can manage, yours can too.
|
| If this is still untenable, then anything k-sortable (like
| UUIDv7, as the sibling comment mentioned) is a vast
| improvement over randomness. Don't cause B+tree page splits,
| especially in an RDBMS with a clustering index like MySQL.
|
| [0]:
| https://github.com/planetscale/discussion/discussions/366
| __float wrote:
| This is why UUID v7 is better to start with.
|
| The author also compares to Stripe tokens, which is a strange
| comparison as you can see they also have a time component
| towards the beginning.
| logifail wrote:
| Q: What's special about the format of UUIDs compared to, say, an
| equivalent entropy 128-bit number? For many use cases, the
| hyphens appear to be utterly irrelevant.
|
| https://softwareengineering.stackexchange.com/questions/3855...
| __MatrixMan__ wrote:
| An even better UUID UX would cycle through colors when you
| clicked one and then would overlay the assigned color when you
| see that same UUID elsewhere. Better to find a needle in a
| haystack if it's the only one with a pink background.
| coldtea wrote:
| With any of the entropies mentioned, it's not like you'll find
| 2 same ids in any pagefull of ids for this to ever matter...
|
| It's more like, you used id X in your db and 8 months later
| another X lands, after billions and billions of rows have been
| inserted...
| fireflash38 wrote:
| It's more for tx ids or user ids,which are likely to be used
| multiple times in logging.
| __MatrixMan__ wrote:
| We're not looking for duplicates because we're afraid that
| probability has failed us. We're looking for duplicates
| because we have a thing of interest, with a corresponding
| UUID, and we want to notice where else that thing is
| involved.
| nikeee wrote:
| I built cybertoken [1] for API keys and passwords, not (only)
| IDs. It is basically the format that GitHub uses for their api
| keys. Underscores, a prefix, so we can get a better debugging
| experience and automated secret scanning. It also has a CRC32, so
| you can check offline if the token candidate is a cybertoken
| while doing secret scanning.
|
| [1]: https://github.com/nikeee/cybertoken
| Daegalus wrote:
| As someone who maintains a UUID library, this is definitely
| something that has been thought about, especially in the
| UUIDv6-v8 updates. But it was moved to be considered later as an
| extension after v6-v8 get approved fully.
|
| But all these were talked about and considered before it was
| punted to a later time. https://github.com/uuid6/uuid6-ietf-
| draft/issues/27 https://github.com/uuid6/new-uuid-encoding-
| techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-
| techniques-ietf-d... https://github.com/uuid6/new-uuid-encoding-
| techniques-ietf-d...
|
| But there is always TypeID in the meantime which uses UUIDv7
| under the hood: https://github.com/jetify-com/typeid
|
| Either way, I am in favor of prefixing and using alternative
| encodings, but it will need some time to figure out the best
| route. In the mean time, there are so many alternatives. TypeID,
| NanoID, ULID, etc. I even made my own quick one just for giggles:
| https://github.com/daegalus/snowflakes
| MrBuddyCasino wrote:
| If you expose UUIDs to the user, even if just as part of the URL,
| encode them as shortUUID:
| https://github.com/skorokithakis/shortuuid
| pimlottc wrote:
| > Try copying this UUID by double-clicking on it
|
| Nobody does this. Normal users don't even know this is a thing. I
| worked on an app that did something like this for placeholders in
| generated text, and in all our extensive testing and high-touch
| rollouts, we never saw anyone use it.
|
| It's nice that you took the time to think about it, but it's not
| that important.
| kamikaz1k wrote:
| I use it, but I'm just me.
|
| What was the thing your product did?
| simonw wrote:
| Related note: Amazon IAM credentials often look something like
| this (not real): aws_access_key_id =
| AKIA367COJQOEU3UOE aws_secret_access_key =
| a7Ed0F80a0AF6606/MQG3+4o/o
|
| It's frustrating that you can select the access key by double
| clicking it but not the secret access key because of those /
| characters.
___________________________________________________________________
(page generated 2024-04-11 23:00 UTC)