Problem

We track failed attempts in audit logs and logs, and to generate diffs we are using random uuids's for anonymous users (see #5925).

The issue for this is that the uuids are not obviously anonymous at first glance, and might cause some misunderstandings if logs are consumed programatically. It would be hard to tell if a uuid was random, or maybe some user that was deleted (hard delete).

Tracking the same anonymous user

The other issue with this is that it does not track the same anonymous user. IP address in logs does do this to an extent, and might be sufficient. We could set a cookie on the user's browser some identifying token that does not expire so all unauthenticated requests have the same tracking ID. That way in the audit logs, it is clear the same browser is making many failed requests. Especially useful if there is a group of users behind a NAT since the IP tracking would not distinguish individual users.

Idea

One idea to ensure that it is clear which UUIDs track anonymous users and have no relations to any data in the database, we could:

Static UUID

We could use a static id (eg 11111111-1111-1111-1111-111111111111). This is obvious it is not a real UUID.

The downside is all anonymous users are the same.

Not completely random uuid

We could manipulate a random UUID. UUID's have various parts to them. The RFC states:

https://www.rfc-editor.org/rfc/rfc4122#section-4.4

[4.4](https://www.rfc-editor.org/rfc/rfc4122#section-4.4).  Algorithms for Creating a UUID from Truly Random or
      Pseudo-Random Numbers

   The version 4 UUID is meant for generating UUIDs from truly-random or
   pseudo-random numbers.

   The algorithm is as follows:

   o  Set the two most significant bits (bits 6 and 7) of the
      clock_seq_hi_and_reserved to zero and one, respectively.

   o  Set the four most significant bits (bits 12 through 15) of the
      time_hi_and_version field to the 4-bit version number from
      [Section 4.1.3](https://www.rfc-editor.org/rfc/rfc4122#section-4.1.3).

   o  Set all the other bits to randomly (or pseudo-randomly) chosen
      values.

Standard parts of a uuid (remember that v4 is the one we use and most of this is completely random)

We could use a different version uuid, as it has the same format. I don't know what version exactly, but we could use a version (like v1) that uses time for many of the bits, and something static for the Node part. Meaning any "anonymous user" is essentially tracked to the time they were identified as an anonymous user.

Example:
(decode the uuid here to see the time: https://www.uuidtools.com/decode)

3cb47c7a-a637-11ed-afa1-aa0000000000

Some combination of static and random

Same as above, but more random parts instead of using time.