3 ms·

I don't think this passes. Anonymized post IDs still are information about a person. You can piece together posts & likes and conclude with good accuracy that

by treis 5y ago

I don't think this passes. Anonymized post IDs still are information about a person. You can piece together posts & likes and conclude with good accuracy that a specific person is making the post. As an example, if me, My Mom, and my brother's girlfriend all like a post it's likely that my brother made it. That makes those anonymized IDs personal information based on the GPRD definition: “any information” “relating to” “an identified or identifiable” “natural person” https://gdpr.eu/eu-gdpr-personal-data/ https://gdpr.eu/eu-gdpr-personal-data/ Ultimately the problem is that the GDPR is written broadly enough to encompass basically everything.

paulmd 5y ago
> Anonymized post IDs still are information about a person. I don't disagree with your general thrust, but I think there's some imprecise terminology here. No, anonymized post IDs are not, themselves, personal identifiers. A simple list of all UUIDs of posts in your table, for example, is not personal data. It can't be used to determine who made a post, there's no time data encoded there. It's just a list of handles to go get data somewhere else. If you store a user identifier, then it's personal data. Even an anonymized user identifier could be used to perform network analysis if it is used more than once. Using it only once is fine, but at that point it's just a post UUID with extra steps. Where I will go farther than great-grandparent is that GP is right and you don't have to run a full-scan of everything every time. It would be legally permissible for Facebook to store, in the US, "if you can see post 227, you should lookup the following: comment 383, like 398, comment 442, like 721". As long as there's no association (even anonymized) back to users, knowing that an event happened is not, itself, personal data. Even knowing times is fine, as long as you don't know who did it. That of course has a much broader sense than just storing user ID, you can't store IP address or anonymized user IDs or anything else either, but a list of object UUIDs and relational data between them is not, itself, personal data. The implication of this is that it would be generally permissible to store what are essentially post-to-comment and post-to-like indexes in the US, meaning you don't have to full-scan everything every time. You can't attach user info to them, and you very obviously cannot just store everything in the US anymore, but storing relational data between non-identifiable objects is legal - of course "non-identifiable" is doing a lot of work in that sentence, but if I tell you "post 227 exists, and has comment 383 and like 398 in my database" that declaration does not, itself, mean that the EU is coming after me for GDPR violations. You don't have the content, and you don't have any metadata other than a completely unidentifiable object tag that cannot be correlated to any user by any means. It does mean that you'd probably want to partition your data according to some reasonable shape, like localizing comments/likes/etc to the same server, but you don't have to scan everything just to find out if there exists any match ever. It would also be permissible to store a place where you could go to look up that identifier, as long as it can't be correlated. So it would be fine to say "post 227 exists on shard A123X", as long as that can't be correlated back to something like geolocation. If you can backreference from shard A123X to that post being made by someone in Paris France, that's a problem. If your user-to-server mappings are randomized such that a French user's comments might end up in a server in Belgium, that's probably permissible to store the shard location even inside a US server. If you don't randomize like that, the lookup data would probably have to live in the EU as well. There is, unfortunately, a huge amount of "don't wanna!" around this issue in the programmer community and on HN in particular. The GDPR is perceived as onerous because it outlaws some data collection practices that generate a lot of revenue (directly or indirectly - such as providing insight to guide decisions), and programmers have decided that means it's impossible to comply. It's not, it's just impossible to comply while doing the things you were doing before, because they were socially harmful and were specifically outlawed by these regulations. It would be a lot better for industrial businesses if they could just dump their toxic waste in the river too. Their business model doesn't work if they can't do that! Having to comply with EPA regulations and dispose of the waste appropriately is complex and difficult and we can't afford that!
- treis 5y ago
  >No, anonymized post IDs are not, themselves, personal identifiers It's the set of users acting on a post that can be used to identify the poster.
  - deleted 5y ago
    [deleted]
  - paulmd 5y ago
    You can't tell the users that acted on a post from the mere UUID of the post itself. Knowing that this is HN thread 30427711 doesn't give you a set of users who acted on that. For example, a hyperlink to this thread, or posts within it, is not personal data. You'd have to go to the HN server and ask them for the data - which is personal data, but the post ID itself is not, it's just a handle. Assigning UUIDs randomly instead of sequentially strengthens this further because there is no way to pull out even a time component from the post ID.

by treis 5y ago

paulmd 5y ago

> Anonymized post IDs still are information about a person. I don't disagree with your general thrust, but I think there's some imprecise terminology here. No, anonymized post IDs are not, themselves, personal identifiers. A simple list of all UUIDs of posts in your table, for example, is not personal data. It can't be used to determine who made a post, there's no time data encoded there. It's just a list of handles to go get data somewhere else. If you store a user identifier, then it's personal data. Even an anonymized user identifier could be used to perform network analysis if it is used more than once. Using it only once is fine, but at that point it's just a post UUID with extra steps. Where I will go farther than great-grandparent is that GP is right and you don't have to run a full-scan of everything every time. It would be legally permissible for Facebook to store, in the US, "if you can see post 227, you should lookup the following: comment 383, like 398, comment 442, like 721". As long as there's no association (even anonymized) back to users, knowing that an event happened is not, itself, personal data. Even knowing times is fine, as long as you don't know who did it. That of course has a much broader sense than just storing user ID, you can't store IP address or anonymized user IDs or anything else either, but a list of object UUIDs and relational data between them is not, itself, personal data. The implication of this is that it would be generally permissible to store what are essentially post-to-comment and post-to-like indexes in the US, meaning you don't have to full-scan everything every time. You can't attach user info to them, and you very obviously cannot just store everything in the US anymore, but storing relational data between non-identifiable objects is legal - of course "non-identifiable" is doing a lot of work in that sentence, but if I tell you "post 227 exists, and has comment 383 and like 398 in my database" that declaration does not, itself, mean that the EU is coming after me for GDPR violations. You don't have the content, and you don't have any metadata other than a completely unidentifiable object tag that cannot be correlated to any user by any means. It does mean that you'd probably want to partition your data according to some reasonable shape, like localizing comments/likes/etc to the same server, but you don't have to scan everything just to find out if there exists any match ever. It would also be permissible to store a place where you could go to look up that identifier, as long as it can't be correlated. So it would be fine to say "post 227 exists on shard A123X", as long as that can't be correlated back to something like geolocation. If you can backreference from shard A123X to that post being made by someone in Paris France, that's a problem. If your user-to-server mappings are randomized such that a French user's comments might end up in a server in Belgium, that's probably permissible to store the shard location even inside a US server. If you don't randomize like that, the lookup data would probably have to live in the EU as well. There is, unfortunately, a huge amount of "don't wanna!" around this issue in the programmer community and on HN in particular. The GDPR is perceived as onerous because it outlaws some data collection practices that generate a lot of revenue (directly or indirectly - such as providing insight to guide decisions), and programmers have decided that means it's impossible to comply. It's not, it's just impossible to comply while doing the things you were doing before, because they were socially harmful and were specifically outlawed by these regulations. It would be a lot better for industrial businesses if they could just dump their toxic waste in the river too. Their business model doesn't work if they can't do that! Having to comply with EPA regulations and dispose of the waste appropriately is complex and difficult and we can't afford that!

treis 5y ago
>No, anonymized post IDs are not, themselves, personal identifiers It's the set of users acting on a post that can be used to identify the poster.
- deleted 5y ago
  [deleted]
- paulmd 5y ago
  You can't tell the users that acted on a post from the mere UUID of the post itself. Knowing that this is HN thread 30427711 doesn't give you a set of users who acted on that. For example, a hyperlink to this thread, or posts within it, is not personal data. You'd have to go to the HN server and ask them for the data - which is personal data, but the post ID itself is not, it's just a handle. Assigning UUIDs randomly instead of sequentially strengthens this further because there is no way to pull out even a time component from the post ID.