6 ms·

I can't get away from storing PII for signed in users. For non-signed-in users, I think it would be useful to avoid all PII.

Msurrow 4y ago
Fair enough. Just wanted to make sure the take away wasnt that US companies cannot deliver services _at all_ to EU. Just curious whats your product/service? And how is PII used (high level)? As a dev and sw architect, and strong supporter of GDPR, I think its interesting to (attempt to) find engineering solutions for the challenges posed by GDPR (and Schrems)
- gavinhoward 4y ago
  > Fair enough. Just wanted to make sure the take away wasnt that US companies cannot deliver services _at all_ to EU. With the CLOUD Act, I'm wondering if it is illegal. > Just curious whats your product/service? And how is PII used (high level)? As a dev and sw architect, and strong supporter of GDPR, I think its interesting to (attempt to) find engineering solutions for the challenges posed by GDPR (and Schrems) It's a code forge. For users with accounts, I have to store at least email addresses, which I believe are PII. I also need to store public keys (for commit signing), which could be considered "identification numbers" covered by the GDPR. Even if I got away with not using email addresses, I can't get away with not storing public keys, unfortunately. I believe that once I store any PII, it's game over, right? By the way, I'm all for strong consumer privacy protection too. I would want the US to implement something like the GDPR as well. So I'm a supporter on some level. I'm just mad at the US government for the CLOUD Act.
  - Msurrow 4y ago
    Sorry about response time here, familiy stuff happened. Yes emails are PII. In general anything that can identify a person. Its a broad interpretation of "identify a person", and actually hasn't got anything to do with the sensitivity of the information. There are classes of PII for sensitive data, and extra rules for processing that, but when figuring out _if_ data is PII, sensitivity doesn't really come into it. And you are correct, _any_ PII is "game over" in this case. But this case (US <-> EU) is also a bit of an edge case to GDPR I think. I mean most of GDPR is concerned with how a company should handle PII. Then there are some rules about transferring data to "unsafe" countries. Unsafe in this case means countries where there is high risk that the company is not handling PII correctly and/or nothing the EU (citizen) can do about it. And this is where your CLOUD Act + Schrems II comes in. It makes US an "unsafe" country to transfer data to because it brings a high risk for the EU citizen that their GDPR rights cannot/will not be enforced (and the Privacy Shield agreenment that used to make it okay away is no longer valid). Its unfortunate, I think, because it puts GDPR in a special negative light for US engineers, and that takes away from the many good things in GDPR. I actually think most of the stuff in there is pretty good. And just for reference - I run my own company, so I'm "enjoying" GDPR compliance fully, and sure, its more work, but I haven't yet encountered a part of GDPR where I havn't though "isn't this actually how I wanted my data to be handled by other companies?" Okay, now for the fun part - thinking up designs/architectures where your product would be GDPR compliant. Im just doing this for my own fun btw, and perhaps a nice discussion. Not trying to tell you what to do :) Since we have the hole "unsafe" third country situation, no transfer of PII is okay. This is a bit more restricted that what we would normally deal with under GDPR. The basic tenants for being compliant here is two things: 1) If you/your employees hasn't got access to the data, e.g. because you don't have it, you are not handling PII. 2) If data is not being sent from the client (located in EU) to your US servers, you don't have the "unsafe" country data transfer situation. And the your are compliant. Emails (and other data attributes, like username, name, CC details, shoe size etc). I think the way to go about this is thinking in terms of that you actually need server side to make core functionality work, and what could actually be kept client side and never sent to your servers. See, in this case the problem is transferring the PII to the US. If you can somehow have a "fat" application client side, like a SPA, could you avoid sending the email to the server? What you must have is a unique identifier for users, sure, and email is normally that. But you could hash the email addr and use that as a unique key for the user. You just need it to be guaranteed unique, and dont care (most likely) what the actual mail address is. Note: Stil have to be careful with the hashed email as unique key because that could still identify a user, since its unique, and therefore PII. However if you hash client side and only send the hash, you will only have the hash server side. And if the only datapoint you have is a hash then it cannot identify a person on its own (given the properties of a one-way hash function). You'd need to put that hash in context with other info to be able to identify a person from it. And then its not PII, and you can send it to your server no problem. The same concept should be usable for most basic data attributes, i.e. shift everything PII to the client, and if data needs to be sent then do you actually the actual value of the data or do you just need the data to have a certain property, e.g. be unique or be not-null or whatever. Then there is the matter of storing all this data we've now shifted to the client. This is were the textbook would say "left as exercise for the reader" LOL. Storage for web apps especially is gonna be annoying to deal with. If you have an actual (not web app) client, its much easier. If your users are developers, you can get away with less user-friendly ways of managing that data client side in a web app. It seems solvable without too much fuss, with some form of local storage. Public keys. This one is though. A public key is PII. You need the public key server side because (I'm guessing) when a user submits code (s)he attaches a signature, that you need to verify. You having that public key is part of the hole PKI idea. The first idea that comes to mind is based on the same "do you need the value of the data or do you need to know a property about the data"-thinking. You need to know the signature is valid for the submitted code. If you had a magic black box that could give you a yes/no (that you could trust) on that, you wouldn't actually need the public key, you could just give the code and the signature to your black box and it would say yay or nay. If there was a service (i.e. API) on a server in europe that played the part of the black box, and you trusted it, you could "just" call the service with the signature (again hashed/encrypted and if you don't have the key, you can't relate the signature to a person, so its not PII) and code as input, and the service would return true/false, when you would have what you need. And no PII i.e. the public key would need to be transferred to your server / you wound't need to handle (store) it. Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup? I feel like there must be more solutions to the public key one, but they don't come to mind right now. Was a fun exercise anyway :) I'm sure I've made so many assumptions about how your product works, that the above suggestions would never work in practise, but my point was more to illustrate that GDPR compliance can be dealt with by rethinking many of our go-to design patterns (i.e. have a central database with user info). Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced.
    - gavinhoward 4y ago
      First off, do you have a blog? This information would be great as a blog post! I think your ideas are wonderful, and I might try to implement as many of them as possible, just for privacy reasons, even if it is impossible for me to target the EU market. In fact, because it's a code forge, there will be a client, just like Git is a "client" for GitHub. (It will be a self-contained VCS like Fossil.) So most of what you said will work. In fact, you are exactly correct that I need the public key for signatures on code. But there is one hang-up. While I could let the client handle checking for code signing, I still need to store the public key. The reason for this is because the public key will also be for account recovery. Recovery via email will also be possible, unless I can't store the email address at all. But either email or public key will be required to recover accounts. So unless I could make it so random clients could recover accounts for other users, I need to store the public key. If you have ideas about how to get around that, please contact me. [1] Even if not, I would love to continue talking with you about this; I want to set the standard for protecting user privacy with my code forge. > Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup? Yeah, I thought so. The biggest problem with that is that I have absolutely NO contacts in Europe that I can use. I may not even be able to travel to Europe to set something like that up. So because I only care about money enough to make what I need to in order to support my wife and me, offering my product to the EU is not worth it for the hassle and cost. > Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced. This is encouraging, though sad since I won't be able to make it work. To be honest, I was hoping I could make an end-to-end encrypted code forge, but I also want to support FOSS projects, which have to do their stuff in public. End-to-end encryption would only work in that case if everyone had the client on their machine, which would not be likely for a VCS; there will be people that just want to download the code from the browser without needing an extra program to do so. Again, I'd love to chat even more. Please contact me if you feel like doing so. [1]: https://gavinhoward.com/contact/ https://gavinhoward.com/contact/

Msurrow 4y ago

Fair enough. Just wanted to make sure the take away wasnt that US companies cannot deliver services _at all_ to EU. Just curious whats your product/service? And how is PII used (high level)? As a dev and sw architect, and strong supporter of GDPR, I think its interesting to (attempt to) find engineering solutions for the challenges posed by GDPR (and Schrems)

gavinhoward 4y ago
> Fair enough. Just wanted to make sure the take away wasnt that US companies cannot deliver services _at all_ to EU. With the CLOUD Act, I'm wondering if it is illegal. > Just curious whats your product/service? And how is PII used (high level)? As a dev and sw architect, and strong supporter of GDPR, I think its interesting to (attempt to) find engineering solutions for the challenges posed by GDPR (and Schrems) It's a code forge. For users with accounts, I have to store at least email addresses, which I believe are PII. I also need to store public keys (for commit signing), which could be considered "identification numbers" covered by the GDPR. Even if I got away with not using email addresses, I can't get away with not storing public keys, unfortunately. I believe that once I store any PII, it's game over, right? By the way, I'm all for strong consumer privacy protection too. I would want the US to implement something like the GDPR as well. So I'm a supporter on some level. I'm just mad at the US government for the CLOUD Act.
- Msurrow 4y ago
  Sorry about response time here, familiy stuff happened. Yes emails are PII. In general anything that can identify a person. Its a broad interpretation of "identify a person", and actually hasn't got anything to do with the sensitivity of the information. There are classes of PII for sensitive data, and extra rules for processing that, but when figuring out _if_ data is PII, sensitivity doesn't really come into it. And you are correct, _any_ PII is "game over" in this case. But this case (US <-> EU) is also a bit of an edge case to GDPR I think. I mean most of GDPR is concerned with how a company should handle PII. Then there are some rules about transferring data to "unsafe" countries. Unsafe in this case means countries where there is high risk that the company is not handling PII correctly and/or nothing the EU (citizen) can do about it. And this is where your CLOUD Act + Schrems II comes in. It makes US an "unsafe" country to transfer data to because it brings a high risk for the EU citizen that their GDPR rights cannot/will not be enforced (and the Privacy Shield agreenment that used to make it okay away is no longer valid). Its unfortunate, I think, because it puts GDPR in a special negative light for US engineers, and that takes away from the many good things in GDPR. I actually think most of the stuff in there is pretty good. And just for reference - I run my own company, so I'm "enjoying" GDPR compliance fully, and sure, its more work, but I haven't yet encountered a part of GDPR where I havn't though "isn't this actually how I wanted my data to be handled by other companies?" Okay, now for the fun part - thinking up designs/architectures where your product would be GDPR compliant. Im just doing this for my own fun btw, and perhaps a nice discussion. Not trying to tell you what to do :) Since we have the hole "unsafe" third country situation, no transfer of PII is okay. This is a bit more restricted that what we would normally deal with under GDPR. The basic tenants for being compliant here is two things: 1) If you/your employees hasn't got access to the data, e.g. because you don't have it, you are not handling PII. 2) If data is not being sent from the client (located in EU) to your US servers, you don't have the "unsafe" country data transfer situation. And the your are compliant. Emails (and other data attributes, like username, name, CC details, shoe size etc). I think the way to go about this is thinking in terms of that you actually need server side to make core functionality work, and what could actually be kept client side and never sent to your servers. See, in this case the problem is transferring the PII to the US. If you can somehow have a "fat" application client side, like a SPA, could you avoid sending the email to the server? What you must have is a unique identifier for users, sure, and email is normally that. But you could hash the email addr and use that as a unique key for the user. You just need it to be guaranteed unique, and dont care (most likely) what the actual mail address is. Note: Stil have to be careful with the hashed email as unique key because that could still identify a user, since its unique, and therefore PII. However if you hash client side and only send the hash, you will only have the hash server side. And if the only datapoint you have is a hash then it cannot identify a person on its own (given the properties of a one-way hash function). You'd need to put that hash in context with other info to be able to identify a person from it. And then its not PII, and you can send it to your server no problem. The same concept should be usable for most basic data attributes, i.e. shift everything PII to the client, and if data needs to be sent then do you actually the actual value of the data or do you just need the data to have a certain property, e.g. be unique or be not-null or whatever. Then there is the matter of storing all this data we've now shifted to the client. This is were the textbook would say "left as exercise for the reader" LOL. Storage for web apps especially is gonna be annoying to deal with. If you have an actual (not web app) client, its much easier. If your users are developers, you can get away with less user-friendly ways of managing that data client side in a web app. It seems solvable without too much fuss, with some form of local storage. Public keys. This one is though. A public key is PII. You need the public key server side because (I'm guessing) when a user submits code (s)he attaches a signature, that you need to verify. You having that public key is part of the hole PKI idea. The first idea that comes to mind is based on the same "do you need the value of the data or do you need to know a property about the data"-thinking. You need to know the signature is valid for the submitted code. If you had a magic black box that could give you a yes/no (that you could trust) on that, you wouldn't actually need the public key, you could just give the code and the signature to your black box and it would say yay or nay. If there was a service (i.e. API) on a server in europe that played the part of the black box, and you trusted it, you could "just" call the service with the signature (again hashed/encrypted and if you don't have the key, you can't relate the signature to a person, so its not PII) and code as input, and the service would return true/false, when you would have what you need. And no PII i.e. the public key would need to be transferred to your server / you wound't need to handle (store) it. Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup? I feel like there must be more solutions to the public key one, but they don't come to mind right now. Was a fun exercise anyway :) I'm sure I've made so many assumptions about how your product works, that the above suggestions would never work in practise, but my point was more to illustrate that GDPR compliance can be dealt with by rethinking many of our go-to design patterns (i.e. have a central database with user info). Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced.
  - gavinhoward 4y ago
    First off, do you have a blog? This information would be great as a blog post! I think your ideas are wonderful, and I might try to implement as many of them as possible, just for privacy reasons, even if it is impossible for me to target the EU market. In fact, because it's a code forge, there will be a client, just like Git is a "client" for GitHub. (It will be a self-contained VCS like Fossil.) So most of what you said will work. In fact, you are exactly correct that I need the public key for signatures on code. But there is one hang-up. While I could let the client handle checking for code signing, I still need to store the public key. The reason for this is because the public key will also be for account recovery. Recovery via email will also be possible, unless I can't store the email address at all. But either email or public key will be required to recover accounts. So unless I could make it so random clients could recover accounts for other users, I need to store the public key. If you have ideas about how to get around that, please contact me. [1] Even if not, I would love to continue talking with you about this; I want to set the standard for protecting user privacy with my code forge. > Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup? Yeah, I thought so. The biggest problem with that is that I have absolutely NO contacts in Europe that I can use. I may not even be able to travel to Europe to set something like that up. So because I only care about money enough to make what I need to in order to support my wife and me, offering my product to the EU is not worth it for the hassle and cost. > Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced. This is encouraging, though sad since I won't be able to make it work. To be honest, I was hoping I could make an end-to-end encrypted code forge, but I also want to support FOSS projects, which have to do their stuff in public. End-to-end encryption would only work in that case if everyone had the client on their machine, which would not be likely for a VCS; there will be people that just want to download the code from the browser without needing an extra program to do so. Again, I'd love to chat even more. Please contact me if you feel like doing so. [1]: https://gavinhoward.com/contact/ https://gavinhoward.com/contact/