4 ms·

It looks like you're explaining this well, but I still don't understand what you're saying.

nomercy400 3y ago
Don't use UUIDv7 if you want to keep the creation time of the event/id/entry private.
sgarland 3y ago
They're saying that in certain circumstances, if your API exposes the PK publicly, it may leak information you don't want leaked (the precise datetime something occurred, in the case of UUIDv7). If that's an issue for you, you can get around this in a variety of ways, as they mention: you could use an associative table that maps the externally-exposed random ID to an internal-only ID.
remus 3y ago
Be careful about combining 2 pieces of information in to 1 column. From the above examples, you may want something to uniquely identify a record in your db and you may want something that tells you when the record was created. If you combine these two things, you then have a problem if you want to give an untrusted party that unique reference without telling them when it was created.
jandrewrogers 3y ago
The event timestamps embedded in the UUID can be correlated with external event streams, or even with other events within the same dataset, to de-anonymize the context of the event associated with the UUID. This is a common class of de-anonymization attack. Anything that allows temporal correlations to be inferred potentially leaks quite a lot of info about the data underlying the unique ids.
spamizbad 3y ago
At my company we had a competitor scrape our API for various businesses. One of the fields was an bson ObjectId that represented when the customer entered our system. This unique identifier encodes a timestamp of its creation. Our competitor was able to ascertain, based on that timestamp, when our customers contract was up and was (briefly) able to poach some customers by underbidding us until we corrected this.
- taftster 3y ago
  Wow. I'm amazed by stories like. I'm so naively the "take the high road" kind of guy, that I just assume everyone (or every company) should just do the right thing. Stealing customers in this way from a competitor, I have no ability to rationalize such an action. And this kind of makes me scared, like if I were to ever own a business, I just know I'm swimming with sharks with no ability to defend. I believe your story, but it's just crazy to me. Go earn a customer's business in a legit way, not be stealing data from a competitor.
  - oluwie 3y ago
    Uhh ... that's entirely what business is about. Some shady methods maybe, but also some pretty good customer acquisition methods
    - gorjusborg 3y ago
      Businesses do not have to act unethically. Doing so limits who you can hire and collaborate with.
  - spamizbad 3y ago
    Honestly I didn't even think of it when I first wrote the endpoint. Our founder asked me "Is there anything we're sending over the API that might clue someone in when someone signs up? Are we sending a createdAt field or something?" and I said "No, but we do have a timestamp in one of the IDs..." -- well, we removed the field and this behavior stopped soon after. Anyway, the arc of the universe bends toward justice: this (former) competitor got sold for parts a few years later.
  - Dylan16807 3y ago
    Giving someone an offer when their existing contract is running out isn't that shady. Lots of companies ask for that. It shouldn't be hard to rationalize!
- 698969 3y ago
  Isn't the real issue here that your competitors had the authorization to see the contracts you had with other customers?

Don't use UUIDv7 if you want to keep the creation time of the event/id/entry private.

They're saying that in certain circumstances, if your API exposes the PK publicly, it may leak information you don't want leaked (the precise datetime something occurred, in the case of UUIDv7). If that's an issue for you, you can get around this in a variety of ways, as they mention: you could use an associative table that maps the externally-exposed random ID to an internal-only ID.

remus 3y ago

Be careful about combining 2 pieces of information in to 1 column. From the above examples, you may want something to uniquely identify a record in your db and you may want something that tells you when the record was created. If you combine these two things, you then have a problem if you want to give an untrusted party that unique reference without telling them when it was created.

jandrewrogers 3y ago

The event timestamps embedded in the UUID can be correlated with external event streams, or even with other events within the same dataset, to de-anonymize the context of the event associated with the UUID. This is a common class of de-anonymization attack. Anything that allows temporal correlations to be inferred potentially leaks quite a lot of info about the data underlying the unique ids.

spamizbad 3y ago

At my company we had a competitor scrape our API for various businesses. One of the fields was an bson ObjectId that represented when the customer entered our system. This unique identifier encodes a timestamp of its creation. Our competitor was able to ascertain, based on that timestamp, when our customers contract was up and was (briefly) able to poach some customers by underbidding us until we corrected this.

taftster 3y ago
Wow. I'm amazed by stories like. I'm so naively the "take the high road" kind of guy, that I just assume everyone (or every company) should just do the right thing. Stealing customers in this way from a competitor, I have no ability to rationalize such an action. And this kind of makes me scared, like if I were to ever own a business, I just know I'm swimming with sharks with no ability to defend. I believe your story, but it's just crazy to me. Go earn a customer's business in a legit way, not be stealing data from a competitor.
- oluwie 3y ago
  Uhh ... that's entirely what business is about. Some shady methods maybe, but also some pretty good customer acquisition methods
  - gorjusborg 3y ago
    Businesses do not have to act unethically. Doing so limits who you can hire and collaborate with.
- spamizbad 3y ago
  Honestly I didn't even think of it when I first wrote the endpoint. Our founder asked me "Is there anything we're sending over the API that might clue someone in when someone signs up? Are we sending a createdAt field or something?" and I said "No, but we do have a timestamp in one of the IDs..." -- well, we removed the field and this behavior stopped soon after. Anyway, the arc of the universe bends toward justice: this (former) competitor got sold for parts a few years later.
- Dylan16807 3y ago
  Giving someone an offer when their existing contract is running out isn't that shady. Lots of companies ask for that. It shouldn't be hard to rationalize!
698969 3y ago
Isn't the real issue here that your competitors had the authorization to see the contracts you had with other customers?