[mort96]

Well you're leaking user data. I'm sure you can imagine situations where "the defendant created an account on this site on this date" could come up. And the user could have created that account not knowing that the creation date is public, because it's not listed anywhere in the publicly viewable part of the profile other than the UUID in the URL.

[koakuma-chan]

Discord is doing fine.

[mort96]

Hacker news is also doing fine, even though I can just click your profile and see you joined in october 2024. It doesn't matter for every use case.

But there are cases where it matters. Using UUIDv7 for identifiers means you need to carefully consider the security and privacy implications every time you create a new table identified by a UUID, and you'll possibly end up with some tables where you use v4 and some where you use v7. Worst case, you'll end up with painful migrations from v7 to v4 as security review identifies timestamped identifiers as a security concern.

[nish__]

Pretty much every social media app has a "Member since X" visible on public profiles. I don't think it's an issue.

[mort96]

Who said I was talking about social media?

[nish__]

Well where else do users have public profiles?

[0x3f]

The whole point though is that the ID itself leaks info, even if the profile is not public. There are many cases where you reference an object as a foreign key, even if you can't see the entire record of that foreign key.

[nish__]

I can't think of any.

[strbean]

Sending a friend request is an obvious example.