3 ms·

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 use

by mort96 11mo ago

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.

nish__ 11mo ago
Pretty much every social media app has a "Member since X" visible on public profiles. I don't think it's an issue.
- mort96 11mo ago
  Who said I was talking about social media?
  - nish__ 11mo ago
    Well where else do users have public profiles?
    - 0x3f 11mo ago
      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__ 11mo ago
        I can't think of any.
        strbean 11mo ago
        Sending a friend request is an obvious example.
        nish__ 11mo ago
        Ok but in that case, why not use the user ID as the primary key?
koakuma-chan 11mo ago
Discord is doing fine.
- mort96 11mo ago
  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.