5 ms·

In the case of a thick client app: > if user A living in France makes a post The post data would be stored on a server in France. > a user B living in Americ

In the case of a thick client app: > if user A living in France makes a post The post data would be stored on a server in France. > a user B living in America comments on it The user B's thick client app would have to query all servers all over the world that might hold data they're allowed to see, and then render it. It's up to the servers in each country to decide whether the post should be sent to the viewer in question. When User B comments, their comment would be stored on a server in the US. For User A to see the comment, like User B, they would need to connect to all servers in all countries to fetch what data they're allowed to see. Is this cheap and practical? Of course not. But it's possible, just not in the sense we've come to know social media apps.

TekMol 5y ago
When User B comments, their comment would be stored on a server in the US. For User A to see the comment, like User B, they would need to connect to all servers in all countries to fetch what data they're allowed to see. Since A is in France, how would the server of User B - who is in the USA - know what A is allowed to see? If no data about user A is allowed to be stored in the USA, the server in the USA can not know who A is and what they are allowed to see.
- egeozcan 5y ago
  > If no data about user A is allowed to be stored in the USA, the server in the USA can not know who A is IANAL, but to my best knowledge, holding one-off data in memory is repeatedly defended in European courts as not storing data. This is from the top of my head, so treat it as "probably wrong". All in all, the whole thing is a bit of a circus, really.
  - TekMol 5y ago
    How does "one-off data in memory" come into play here?
sandworm101 5y ago
It doesn't need to be nearly that complicated. You never need to query every server. The post stays on the server for the poster's country. Every comment attached to that post gets an anonymous number/tag (this already exists). So each post is stored as a post and an associated list of numbers/tags for comments. When rendering, the user's system fetches the post, gets the list of comment numbers, and pulls the comments from the various country-specific servers. The servers in each country take the incoming request and decide whether the data can be sent to the requesting country according to their own local rules/laws. This need not be complicated. It can all be handled as basic HTML stuff.
- 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!

TekMol 5y ago

When User B comments, their comment would be stored on a server in the US. For User A to see the comment, like User B, they would need to connect to all servers in all countries to fetch what data they're allowed to see. Since A is in France, how would the server of User B - who is in the USA - know what A is allowed to see? If no data about user A is allowed to be stored in the USA, the server in the USA can not know who A is and what they are allowed to see.

egeozcan 5y ago
> If no data about user A is allowed to be stored in the USA, the server in the USA can not know who A is IANAL, but to my best knowledge, holding one-off data in memory is repeatedly defended in European courts as not storing data. This is from the top of my head, so treat it as "probably wrong". All in all, the whole thing is a bit of a circus, really.
- TekMol 5y ago
  How does "one-off data in memory" come into play here?

sandworm101 5y ago

It doesn't need to be nearly that complicated. You never need to query every server. The post stays on the server for the poster's country. Every comment attached to that post gets an anonymous number/tag (this already exists). So each post is stored as a post and an associated list of numbers/tags for comments. When rendering, the user's system fetches the post, gets the list of comment numbers, and pulls the comments from the various country-specific servers. The servers in each country take the incoming request and decide whether the data can be sent to the requesting country according to their own local rules/laws. This need not be complicated. It can all be handled as basic HTML stuff.

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!