6 ms·

I have a tiny project in closed beta right now I've been working on in my spare time for 7 years I'm considering closing to the EU. The idea is even entirely pr

by donatj 8y ago

I have a tiny project in closed beta right now I've been working on in my spare time for 7 years I'm considering closing to the EU. The idea is even entirely privacy minded with all data save email address being client side encrypted so we never see it unencrypted. I never intended to make real money off it except maybe covering server costs if I'm lucky, but the time it would take dealing with requests like this it enough to scare anyone off.

ColinWright 8y ago
Broadly speaking, and noting that IANAL, etc, etc, ... I'm not sure what the problem is. Your obligation is to keep the data secure, and only keep data that you need. Then you need to respond to requests to (a) tell a person what data you hold on them, (b) tell them what you do with the data, and (c) delete it if asked, unless you have a legitimate reason to keep it. So if someone has given you data for the purpose of you providing a service then all you need to do is treat that data with care, don't do anything your customer doesn't expect you to do, and be able to provide and/or delete it. Fair do, someone disagrees and has down-voted me. Please, having read the actual regulations[0] several times, including the recitals[1], I'd be pleased to see what's missing from that outline, so I can improve my understanding. [0] https://gdpr-info.eu/ https://gdpr-info.eu/ [1] https://gdpr-info.eu/recitals/ https://gdpr-info.eu/recitals/
- testvox 8y ago
  The problem is you have to do all that or face fines and lawsuits which is outside the risk envelope of most people's side projects.
  - Radle 8y ago
    Try to build a treehouse without following legal guidelines and see what happens to your side project. I frankyl don't understand why web site owners are entitled to a wild west, now-law zone?
    - donatj 8y ago
      Treehouse is an odd yet apt choice as the laws vary highly by municipality. None of the treehouses I played in as a child were inspected or up to code. I think the argument to be made here anyway is the level of danger. You could die falling out of a treehouse, whereas the actual damages from mishandling a single users data is several magnitudes less.
      - freeflight 8y ago
        > You could die falling out of a treehouse, whereas the actual damages from mishandling a single users data is several magnitudes less. That's a very dangerous sentiment to have. Identity theft is a very real thing. You can do pretty horrible things impersonating other people, things that will lead to people ending up in jail, things that can ruin whole families and drive people into poverty, desperation, and suicide. It opens people up to blackmail, manipulation and a whole list of other, rather nasty, tactics. On the extreme end, there's also the fact that not everybody lives in a "free country". In many places saying the wrong things, even online, can have very final consequences. In such cases, you not taking proper care of your user's data, sharing or leaking it all over the place, can result in people vanishing in some torture dungeon never to be seen again.
        tetromino_ 8y ago
        My entire, multi-year record of personal and financial information has been leaked and stolen at least 3 times, most recently from Equifax. In addition, certain of my passwords and financial and personal details were leaked at least a dozen times that I know about by various stores, restaurants, apps, and online forums. The consequences to me, personally? Not much. I haven't been blackmailed, I haven't been impersonated, jailed, or driven to suicide. And in this, I am not unique, not unusual. Probably at least half of the adult US population has had all their information leaked just like mine was. The overwhelming majority of them suffered few to no consequences.
        aleksei 8y ago
  - ColinWright 8y ago
    Even if you're running a small side-project, you really should (a) not do things people don't expect, (b) be able to provide people with a copy of their data that you hold, and (c) delete their data if you're asked to (and you have no legitimate reason to keep it). That all seems completely reasonable to me. It's certainly reasonable that a new start-up or side-project should use these considerations as part of their design, and I should think that an existing start-up or side-project that does not comply should look hard at why not. If you think these demands are unreasonable, I'd genuinely be interested in knowing which, and why.
    - Mirioron 8y ago
      Does it seem reasonable to you? Let me propose a scenario to you. Let's suppose that you commenting on Hacker News would mean that you must adequately respond to certain messages sent to you. If you don't do that then you can be fined. Does this sound like an environment that would encourage you to share your thoughts on Hacker News? Or does it sound more like an environment, where you would just not say anything and perhaps go elsewhere? It's unreasonable, because it imposes an administrative cost on anyone that tries to do things on the side regardless whether they have good data handling practices or whether they have any intention of abusing the data. I would bet money on the fact, that JUST the fact that they must respond to a letter is enough to make some people go do something else. And who knows, maybe the side project could've been the next google.
      - wooter 8y ago
        not to mention that, historically and intrinsically, visiting a site or using someones application is a voluntary activity. no one is forcing the user to do anything and the user shouldn't be able to force the developers to do anything.
      - ColinWright 8y ago
        My understanding is that if someone is not a customer, and I hold no data on them, then I can safely ignore any requests. At worst I can automate a response saying "I hold no data on you". For customers, how many requests would you expect? One in 100? One in 1000? If I store the data securely, and I only use it for the purpose it was intended, I can automate a response that (a) Sends them a copy of their data, (b) points them at the privacy policy saying I don't do anything unexpected with their data, and (c) offer a link to delete their data. Once set up, these should not place a significant burden on the provider of a service. I suspect we are arguing about how much work will be required. I'm saying that once set up, the administrative overhead is negligible, you are saying it isn't. Certainly the services I run have seen no increase in administrative load, I'd be interested to know who has seen a significant increase (once already set up) and why.
- JumpCrisscross 8y ago
  > you need to respond to requests to (a) tell a person what data you hold on them, (b) tell them what you do with the data, and (c) delete it if asked, unless you have a legitimate reason to keep it Over the course of a few years, doing these things might take up as much time as it would to learn a new language. For a side project, I’m not sure that’s a smart trade-off.
  - GiuseppaAcciaio 8y ago
    You could have an automated report generator/emailer to deal with a), point the user to your privacy policy for answer to b), and finally again have an automated process for c) as well. This doesn't seem to be in the "learn a new language" effort ballpark to me. If you're handling user data for a side project, then you'd better be serious enough about protecting your users' privacy; if not, either remove the need to store any more data than is required to provide whatever service it is you're providing, or rethink your approach to starting a project in the first place.
  - badestrand 8y ago
    > might take up as much time as it would to learn a new language How so? Just build yourself a tiny tool that takes an email address or username and sends them their database entries along with the standard explanations about why you need that data. For my side projects that will be around two hours per project and then 2 minutes for every request. Or am I missing something?
    - JumpCrisscross 8y ago
      > Just build yourself a tiny tool that takes an email address or username and sends them their database entries along with the standard explanations about why you need that data You're assuming automated responses will satisfy requestors and, for the unsatisfied, be seen favorably by each of the twenty-eight national regulators, today and into perpetuity. In any case, I got curious about your 2 hours / project + 2 minutes / request metric. One can achieve "basic fluency" in a number of languages within 480 hours [1]. We thus find a trade-off hyperbola [2]. For 1 project, after 14,340 requests you could have learned a new language. For 5: 2,820 per project. For 10: 1,380. At one request per day, that's under 4 years. TL; DR, even with optimistic figures, a significant toll is extracted purely for administration. [1] https://blog.thelinguist.com/how-long-should-it-take-to-learn-a-language https://blog.thelinguist.com/how-long-should-it-take-to-lear... [2] 2 * Projects + (1 / 30) * Projects * Requests = 480
- Mirioron 8y ago
  And then they spend their entire free-time playing administrator on a service that doesn't make them any money. Time they could've spent on improving the service. The alternative is that if they're outside the EU they just block the EU and if they're inside the EU then they abandon the project.
  - ColinWright 8y ago
    > And then they spend their entire free-time playing administrator on a service that doesn't make them any money. Do you really think this is going to be a constant, relentless attack on your time? Do you really think that users of a service will constantly be sending DSARs? I run a few closed services as side-projects totalling a few thousand users. I've received exactly three DSARs, and those are from people who wanted to see if I had processes in place. I'm very surprised that people think the administrative load will be significant. But these are the underlying assumptions that can, and perhaps should, be explored. Broadly speaking, how many users will send in DSARs? One in ten? One in 100? One in 1000? How long will it take to respond to a request?
    - Mirioron 8y ago
      If the service gets enough users? Perhaps it will. If I annoy the wrong person on Twitter, then I'm fairly certain I will be handling those requests for a while. Just out of curiosity, how long did it take you to respond to those requests? >But these are the underlying assumptions that can, and perhaps should, be explored. Broadly speaking, how many users will send in DSARs? One in ten? One in 100? One in 1000? >How long will it take to respond to a request? I don't know, but I do know that there are plenty of developers out there that would probably have a lot of trouble adequately responding to these kinds of requests. Particularly the people who might have some trouble with English, especially the type of English in these requests. I have no idea how those people are going to handle these situations.
      - ColinWright 8y ago
        > If the service gets enough users? Perhaps it will. If I annoy the wrong person on Twitter, then I'm fairly certain I will be handling those requests for a while. Anyone to whom you are not providing a service should not have any data released to them, so they can get a simple "I'm sorry, you're not a customer, and I hold no data on you." response. Anyone who is a customer and is sending vexatious requests - I'd refund them if appropriate and terminate their service. Especially for side-projects, you don't need the aggravation. In my case people were genuinely asking about actual data, and I took the time for the first to respond "by hand" - it took about ten minutes. The second time I documented what had been done the first, and parametrised it. Total time was about 15 minutes. The third time I ran the script by hand and checked the output. Total time was under three minutes. I'm pretty sure that after another two or three I can just let it run automatically. Time taken for subsequent queries? Probably none. And I agree that for some people, especially those for whom English is not their first language, would have trouble responding in English. It's not clear that they have to. But speaking about time taken, I'm now going to bow out. I've made my position and understanding as clear as I can. GDPR is here, and everyone can make their choice about what they do to be seen to comply. I wish you all good luck. http://www.paulgraham.com/schlep.html http://www.paulgraham.com/schlep.html
- zeveb 8y ago
  > (c) delete it if asked, unless you have a legitimate reason to keep it. Deleting it if asked might be neither cheap nor possible, depending. What if he has an audit log in his system recording that foo@bar.example attempted registered, baz@quux.example wrote a record &c.? If the audit log is a secure audit log, it's not possible to mutate a record after it's written — but that's exactly what the GDPR requires! So now he has to either allow his audit logs to be mutable (and thus no longer secure), or he has to e.g. use an opaque identifier for his users, which means he needs another database, his audit-log–viewing system has to perform joins between the logs & that database (which means that it will no longer be straightforward to view with tail(1) & friends), that join has to handle deleted users in some useful way, &c. &c. &c. That's thought he has to spend on something he didn't have to previously. There's obviously no problem with that in the case of something that's essential (and several provisions of the GDPR are essential). The problem is when the GDPR is mandating something inessential, or — in the case of its mandate that users be permitted to rewrite history — outright wrong. He's being forced by the law to implement a misfeature. It's somewhat similar to a law mandating key escrow: it imposes engineering cost to achieve a wrong end.
  - ColinWright 8y ago
    > If the audit log is a secure audit log, it's not possible to mutate a record after it's written — but that's exactly what the GDPR requires! My reading, and the advice I've seen in multiple locations, is that in the case of immutable audit logs (and backups, for example), being immutable logs (or backups) would count as a legitimate reason to retain the information. It would be required to store the logs and backups securely, but that should be done anyway. The requirement would then be to delete what's possible (which is what the GDPR says) and then not process whatever remains. In other words, it's mandating what is already good practice.
3pt14159 8y ago
Question: Can you not just have a checkbox that says "I agree not to use this service from within the EU." or something like that? Like, I don't even track IP addresses for my dumb side projects. I wouldn't know where to start with this.
- donatj 8y ago
  This is actually something I've mocked up, but I'm not sure if it flies. I also wonder if blocking by IP actually counts as processing PII... Lol. So many questions.
- bmelton 8y ago
  GDPR impacts all European citizens whether or not they're physically within Euope, so that particular checkbox verbiage is probably not enough.
  - detaro 8y ago
    The scope definition talks about location of the data subject, not citizenship: https://gdpr-info.eu/art-3-gdpr/ https://gdpr-info.eu/art-3-gdpr/
    - bmelton 8y ago
      The information obligations begin with citizenship: > One requires transparency in gathering and using data in order to allow EU citizens to exercise their rights to personal data. Therefore, the General Data Protection Regulation sets forth a variety of information obligations. American citizens don't may or may not have rights under GDPR, or may have rights only where the processing is done within European borders, but European citizens have rights under GDPR regardless of where they are.
dangerface 8y ago
"all data save email address being client side encrypted" If its client side encrypted its not Personaly identifiable information.
- donatj 8y ago
  Save meaning except. Email address is not encrypted to allow password reset and the like.
  - dangerface 8y ago
    Ah true, in the past I have hashed emails with no salt to try and provide some privacy. For password reset I just asked the user for their email when requesting the reset and tested against the hash to make sure its legit.

by donatj 8y ago

ColinWright 8y ago

Broadly speaking, and noting that IANAL, etc, etc, ... I'm not sure what the problem is. Your obligation is to keep the data secure, and only keep data that you need. Then you need to respond to requests to (a) tell a person what data you hold on them, (b) tell them what you do with the data, and (c) delete it if asked, unless you have a legitimate reason to keep it. So if someone has given you data for the purpose of you providing a service then all you need to do is treat that data with care, don't do anything your customer doesn't expect you to do, and be able to provide and/or delete it. Fair do, someone disagrees and has down-voted me. Please, having read the actual regulations[0] several times, including the recitals[1], I'd be pleased to see what's missing from that outline, so I can improve my understanding. [0] https://gdpr-info.eu/ https://gdpr-info.eu/ [1] https://gdpr-info.eu/recitals/ https://gdpr-info.eu/recitals/

testvox 8y ago
The problem is you have to do all that or face fines and lawsuits which is outside the risk envelope of most people's side projects.
- Radle 8y ago
  Try to build a treehouse without following legal guidelines and see what happens to your side project. I frankyl don't understand why web site owners are entitled to a wild west, now-law zone?
  - donatj 8y ago
    Treehouse is an odd yet apt choice as the laws vary highly by municipality. None of the treehouses I played in as a child were inspected or up to code. I think the argument to be made here anyway is the level of danger. You could die falling out of a treehouse, whereas the actual damages from mishandling a single users data is several magnitudes less.
    - freeflight 8y ago
      > You could die falling out of a treehouse, whereas the actual damages from mishandling a single users data is several magnitudes less. That's a very dangerous sentiment to have. Identity theft is a very real thing. You can do pretty horrible things impersonating other people, things that will lead to people ending up in jail, things that can ruin whole families and drive people into poverty, desperation, and suicide. It opens people up to blackmail, manipulation and a whole list of other, rather nasty, tactics. On the extreme end, there's also the fact that not everybody lives in a "free country". In many places saying the wrong things, even online, can have very final consequences. In such cases, you not taking proper care of your user's data, sharing or leaking it all over the place, can result in people vanishing in some torture dungeon never to be seen again.
      - tetromino_ 8y ago
        My entire, multi-year record of personal and financial information has been leaked and stolen at least 3 times, most recently from Equifax. In addition, certain of my passwords and financial and personal details were leaked at least a dozen times that I know about by various stores, restaurants, apps, and online forums. The consequences to me, personally? Not much. I haven't been blackmailed, I haven't been impersonated, jailed, or driven to suicide. And in this, I am not unique, not unusual. Probably at least half of the adult US population has had all their information leaked just like mine was. The overwhelming majority of them suffered few to no consequences.
        aleksei 8y ago
- ColinWright 8y ago
  Even if you're running a small side-project, you really should (a) not do things people don't expect, (b) be able to provide people with a copy of their data that you hold, and (c) delete their data if you're asked to (and you have no legitimate reason to keep it). That all seems completely reasonable to me. It's certainly reasonable that a new start-up or side-project should use these considerations as part of their design, and I should think that an existing start-up or side-project that does not comply should look hard at why not. If you think these demands are unreasonable, I'd genuinely be interested in knowing which, and why.
  - Mirioron 8y ago
    Does it seem reasonable to you? Let me propose a scenario to you. Let's suppose that you commenting on Hacker News would mean that you must adequately respond to certain messages sent to you. If you don't do that then you can be fined. Does this sound like an environment that would encourage you to share your thoughts on Hacker News? Or does it sound more like an environment, where you would just not say anything and perhaps go elsewhere? It's unreasonable, because it imposes an administrative cost on anyone that tries to do things on the side regardless whether they have good data handling practices or whether they have any intention of abusing the data. I would bet money on the fact, that JUST the fact that they must respond to a letter is enough to make some people go do something else. And who knows, maybe the side project could've been the next google.
    - wooter 8y ago
      not to mention that, historically and intrinsically, visiting a site or using someones application is a voluntary activity. no one is forcing the user to do anything and the user shouldn't be able to force the developers to do anything.
    - ColinWright 8y ago
      My understanding is that if someone is not a customer, and I hold no data on them, then I can safely ignore any requests. At worst I can automate a response saying "I hold no data on you". For customers, how many requests would you expect? One in 100? One in 1000? If I store the data securely, and I only use it for the purpose it was intended, I can automate a response that (a) Sends them a copy of their data, (b) points them at the privacy policy saying I don't do anything unexpected with their data, and (c) offer a link to delete their data. Once set up, these should not place a significant burden on the provider of a service. I suspect we are arguing about how much work will be required. I'm saying that once set up, the administrative overhead is negligible, you are saying it isn't. Certainly the services I run have seen no increase in administrative load, I'd be interested to know who has seen a significant increase (once already set up) and why.
JumpCrisscross 8y ago
> you need to respond to requests to (a) tell a person what data you hold on them, (b) tell them what you do with the data, and (c) delete it if asked, unless you have a legitimate reason to keep it Over the course of a few years, doing these things might take up as much time as it would to learn a new language. For a side project, I’m not sure that’s a smart trade-off.
- GiuseppaAcciaio 8y ago
  You could have an automated report generator/emailer to deal with a), point the user to your privacy policy for answer to b), and finally again have an automated process for c) as well. This doesn't seem to be in the "learn a new language" effort ballpark to me. If you're handling user data for a side project, then you'd better be serious enough about protecting your users' privacy; if not, either remove the need to store any more data than is required to provide whatever service it is you're providing, or rethink your approach to starting a project in the first place.
- badestrand 8y ago
  > might take up as much time as it would to learn a new language How so? Just build yourself a tiny tool that takes an email address or username and sends them their database entries along with the standard explanations about why you need that data. For my side projects that will be around two hours per project and then 2 minutes for every request. Or am I missing something?
  - JumpCrisscross 8y ago
    > Just build yourself a tiny tool that takes an email address or username and sends them their database entries along with the standard explanations about why you need that data You're assuming automated responses will satisfy requestors and, for the unsatisfied, be seen favorably by each of the twenty-eight national regulators, today and into perpetuity. In any case, I got curious about your 2 hours / project + 2 minutes / request metric. One can achieve "basic fluency" in a number of languages within 480 hours [1]. We thus find a trade-off hyperbola [2]. For 1 project, after 14,340 requests you could have learned a new language. For 5: 2,820 per project. For 10: 1,380. At one request per day, that's under 4 years. TL; DR, even with optimistic figures, a significant toll is extracted purely for administration. [1] https://blog.thelinguist.com/how-long-should-it-take-to-learn-a-language https://blog.thelinguist.com/how-long-should-it-take-to-lear... [2] 2 * Projects + (1 / 30) * Projects * Requests = 480
Mirioron 8y ago
And then they spend their entire free-time playing administrator on a service that doesn't make them any money. Time they could've spent on improving the service. The alternative is that if they're outside the EU they just block the EU and if they're inside the EU then they abandon the project.
- ColinWright 8y ago
  > And then they spend their entire free-time playing administrator on a service that doesn't make them any money. Do you really think this is going to be a constant, relentless attack on your time? Do you really think that users of a service will constantly be sending DSARs? I run a few closed services as side-projects totalling a few thousand users. I've received exactly three DSARs, and those are from people who wanted to see if I had processes in place. I'm very surprised that people think the administrative load will be significant. But these are the underlying assumptions that can, and perhaps should, be explored. Broadly speaking, how many users will send in DSARs? One in ten? One in 100? One in 1000? How long will it take to respond to a request?
  - Mirioron 8y ago
    If the service gets enough users? Perhaps it will. If I annoy the wrong person on Twitter, then I'm fairly certain I will be handling those requests for a while. Just out of curiosity, how long did it take you to respond to those requests? >But these are the underlying assumptions that can, and perhaps should, be explored. Broadly speaking, how many users will send in DSARs? One in ten? One in 100? One in 1000? >How long will it take to respond to a request? I don't know, but I do know that there are plenty of developers out there that would probably have a lot of trouble adequately responding to these kinds of requests. Particularly the people who might have some trouble with English, especially the type of English in these requests. I have no idea how those people are going to handle these situations.
    - ColinWright 8y ago
      > If the service gets enough users? Perhaps it will. If I annoy the wrong person on Twitter, then I'm fairly certain I will be handling those requests for a while. Anyone to whom you are not providing a service should not have any data released to them, so they can get a simple "I'm sorry, you're not a customer, and I hold no data on you." response. Anyone who is a customer and is sending vexatious requests - I'd refund them if appropriate and terminate their service. Especially for side-projects, you don't need the aggravation. In my case people were genuinely asking about actual data, and I took the time for the first to respond "by hand" - it took about ten minutes. The second time I documented what had been done the first, and parametrised it. Total time was about 15 minutes. The third time I ran the script by hand and checked the output. Total time was under three minutes. I'm pretty sure that after another two or three I can just let it run automatically. Time taken for subsequent queries? Probably none. And I agree that for some people, especially those for whom English is not their first language, would have trouble responding in English. It's not clear that they have to. But speaking about time taken, I'm now going to bow out. I've made my position and understanding as clear as I can. GDPR is here, and everyone can make their choice about what they do to be seen to comply. I wish you all good luck. http://www.paulgraham.com/schlep.html http://www.paulgraham.com/schlep.html
zeveb 8y ago
> (c) delete it if asked, unless you have a legitimate reason to keep it. Deleting it if asked might be neither cheap nor possible, depending. What if he has an audit log in his system recording that foo@bar.example attempted registered, baz@quux.example wrote a record &c.? If the audit log is a secure audit log, it's not possible to mutate a record after it's written — but that's exactly what the GDPR requires! So now he has to either allow his audit logs to be mutable (and thus no longer secure), or he has to e.g. use an opaque identifier for his users, which means he needs another database, his audit-log–viewing system has to perform joins between the logs & that database (which means that it will no longer be straightforward to view with tail(1) & friends), that join has to handle deleted users in some useful way, &c. &c. &c. That's thought he has to spend on something he didn't have to previously. There's obviously no problem with that in the case of something that's essential (and several provisions of the GDPR are essential). The problem is when the GDPR is mandating something inessential, or — in the case of its mandate that users be permitted to rewrite history — outright wrong. He's being forced by the law to implement a misfeature. It's somewhat similar to a law mandating key escrow: it imposes engineering cost to achieve a wrong end.
- ColinWright 8y ago
  > If the audit log is a secure audit log, it's not possible to mutate a record after it's written — but that's exactly what the GDPR requires! My reading, and the advice I've seen in multiple locations, is that in the case of immutable audit logs (and backups, for example), being immutable logs (or backups) would count as a legitimate reason to retain the information. It would be required to store the logs and backups securely, but that should be done anyway. The requirement would then be to delete what's possible (which is what the GDPR says) and then not process whatever remains. In other words, it's mandating what is already good practice.

3pt14159 8y ago

Question: Can you not just have a checkbox that says "I agree not to use this service from within the EU." or something like that? Like, I don't even track IP addresses for my dumb side projects. I wouldn't know where to start with this.

donatj 8y ago
This is actually something I've mocked up, but I'm not sure if it flies. I also wonder if blocking by IP actually counts as processing PII... Lol. So many questions.
bmelton 8y ago
GDPR impacts all European citizens whether or not they're physically within Euope, so that particular checkbox verbiage is probably not enough.
- detaro 8y ago
  The scope definition talks about location of the data subject, not citizenship: https://gdpr-info.eu/art-3-gdpr/ https://gdpr-info.eu/art-3-gdpr/
  - bmelton 8y ago
    The information obligations begin with citizenship: > One requires transparency in gathering and using data in order to allow EU citizens to exercise their rights to personal data. Therefore, the General Data Protection Regulation sets forth a variety of information obligations. American citizens don't may or may not have rights under GDPR, or may have rights only where the processing is done within European borders, but European citizens have rights under GDPR regardless of where they are.

dangerface 8y ago

"all data save email address being client side encrypted" If its client side encrypted its not Personaly identifiable information.

donatj 8y ago
Save meaning except. Email address is not encrypted to allow password reset and the like.
- dangerface 8y ago
  Ah true, in the past I have hashed emails with no salt to try and provide some privacy. For password reset I just asked the user for their email when requesting the reset and tested against the hash to make sure its legit.