EU GDPR – Another reason for SaaS to reconsider on-premise(gravitational.com)
gravitational.com
EU GDPR – Another reason for SaaS to reconsider on-premise
https://gravitational.com/blog/gdpr-impact-on-saas-vendors/
103 comments
In that instance it's not always the case that SaaS will default to be a processor. GDPR describes a controller as 'which, alone or jointly with others, determines the purposes and means of the processing of personal data;'
Where a SaaS provider steps into more complex analytics or has some freedom in the process, there's an argument that they're joint controllers and bear those responsibilities. The difference between cloud and on- premises is that you're actively processing personal data in SaaS.
In many cases, the processor/controller relationship will be correct. But GDPR is focused on active compliance so it's something which should be actively considered and documented.
Where a SaaS provider steps into more complex analytics or has some freedom in the process, there's an argument that they're joint controllers and bear those responsibilities. The difference between cloud and on- premises is that you're actively processing personal data in SaaS.
In many cases, the processor/controller relationship will be correct. But GDPR is focused on active compliance so it's something which should be actively considered and documented.
Maybe I'm missing the point of your comment but a typical reason for delivering an application on your customer's infrastructure is that they don't want their data to leave their infrastructure. It's usually b-to-b where the customer is typically an enterprise buyer using their own data storage. So, the customer knows how its data is being processed.
The point is that your b2b customer is itself a b2c business that holds customer data in the product you sold them. Irrespective of whether it’s hosted or on-prem, you’re considered a processor in GDPR parlance, and your customer is a controller. Your customer needs to be able to handle consumer GDPR requests, so, if your software ever touches end-user data, it needs to be able to handle whatever those GDPR requests might be
> The point is that your b2b customer is itself a b2c business that holds customer data in the product you sold them.
This is not true of most SaaS products I use on daily basis e.g. calendar, gmail, Slack, GitHub, code review tools, CI server, etc.
This is not true of most SaaS products I use on daily basis e.g. calendar, gmail, Slack, GitHub, code review tools, CI server, etc.
If Slack uses Google Analytics, it makes GA a processor for the consent that Slack has acquired from you to track you. GA would be a processor in this scenario, and Slack would be the controller and owner of the data stored on GA’s servers.
Slack would indeed be the controller of the data, since Slack is more of a standalone product. But they have less to fear from the GDPR, because tracking is not their core business. GA otoh is different, and the point that OP is making is that if you were to make an on-prem solution of GA, surely it would be simpler to make GA compliant with GDPR as a Processor rather than going over the top and go fully on-prem?
Slack would indeed be the controller of the data, since Slack is more of a standalone product. But they have less to fear from the GDPR, because tracking is not their core business. GA otoh is different, and the point that OP is making is that if you were to make an on-prem solution of GA, surely it would be simpler to make GA compliant with GDPR as a Processor rather than going over the top and go fully on-prem?
The GDPR applies to employees as much as it applies to customers. Internal tools are not exempt.
True, one of the primary reasons enterprises want software to run on-premises is so data doesn't leave company. But this article is talking about SaaS software, specifically it is talking about fairly complex software where the software provider might actually manage the software even though it is running on-promises at a customer site.
This type of software is delivered as virtual machines, or in the case of Gravitational they package up Kubernetes. Think something more like GitHub Enterprise (if GH managed it) instead of Oracle Database.
The enterprise running the software would be providing block storage as part of their virtualization infrastructure, but they would have little insight into how the data is stored. It would be a black box. The software would need to provide sufficient APIs to get GDPR data out (deletes, dumps, etc.).
As an easy example let's say I make a SaaS logging service. I can tell my customers (the controllers) that I know nothing of their data, they send me a JSON blob and I index it, I have no idea what parts of the data are personal. They can either not send personal data in the logs, or they can use our APIs to search, extract, and delete data when a customer makes a request. For me, I wouldn't have to service any additional requests or write any additional features, it makes little difference if I deliver the software as SaaS or on-prem[1].
A harder example would be a SaaS CRM product, maybe it includes a support ticket system, a forum, purchase records, etc. All of that is locked up in a GUI, with no meaningful API. As a SaaS product I would have to write features so my customer (the controller) could dump and delete data for a specific one of their customers. I know what the records are, how they relate to individuals, what rows in what tables in what DBs matter. My customer (the controllers) doesn't know any of that. If it was delivered as on-prem software it would still need features to dump or delete that data.
[1] It isn't quite true that there is little difference between SaaS and on-prem. There are trade offs in both directions. With SaaS you have to deal with all the sub-processor stuff, ensuring they are GDPR compliant and getting consent from the controller to use each sub-processor. If it is on-prem you can pass that burden to the controller. On the other hand updating software and troubleshooting it a lot easier if you run it yourself, versus having it locked away in some enterprise virtualization system you can't access. And it is easier to write your software to run on your infra instead of all the mixes of infra that enterprises run. But then again if you are running a multi-tenant SaaS you are going to have to deal with big scaling issues, but if it runs on-prem at each customer site you have effectively sharded your data. Now you just have to make sure you can reliably run a schema change across 1000 DBs, spread across the worlds, that you can't monitors and can't access. Yep, there are trade offs.
This type of software is delivered as virtual machines, or in the case of Gravitational they package up Kubernetes. Think something more like GitHub Enterprise (if GH managed it) instead of Oracle Database.
The enterprise running the software would be providing block storage as part of their virtualization infrastructure, but they would have little insight into how the data is stored. It would be a black box. The software would need to provide sufficient APIs to get GDPR data out (deletes, dumps, etc.).
As an easy example let's say I make a SaaS logging service. I can tell my customers (the controllers) that I know nothing of their data, they send me a JSON blob and I index it, I have no idea what parts of the data are personal. They can either not send personal data in the logs, or they can use our APIs to search, extract, and delete data when a customer makes a request. For me, I wouldn't have to service any additional requests or write any additional features, it makes little difference if I deliver the software as SaaS or on-prem[1].
A harder example would be a SaaS CRM product, maybe it includes a support ticket system, a forum, purchase records, etc. All of that is locked up in a GUI, with no meaningful API. As a SaaS product I would have to write features so my customer (the controller) could dump and delete data for a specific one of their customers. I know what the records are, how they relate to individuals, what rows in what tables in what DBs matter. My customer (the controllers) doesn't know any of that. If it was delivered as on-prem software it would still need features to dump or delete that data.
[1] It isn't quite true that there is little difference between SaaS and on-prem. There are trade offs in both directions. With SaaS you have to deal with all the sub-processor stuff, ensuring they are GDPR compliant and getting consent from the controller to use each sub-processor. If it is on-prem you can pass that burden to the controller. On the other hand updating software and troubleshooting it a lot easier if you run it yourself, versus having it locked away in some enterprise virtualization system you can't access. And it is easier to write your software to run on your infra instead of all the mixes of infra that enterprises run. But then again if you are running a multi-tenant SaaS you are going to have to deal with big scaling issues, but if it runs on-prem at each customer site you have effectively sharded your data. Now you just have to make sure you can reliably run a schema change across 1000 DBs, spread across the worlds, that you can't monitors and can't access. Yep, there are trade offs.
Let's say you are an Appointment Reminder Saas to pick an HN relevant example. You are selling to a Dentist practise in Germany. The Dentist is the controller of the personal data. Your software processes the name, address, phone number of the Dentists patients. If a patient wants their records deleted (maybe moved house) then on-premises or not, your software needs to support such deletion.
if you sell it as a normal hosted sass, you are the processor and must delete and audit the deletion. if you are selling it as a packaged software (on-premises by any other name) then the Dentist is also the operator or processor - you are hands off the data. but not in the clear.
Because almost no-one buys packaged software anymore and absolutely no-one will buy it unless it says "GDPR-compliant" on the box so no matter what you have to support this.
https://www.eugdpr.org/glossary-of-terms.html
Edit - oh already answered!
if you sell it as a normal hosted sass, you are the processor and must delete and audit the deletion. if you are selling it as a packaged software (on-premises by any other name) then the Dentist is also the operator or processor - you are hands off the data. but not in the clear.
Because almost no-one buys packaged software anymore and absolutely no-one will buy it unless it says "GDPR-compliant" on the box so no matter what you have to support this.
https://www.eugdpr.org/glossary-of-terms.html
Edit - oh already answered!
This article feels the need to repurpose the term "on-premises" to mean "self-hosted".
From a previous article [0]:
In the SaaS context, “on-premise” historically meant deploying a separate instance of your SaaS application to your customer’s server room or data center, behind their firewall. More recently, this term may also include deploying to the customer’s private cloud at a cloud provider like Amazon Web Services or Azure
I'm a bit baffled this is necessary. You go from two terms that are widely understood to now having to add a disclaimer every time you say "on-premises".
0 - https://gravitational.com/blog/time-to-reconsider-going-onpr...
From a previous article [0]:
In the SaaS context, “on-premise” historically meant deploying a separate instance of your SaaS application to your customer’s server room or data center, behind their firewall. More recently, this term may also include deploying to the customer’s private cloud at a cloud provider like Amazon Web Services or Azure
I'm a bit baffled this is necessary. You go from two terms that are widely understood to now having to add a disclaimer every time you say "on-premises".
0 - https://gravitational.com/blog/time-to-reconsider-going-onpr...
Point taken. I've struggled with this because we see these terms intermingled in practice.
This is probably because most of our customers (SaaS vendors) think of everything that is not traditional multi-tenant SaaS as "on-premise". Also, self-hosted does connote the customer's IT is running the application, where a lot of times we see the vendor running the application (just on customer infrastructure).
This is probably because most of our customers (SaaS vendors) think of everything that is not traditional multi-tenant SaaS as "on-premise". Also, self-hosted does connote the customer's IT is running the application, where a lot of times we see the vendor running the application (just on customer infrastructure).
Ah, the vendor running the app on the customer's infrastructure. Got it. Thanks, that makes sense.
The motivation is that both kinds of "on-premise" create roughly similar engineering challenges. (Your app has to be adaptable to heterogenous execution environments, all your code changes will be in a partially released state for indefinite periods of time, it's hard to immediately diagnose whether a reported problem is your fault or user error...)
Self hosted may as well be on premise for most companies though.
The whole point of SaaS is that someone else manages the app. If you've ever worked in an enterprise you would understand that it can take months/years and significant amounts of money to get an app "installed". Often there needs to be a business case, project and resourcing plans, security and risk reviews, legal compliance checks etc.
The infrastructure (cloud versus on premise) is just one part of a dozen and not usually the most challenging.
The whole point of SaaS is that someone else manages the app. If you've ever worked in an enterprise you would understand that it can take months/years and significant amounts of money to get an app "installed". Often there needs to be a business case, project and resourcing plans, security and risk reviews, legal compliance checks etc.
The infrastructure (cloud versus on premise) is just one part of a dozen and not usually the most challenging.
What's your point w.r.t. using "on-premises" when "self-hosted" (on-premises or not) would suffice? I don't get it, sorry.
This post was inspired by "The Nightmare Letter: A Subject Access Request under GDPR" [0]. Which shows the potential scary consequences of subject access requests.
There's a lot of FUD around this topic. I've seen posts opinions ranging from "no big deal" to "this is actually good for U.S. SaaS" to "This is going to kill SaaS". It will be interesting to see how enforcement of the GDPR plays out.
At the moment, with Facebook transgressions in the news, the pendulum seems to be swinging towards privacy. We'll see how far it swings.
[0] https://www.linkedin.com/pulse/nightmare-letter-subject-acce...
There's a lot of FUD around this topic. I've seen posts opinions ranging from "no big deal" to "this is actually good for U.S. SaaS" to "This is going to kill SaaS". It will be interesting to see how enforcement of the GDPR plays out.
At the moment, with Facebook transgressions in the news, the pendulum seems to be swinging towards privacy. We'll see how far it swings.
[0] https://www.linkedin.com/pulse/nightmare-letter-subject-acce...
As a CTO at a European SaaS company I don't particularly find 'The Nightmare Letter' nightmarish at all. If you're doing your job properly then this stuff isn't hard.
It's had very little effect on our day-to-day - yeah, it's cost us real cash money in lawyers, and additional training for GDPR, but most of what is going to be legislation we were already doing. As an individual I welcome this legislation - it should really help to stop the shoddy practises that clearly go on (based on the amount outrage I've seen on this issue). GDPR seems, to me, to be proportionate and reasonable.
I don't see this helping US SaaS companies, because once GDPR is in-place then I'd consider EU SaaS providers to be more attractive. It's a real selling point that your data isn't leaking or being mismanaged.
If anything I see this as a potential boon for the SaaS companies doing their job properly, because the companies that have in-house systems (or have their own bespoke solutions) are going to have to prove those systems themselves - and have all the answers to The Letter. Whereas a good SaaS company can take those problems off their hands.
It's had very little effect on our day-to-day - yeah, it's cost us real cash money in lawyers, and additional training for GDPR, but most of what is going to be legislation we were already doing. As an individual I welcome this legislation - it should really help to stop the shoddy practises that clearly go on (based on the amount outrage I've seen on this issue). GDPR seems, to me, to be proportionate and reasonable.
I don't see this helping US SaaS companies, because once GDPR is in-place then I'd consider EU SaaS providers to be more attractive. It's a real selling point that your data isn't leaking or being mismanaged.
If anything I see this as a potential boon for the SaaS companies doing their job properly, because the companies that have in-house systems (or have their own bespoke solutions) are going to have to prove those systems themselves - and have all the answers to The Letter. Whereas a good SaaS company can take those problems off their hands.
> I don't see this helping US SaaS companies, because once GDPR is in-place then I'd consider EU SaaS providers to be more attractive. It's a real selling point that your data isn't leaking or being mismanaged.
That doesn't make any sense. If GDPR is in place, then US SaaS firms won't be leaking & mismanaging your data, the whole point is they'll have to start complying or else.
US SaaS firms will still have a vast advantage because: they're radically larger with far greater financial resources, have a drastically larger VC environment of initial funding, and still have the world's largest homogeneous economy as the base hub to initialize out of and get to huge scale to easily afford to spend anything they need to on compliance.
What the EU just did is make the compliance picture far more difficult and complex for small European competitors as a whole. With Brexit, the EU lost 15% of its economic mass, further aggrevating this concept of regulatory & compliance splintering across Europe. The European splintering will only get worse as individual European non-EU nations come up with their own rules on this type of stuff.
Salesforce or Workday can more easily comply with a dozen compliance approaches across the whole of Europe, than a given start-up in Portugal or Greece can.
That doesn't make any sense. If GDPR is in place, then US SaaS firms won't be leaking & mismanaging your data, the whole point is they'll have to start complying or else.
US SaaS firms will still have a vast advantage because: they're radically larger with far greater financial resources, have a drastically larger VC environment of initial funding, and still have the world's largest homogeneous economy as the base hub to initialize out of and get to huge scale to easily afford to spend anything they need to on compliance.
What the EU just did is make the compliance picture far more difficult and complex for small European competitors as a whole. With Brexit, the EU lost 15% of its economic mass, further aggrevating this concept of regulatory & compliance splintering across Europe. The European splintering will only get worse as individual European non-EU nations come up with their own rules on this type of stuff.
Salesforce or Workday can more easily comply with a dozen compliance approaches across the whole of Europe, than a given start-up in Portugal or Greece can.
You're making an argument about the good parts of GDPR into an argument about whether the political system should take sides in terms of business opportunities it gives. Is GDPR good for personal data safety? I think it is. Is GDPR easier for small businesses than for larger ones? No.
> I don't see this helping US SaaS companies, because once GDPR is in-place then I'd consider EU SaaS providers to be more attractive. It's a real selling point that your data isn't leaking or being mismanaged.
Does GDPR prevent data from being leaked or mismanaged?
Does GDPR prevent data from being leaked or mismanaged?
No - but it penalises you if you fail to follow best practice (like not encrypting data at rest for example). So, the incentive to do the right thing is greater seeing as you can be fined a percentage of your turnover.
Indeed. Just pointing out the clear difference between that and what was stated.
Thanks for clearing that up. I’m sure nobody knew what I meant until I made the clarifying post above.
As an individual I am much more likely to trust an organisation that follows GDPR regulations over one that doesn’t. That obviously doesn’t mean they’re never going to have a data breach- but by law they will have to announce it within 3 days, and will face massive fines if negligent - that, to me, is a company I would prefer to give my business to - and was my point. Pedantry doesn’t help.
As an individual I am much more likely to trust an organisation that follows GDPR regulations over one that doesn’t. That obviously doesn’t mean they’re never going to have a data breach- but by law they will have to announce it within 3 days, and will face massive fines if negligent - that, to me, is a company I would prefer to give my business to - and was my point. Pedantry doesn’t help.
GDPR is very popular here on HN, but I think it's important to keep a level head about what it actually does and what its real-world effects will be. That is the entire point of this thread, after all.
The difference between "not having a breach" and "a legal obligation to announce it within three days" is not semantic. It is absolutely material to the real-world value of GDPR, and claims about it should reflect that.
The difference between "not having a breach" and "a legal obligation to announce it within three days" is not semantic. It is absolutely material to the real-world value of GDPR, and claims about it should reflect that.
But it gives a clear way of penalising the company if they are caught doing so (and a clear definition of what "doing so" means).
Nothing in that nightmare letter seems unreasonable for an end user to want to know, and I'd be hesitant to do business with a company that can't answer those questions about their own business. If those "nightmare" questions are the bar, it's a pretty low bar.
The issue isn't whether the company has the answers to the questions, but what it costs to assemble those answers in the requested form. You can't respond to detailed legal inquiries by just having customer support copy-paste from documentation; they don't have the expertise required to guarantee a complete and correct answer.
Why do they have to copy and paste? Why couldn’t they make a self service tool where they login and get all documentation that is required by law? The law says that you have the right to information, but does it say you have the right to a human responding with only the requested information?
Just the same way a bank clerk is given a set of security questions so that he could prove your identity and the legal/security departments make sure those questions are relevant and to be trusted. Most of the time you're not speaking to the bank's lawyers when trying to open an account.
I suspect that the 'nightmare GDPR letter' pushes the boundaries on what the GDPR would probably intent as a reasonable request, and I wonder if it would hold up in court if challenged by one of the companies.
I think most of the provisions make a lot of sense if you look at them in a simple way. It's not unreasonable to ask a company:
* what information on me do you keep?
* what are you using it for?
* can you provide me with a copy of my data? (with interesting situations where the data itself might be privacy or competitively sensitive, e.g. can I expect a company to share derived insurance scores with me? what if the data also includes other people's data?)
* can you erase my data?
As for impact on small SaaS businesses, I think it is relatively limited. .e.g For my SaaS side business I could probably answer the nightmare request within a day, if I would get 1+ request per week we could probably automate the response, with the exception of manual ID validation. Information deletion is something that the app wouldn't handle well at the moment and would be a bit more work.
Thinking of it in this way, this is probably only a problem for a) large user bases (in which case I hope companies have the capacity to automate these requests efficiently), and b) data hoarding / ad companies (for which I don't really feel sorry)
I think most of the provisions make a lot of sense if you look at them in a simple way. It's not unreasonable to ask a company:
* what information on me do you keep?
* what are you using it for?
* can you provide me with a copy of my data? (with interesting situations where the data itself might be privacy or competitively sensitive, e.g. can I expect a company to share derived insurance scores with me? what if the data also includes other people's data?)
* can you erase my data?
As for impact on small SaaS businesses, I think it is relatively limited. .e.g For my SaaS side business I could probably answer the nightmare request within a day, if I would get 1+ request per week we could probably automate the response, with the exception of manual ID validation. Information deletion is something that the app wouldn't handle well at the moment and would be a bit more work.
Thinking of it in this way, this is probably only a problem for a) large user bases (in which case I hope companies have the capacity to automate these requests efficiently), and b) data hoarding / ad companies (for which I don't really feel sorry)
For any company that is compliant with GDPR (after 25th May 2018), the answers your 4 questions (2 on data collection, other 2 on data subject rights) must already be in their privacy notice on their website, with instructions for how to contact their data protection officer.
The privacy laws in my country were nearly as restrictive as GDPR and now they get a bit stricter. No big deal. GDPR is only stating the obvious and actually it is sad that the protection of most private information is not common sense but needs to be enforced with rigorous punishment.
I've had that letter bookmarked for months now, and the thing that worries me most is that for example, as a subject that hasn't ever owned an Android phone, doesn't use Google, Gmail or have a YouTube account - if I send that letter to Google, what stops Google from just straight-out lying to me? How do they prove their honesty to me if they say "we got nothing on you"?
This is a key reason why there are data protection officers under GDPR. They report to the highest level of management (mostly the board) and are independent. They are also called mini-regulators. They ensure the company is compliant.
If they are not doing their job, (and you are not content with their reply), you then appeal to the Data Protection Authority (DPA, Privacy Regulator in the country). The DPA has full powers of subpoena (and a whole lot more), and are not to be trifled with.
If they are not doing their job, (and you are not content with their reply), you then appeal to the Data Protection Authority (DPA, Privacy Regulator in the country). The DPA has full powers of subpoena (and a whole lot more), and are not to be trifled with.
That doesn't help. I'm in a similar position, but I'd like to know which data has eg. Facebook on me. If they write back "you have no account, we have no data on you" how I am to know that this is true (and it is almost certainly not)? With nothing on hand it doesn't make sense to go to a regulator.
There is a process to be followed. If you have the response from the DPO and a reasonable suspicion based on evidence, you can absolutely to to the DPA. If your evidence is strong, that may proceed on that. If not but there are many other similar complaints, they can formally ask the company to 'clarify' issues....which is a very dangerous thing if you are a company that is evasive.
You have an entity that regularly creates accounts on Facebook, then sends the letters requesting the data Facebook holds for them. For any requests replying those accounts do not exist that entity brings Facebook to court.
I also wonder how sending requests will work for companies maintaining shadow profiles. PII is defined quite widely, for example my phone number is PII because it can be used to uniquely identify me.
So how to get my PII deleted from FB's servers, for example? FB mines other people's phones for this data continuously, so will they setup a blacklist, so that my phone number will not get mined ever again from other people's phones? Blacklist will have to contain my phone number in order to work. Somewhat self-defeating. Hashing will not do much, because the search space is so small.
Also, they may have my phone, and some guess at my identity. Providing a much stronger link between my identity and my various other identifying information (phone no, emails, ...) to random shady companies and hoping they'll use it to delete data they may have on me... uh. It does not add up to something sensible.
So how to get my PII deleted from FB's servers, for example? FB mines other people's phones for this data continuously, so will they setup a blacklist, so that my phone number will not get mined ever again from other people's phones? Blacklist will have to contain my phone number in order to work. Somewhat self-defeating. Hashing will not do much, because the search space is so small.
Also, they may have my phone, and some guess at my identity. Providing a much stronger link between my identity and my various other identifying information (phone no, emails, ...) to random shady companies and hoping they'll use it to delete data they may have on me... uh. It does not add up to something sensible.
Those companies lie in their reply to you saying that they hold no information. They someone leaks the fact that they actually do hold your information; authorities organise a warrant to dump all of their hardware and realise the company was illegally collecting data. They end up in court.
Assuming that a SaaS provider is the `processor` in the GDPR. Could it comply to the GDPR by providing the following features through either API or admin panel?:
* Trigger json/zip export of all data for $user_id
* Delete all data for $user_id
* List all events where data for $user_id has been sent to $third_party
When building a new SaaS service from in 2018, this does not seem to be that much work if you design your system with these requirements in mind. A simple way to tag every resource in the database with $user_id, and an event log for third party interactions should be enough.
Am I missing something?
* Trigger json/zip export of all data for $user_id
* Delete all data for $user_id
* List all events where data for $user_id has been sent to $third_party
When building a new SaaS service from in 2018, this does not seem to be that much work if you design your system with these requirements in mind. A simple way to tag every resource in the database with $user_id, and an event log for third party interactions should be enough.
Am I missing something?
How do you delete data from backups written to persistent media?
When having CQRS/ES architecture (immutable events), how do you delete that data where by definition events can't be modified/deleted.
Just two examples, but there is much more.
When having CQRS/ES architecture (immutable events), how do you delete that data where by definition events can't be modified/deleted.
Just two examples, but there is much more.
> How do you delete data from backups written to persistent media?
You encrypt each user's data with unique symmetric key and store the key in HSM or other external, rewritable media. When requested, you delete the key for a given user, rendering user data in backups unusable.
You encrypt each user's data with unique symmetric key and store the key in HSM or other external, rewritable media. When requested, you delete the key for a given user, rendering user data in backups unusable.
I don't think that is feasible, because you don't know if this data could be easily decrypted in the future. What do you do with existing data written to persistent media?
What do you do with the futuristic tech that allows one to read all of the possible data written to a given hard drive?
Your point is highly hypothetical.
Your point is highly hypothetical.
What do you think is reasonable if you say encryption and deletion of said key is not reasonable effort enough?
You are not expected to delete data from backups, but you will probably want to put something in place where you ask for consent to store their name or something so that you can remove them again if you ever restore from a backup.
You are not expected to delete data from backups
Why not? Wouldn't it be a very convenient loophole to keep user data? Yes, it sounds very complicated, but not like it was introduced overnight.
Why not? Wouldn't it be a very convenient loophole to keep user data? Yes, it sounds very complicated, but not like it was introduced overnight.
Basically GDPR says that you can keep backed-up data but you must have your backup retention age and processes defined. That is, it's ok to say "we retain backups and logs which may contain your data for 30 days".
Interesting. Is it required to delete data from persistent data immediately or is it sufficient to retain the $to_be_deleted_user_id for preprocessing when restoring a backup?
Same for event processing, can we get by with a preprocessing step that filters out data when reprocessing the event list?
Same for event processing, can we get by with a preprocessing step that filters out data when reprocessing the event list?
The entire on-prem vs. cloud is orthogonal to GDPR. Your stack either compliant with it or it isnt, regardless if you run on AWS or on OVH.
Genuine question, do people realise Facebook Europe (among others) is headquartered in Ireland, and has to abide by fairly strict rules already?
Eg. I can write them and they have to provide me with any personal information they have on me at the moment, for a nominal fee. I could probably get most of the questions on the nightmare letter above answered!
There's one particular aspect of the GDPR which I realised recently could have a significant effect on Facebook. The regulations give users a specific right to data portability, with the wording:
"In exercising his or her right to data portability pursuant to paragraph 1, the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible."
https://gdpr-info.eu/art-20-gdpr/
Conceivably, a Facebook user could demand that Facebook support automatically sending their Facebook posts to their friends on third party social networks. I imagine that an EU court would not be very sympathetic to Facebook claiming that it isn't technically feasible for a (large, monopolistic, American) company to support this use case when small open source (European?) competitors have implemented the W3C social networking standards (e.g. ActivityPub) with no trouble.
Once Facebook is forced by the GDPR to publish data to competing sites, I imagine it will feel compelled to also support receiving data from people on those sites, otherwise the one-way flow of data would put Facebook users at a disadvantage. But then there is basically no reason to use Facebook, as users of competing sites would still be able to see and be seen by their friends on Facebook.
This is such a disastrous outcome for Facebook that I wouldn't be surprised if lawyers at Google (or some other big company) were already working on the legal complaints they are going to launch come May, when the GDPR comes into force.
"In exercising his or her right to data portability pursuant to paragraph 1, the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible."
https://gdpr-info.eu/art-20-gdpr/
Conceivably, a Facebook user could demand that Facebook support automatically sending their Facebook posts to their friends on third party social networks. I imagine that an EU court would not be very sympathetic to Facebook claiming that it isn't technically feasible for a (large, monopolistic, American) company to support this use case when small open source (European?) competitors have implemented the W3C social networking standards (e.g. ActivityPub) with no trouble.
Once Facebook is forced by the GDPR to publish data to competing sites, I imagine it will feel compelled to also support receiving data from people on those sites, otherwise the one-way flow of data would put Facebook users at a disadvantage. But then there is basically no reason to use Facebook, as users of competing sites would still be able to see and be seen by their friends on Facebook.
This is such a disastrous outcome for Facebook that I wouldn't be surprised if lawyers at Google (or some other big company) were already working on the legal complaints they are going to launch come May, when the GDPR comes into force.
That needs to be read in conjunction with A.12(3):
> The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request.
Whilst you may be able to require that Facebook send the data to a competing service, I would not read A.12(3) as requiring it to be done immediately -- Facebook could (somewhat reasonably) claim that gathering all information about an account takes some time. This limits its usefulness.
Further, A.20(1) specifies the "right to receive the personal data concerning him or her", which I would read as making a request under A.20 returns all data relating to you, and does not oblige the controller to return only specifically requested and/or new data. You have have to be comfortable with the entirety of that data being send to the third-party, and they must be set up to process the deluge of information.
Not only that, but A.12(5) provides that:
> Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either: charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or refuse to act on the request.
Repeated requests to facilitate sending posts to a third-party could quickly been seen as excessive, in which case Facebook could refuse to process the request, and I doubt that the courts would treat such requests as being within the spirit of the rights granted under A.20 (it is a right that enables moving to a new controller, rather than being intended to synchronise data between controllers on an ongoing basis).
> The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request.
Whilst you may be able to require that Facebook send the data to a competing service, I would not read A.12(3) as requiring it to be done immediately -- Facebook could (somewhat reasonably) claim that gathering all information about an account takes some time. This limits its usefulness.
Further, A.20(1) specifies the "right to receive the personal data concerning him or her", which I would read as making a request under A.20 returns all data relating to you, and does not oblige the controller to return only specifically requested and/or new data. You have have to be comfortable with the entirety of that data being send to the third-party, and they must be set up to process the deluge of information.
Not only that, but A.12(5) provides that:
> Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either: charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or refuse to act on the request.
Repeated requests to facilitate sending posts to a third-party could quickly been seen as excessive, in which case Facebook could refuse to process the request, and I doubt that the courts would treat such requests as being within the spirit of the rights granted under A.20 (it is a right that enables moving to a new controller, rather than being intended to synchronise data between controllers on an ongoing basis).
Thank you for that detailed analysis. Perhaps I should have emphasised that the scenario I am suggesting is one where there are already multiple open social networks that are communicating with each other using "industry standard" W3C social network specifications.
If technology were in widespread use for allowing instant automated publishing of social media posts to friends on other networks, then I don't see how Facebook could legitimately claim that they can only implement a process that takes weeks (or deluges their competitors with unwanted information). A court should see this as malicious compliance and demand a more "reasonable" effort from them instead.
This article:
http://ejlt.org/article/view/546/726
makes a strong case (in section 3.2) that the GDPR's data portability right should be considered in terms of EU competition law generally:
"In light of the above, it can be argued that a refusal of a dominant firm to enable data portability might be seen as a form of exclusionary abuse as it might drive its competitors out of a specific relevant market and increase market concentration."
If technology were in widespread use for allowing instant automated publishing of social media posts to friends on other networks, then I don't see how Facebook could legitimately claim that they can only implement a process that takes weeks (or deluges their competitors with unwanted information). A court should see this as malicious compliance and demand a more "reasonable" effort from them instead.
This article:
http://ejlt.org/article/view/546/726
makes a strong case (in section 3.2) that the GDPR's data portability right should be considered in terms of EU competition law generally:
"In light of the above, it can be argued that a refusal of a dominant firm to enable data portability might be seen as a form of exclusionary abuse as it might drive its competitors out of a specific relevant market and increase market concentration."
Most of the EU litigation has been against Facebook.
They have spent many millions in EU GDPR projects (such as the ability to download all records, which is in the news cycle right now).
Under the current legislation, they can be sued by each regulator in each country separately (this has happened to them multiple times). Under the GDPR, they will mostly be sued by just the Irish Data Protection Authority (other EU regulators will funnel issues to the Irish DPA first).
They have spent many millions in EU GDPR projects (such as the ability to download all records, which is in the news cycle right now).
Under the current legislation, they can be sued by each regulator in each country separately (this has happened to them multiple times). Under the GDPR, they will mostly be sued by just the Irish Data Protection Authority (other EU regulators will funnel issues to the Irish DPA first).
"strict" only applies once they've been punished for violating those rules, which has not happened with those Irish regulations as far as I am aware. Facebook gives some information out, but does not give it all[1]
[1]http://www.zdnet.com/article/facebook-releasing-your-persona...
[1]http://www.zdnet.com/article/facebook-releasing-your-persona...
According to ICO guidelines:
"Where requests are manifestly unfounded or excessive, in particular because they are repetitive, you can:
charge a reasonable fee taking into account the administrative costs of providing the information; or refuse to respond."
I wonder if that would apply to the letter?
[0]: https://ico.org.uk/for-organisations/guide-to-the-general-da...
Edit: Formatting
charge a reasonable fee taking into account the administrative costs of providing the information; or refuse to respond."
I wonder if that would apply to the letter?
[0]: https://ico.org.uk/for-organisations/guide-to-the-general-da...
Edit: Formatting
I’m not sure why this doesn’t come up more but the EU does not have any authority to force non EU companies to do anything. Please stop pretending that GDPR effects US companies not operating in the EU.
Every major consumer tech company that comes to mind is operating in EU. Facebook, Google, Twitter, Apple, Microsoft, Amazon, etc all are under EU authority in this regard despite being headquartered in USA; they have a sizeable business, thousands of employees and billions of assets in EU.
Also, if your SaaS company is selling globally (which is true for most large SaaS) then if your B2B customers are in EU, they'll require GDPR compliance if they're going to use your service for any customer data. So companies like Dropbox, Stripe, Mailchimp, Salesforce, etc are also affected and have already stated the steps they'll take to be GDPR compliant.
Also, if your SaaS company is selling globally (which is true for most large SaaS) then if your B2B customers are in EU, they'll require GDPR compliance if they're going to use your service for any customer data. So companies like Dropbox, Stripe, Mailchimp, Salesforce, etc are also affected and have already stated the steps they'll take to be GDPR compliant.
Because we live in a global world. Why would you build a startup to only be capable to NOT work in EU. When building a company and you want to have any dealing with EU companies. And there are a lot of those it just makes sense to adopt the most strict framework and deal with it.
>Why would you build a startup to only be capable to NOT work in EU.
Because adopting the lowest common denominator (GDPR etc.) won't let you grow as quickly, and you might not need the EU market to reach your personal and business goals, or your point of exit.
It might make more sense to split into a EU division once you can really afford it and are established in your main market. I think that this will happen, many will see the EU market just as feature and option to scale an already established business, even companies within the EU. They might start in the US first, and block EU access.
Because adopting the lowest common denominator (GDPR etc.) won't let you grow as quickly, and you might not need the EU market to reach your personal and business goals, or your point of exit.
It might make more sense to split into a EU division once you can really afford it and are established in your main market. I think that this will happen, many will see the EU market just as feature and option to scale an already established business, even companies within the EU. They might start in the US first, and block EU access.
Is it really that hard to implement the policies of the GDPR? The way I see it it is basically breach notification and right to access/delete data, which does not seem that difficult and probably not a burden for a startup to "not grow as quickly".
Oh, because of the internet I can serve a EU customer from the US without EU regulation. Why would a startup setup a nexus in the EU?
GDPR has its own, vague criteria for when it applies, and it's much more inclusive than the typical criteria for a nexus.
For example, things like the company actively seeking out clients in EU countries, or offering the service in EU countries' languages, make it more likely that EU will consider the company to be subject to GDPR even if it has no presence in the EU.
It seems to me that EU is overstepping their jurisdiction here, but I really don't know how international law works.
For example, things like the company actively seeking out clients in EU countries, or offering the service in EU countries' languages, make it more likely that EU will consider the company to be subject to GDPR even if it has no presence in the EU.
It seems to me that EU is overstepping their jurisdiction here, but I really don't know how international law works.
Yes the language clause makes no sense to me. If we add French to support Quebec or Spanish for S. America, we can now be roped into an EU regulation?
It's a balancing act. If you're a Canadian company (or have a Canadian subsidiary, I assume), adding French to support Quebec is not enough to show that you're targeting EU customers[1], but if you add French and payments in Euro, that might me.
[1] https://gdpr-info.eu/recitals/no-23/
[1] https://gdpr-info.eu/recitals/no-23/
If you make steps to ensure that you're not servicing EU citizens, then I guess not. A little more clarification on that would be welcome.
What if you are servicing non-EU citizens in EU countries? Or EU citizens in non-EU countries?
An EU citizen buying a product in the US, while in the US, doesn’t pay EU VAT on that product. So it follows that they also wouldn’t be “protected” by European law, despite the color of their passport. US citizens aren’t protected by HIPAA when getting medical care in Britain or France.
Further irony is that many Europeans complain about US “imperialism” in areas such as foreign policy and intellectual property, yet get positively ecstatic over the idea of the EU claiming jurisdiction over companies or users that aren’t in the EU.
Being an EU citizen in the United States using an American product doesn’t make that American product subject to EU law — it doesn’t matter how bad people want to believe that is so.
When in a country, you are subject to that countries laws; you don’t get to bring your home country’s laws with you — except under treaty agreements.
An EU citizen buying a product in the US, while in the US, doesn’t pay EU VAT on that product. So it follows that they also wouldn’t be “protected” by European law, despite the color of their passport. US citizens aren’t protected by HIPAA when getting medical care in Britain or France.
Further irony is that many Europeans complain about US “imperialism” in areas such as foreign policy and intellectual property, yet get positively ecstatic over the idea of the EU claiming jurisdiction over companies or users that aren’t in the EU.
Being an EU citizen in the United States using an American product doesn’t make that American product subject to EU law — it doesn’t matter how bad people want to believe that is so.
When in a country, you are subject to that countries laws; you don’t get to bring your home country’s laws with you — except under treaty agreements.
[deleted]
The GDPR doesn't apply to EU citizens outside the EU. It applies to people that are in the EU (be they EU citizens or not).
For the same reason you typically don't optimize for the Chinese market even though it's also huge.
There is a significant cost to compliance, even if you do it right from the very beginning (assuming it's even possible for GDPR right now), and for a lot of startups it's not worth it to spend time on that because they'll most likely be dead for unrelated reasons before they get any significant amount of GDPR clients.
It makes more sense to spend the effort on not dying instead of chasing incremental gains in markets with complicated regulatory requirements, unless dealing with those is explicitly your business proposition.
There is a significant cost to compliance, even if you do it right from the very beginning (assuming it's even possible for GDPR right now), and for a lot of startups it's not worth it to spend time on that because they'll most likely be dead for unrelated reasons before they get any significant amount of GDPR clients.
It makes more sense to spend the effort on not dying instead of chasing incremental gains in markets with complicated regulatory requirements, unless dealing with those is explicitly your business proposition.
It does affect US companies where either they, their staff, or their customers have sufficient ties to the EU for the EU to exert their authority, and where the GDPR applies by its own terms. Which is more US companies than many think.
Whether "not operating in the EU" is a different threshold than the above is a semantic argument that's less interesting to me than the substantive ones.
Whether "not operating in the EU" is a different threshold than the above is a semantic argument that's less interesting to me than the substantive ones.
I agree. The US is an independent country. The way international law works is only if we have similar law here. Like trademark agreemwnts. Or like China can sue you to post pro-gay things online in Cantonese. That makes no sense.
If you do business with people in the EU, the EU has jurisdiction. That doesn't mean they can enter the US to arrest someone, but they can (for example) tell payment processors in the EU to stop accepting any payments to the company.
An argument has been made that while you may be US only, your bank probably wishes to maintain good relations with the EU and might hand over your money on its behalf.
Can I just say that my service doesn't cater to EU residents?
You can decide not to allow EU citizens to use your service. However, the EU has a population of 508 million citizens. It's the largest population in the world after China and India. GDPR is a genuine attempt to balance the rights of data subjects against ever advancing technology. You'd be excluding yourself from one of the world's largest markets on the basis that you don't want to protect your customer's rights.
As I am interpreting the GDPR (IANAL) it is not about what you say, it is about if you have or have not users from EU.
See [0] specifically the phrase "It applies to all companies processing and holding the personal data of data subjects residing in the European Union, regardless of the company’s location"
[0] https://www.eugdpr.org/gdpr-faqs.html
See [0] specifically the phrase "It applies to all companies processing and holding the personal data of data subjects residing in the European Union, regardless of the company’s location"
[0] https://www.eugdpr.org/gdpr-faqs.html
More or less; if you just happen to be accessible from the EU, but have otherwise no connection to the EU at all, you're probably not subject to the GDPR:
"In order to determine whether such a controller or processor is offering goods or services to data subjects who are in the Union, it should be ascertained whether it is apparent that the controller or processor envisages offering services to data subjects in one or more Member States in the Union. (..) the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention"
https://gdpr-info.eu/recitals/no-23/
"In order to determine whether such a controller or processor is offering goods or services to data subjects who are in the Union, it should be ascertained whether it is apparent that the controller or processor envisages offering services to data subjects in one or more Member States in the Union. (..) the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an email address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention"
https://gdpr-info.eu/recitals/no-23/
If you don't target EU customers and you don't have an EU presence, sure.
Other businesses who want to be GDPR compliant might not be able to use your service either.
Other businesses who want to be GDPR compliant might not be able to use your service either.
Sort of - you have to actually not cater to EU residents, simply saying so might not be sufficient, and (for an exaggerated example) a company implementing a signup screen that says "wink wink nudge nudge press quit if you're from EU" while having 25% of their business income from EU credit cards would be likely treated not as compliance but as malicious evasion.
You have to avoid touching personal data of EU residents; various exceptions are understandable (e.g. people using some measures like VPN to circumvent some restriction), but in general if you do somehow happen to have a sizeable amount of such data, then obviously you're "catering to EU residents" in some way no matter what you claim.
You have to avoid touching personal data of EU residents; various exceptions are understandable (e.g. people using some measures like VPN to circumvent some restriction), but in general if you do somehow happen to have a sizeable amount of such data, then obviously you're "catering to EU residents" in some way no matter what you claim.
“25% of their business income from EU credit cards..”
Where did that 25% come from? Did you just make that up? My point is that some arbitrary EU regulator is going to tell a US based company (or Chinese, Russian, Canadian, etc.,) who that non-EU company is catering to? Under what jurisdiction does this happen? Where does a company representative show up to defend their case? They get to fly to Brussels? How does due process work? How does the EU learn about the percentage of credit card transactions? We’re going to expand their powers to track credit card transactions of individuals? No privacy concerns there right? We are going to support increased privacy violation to protect people from privacy violations? You trust your government that much? Given the history of many European countries, it would seem quite dangerous to give countries more surveillance power.
I am all for increased data hygiene for sure, but the EU has lost its fucking mind if they think they’re just going to be able to start telling non-EU companies what they can and can’t do when those companies aren’t even in the EU. The EU could start blocking websites, which would put it in the same level as China or Turkey. Did Pirate Bay ever get blocked in the EU despite enabling whitespread copyright abuses? Is the EU finally going to draw the line here?
If someone from France calls my US phone number — they are coming into my house. It isn’t like I am showing up at their house forcing them to buy my product. If I am a US company and I refuse to do business with an EU citizen — now we have national origin discrimination, which is illegal in the EU.
My SaaS product is subject to US HIPAA and the HITECH act which directly conflict with this European law. I am required to maintain detailed access logs for 7 years, but to do that, now I have to violate an EU law. We have EU patients who see US medical professionals. So now we are in a hell of a pickle. We have to violate HIPPA to follow the EU. Interestingly, HIPAA is actually stricter around privacy than the EU law — except there are still conflicts, especially around audit logs and data retention.
Additionally, to avoid servicing EU customers, a Canadian company would have to violate the EU national origin discrimination law? Or they’d otherwise be forced to conform their systems to a framework to which they had zero representation in creating? Who represented the Canadian companies when this law was being written by the EU? Because if the EU is going to imply that Canada is subject to said law, then Canada ought to have had a voice in its creation right?
The people who supported and created this law — let’s not pretend this is about privacy. This is about creating trade barriers. The recent obsession with the EU and US tech companies is further proof that there is a clear bias, or perhaps an inferiority complex from the EU. France especially.. they’re actually going after Apple because of the iOS and Mac App Store but they don’t do a damned thing when (Dutch-based) Booking.com takes high percentages of hotel/lodging bookings, including keeping customer data. Basically Booking.com is just like an App Store for hotels — hotels agree to a percentage of revenues for the marketing benefit of being in the Booking “store.” But France doesn’t sue Booking.com for that. But they sue Apple on behalf of French developers? Booking.com also prohibits lower pricing being offered to other distribution channels. But the EU or France isn’t trying to sue Booking.com for high commissions they are suing Apple over.
Give me a fucking break. This law is nothing but a trade barrier wrapped in some feel-good packaging. Is the EU really going to fine BNB bank 5% of global revenues when BNP shares my banking data to telemarketers in their insurance division without my explicit permission or knowledge? Of course not. BNB is French.
Where did that 25% come from? Did you just make that up? My point is that some arbitrary EU regulator is going to tell a US based company (or Chinese, Russian, Canadian, etc.,) who that non-EU company is catering to? Under what jurisdiction does this happen? Where does a company representative show up to defend their case? They get to fly to Brussels? How does due process work? How does the EU learn about the percentage of credit card transactions? We’re going to expand their powers to track credit card transactions of individuals? No privacy concerns there right? We are going to support increased privacy violation to protect people from privacy violations? You trust your government that much? Given the history of many European countries, it would seem quite dangerous to give countries more surveillance power.
I am all for increased data hygiene for sure, but the EU has lost its fucking mind if they think they’re just going to be able to start telling non-EU companies what they can and can’t do when those companies aren’t even in the EU. The EU could start blocking websites, which would put it in the same level as China or Turkey. Did Pirate Bay ever get blocked in the EU despite enabling whitespread copyright abuses? Is the EU finally going to draw the line here?
If someone from France calls my US phone number — they are coming into my house. It isn’t like I am showing up at their house forcing them to buy my product. If I am a US company and I refuse to do business with an EU citizen — now we have national origin discrimination, which is illegal in the EU.
My SaaS product is subject to US HIPAA and the HITECH act which directly conflict with this European law. I am required to maintain detailed access logs for 7 years, but to do that, now I have to violate an EU law. We have EU patients who see US medical professionals. So now we are in a hell of a pickle. We have to violate HIPPA to follow the EU. Interestingly, HIPAA is actually stricter around privacy than the EU law — except there are still conflicts, especially around audit logs and data retention.
Additionally, to avoid servicing EU customers, a Canadian company would have to violate the EU national origin discrimination law? Or they’d otherwise be forced to conform their systems to a framework to which they had zero representation in creating? Who represented the Canadian companies when this law was being written by the EU? Because if the EU is going to imply that Canada is subject to said law, then Canada ought to have had a voice in its creation right?
The people who supported and created this law — let’s not pretend this is about privacy. This is about creating trade barriers. The recent obsession with the EU and US tech companies is further proof that there is a clear bias, or perhaps an inferiority complex from the EU. France especially.. they’re actually going after Apple because of the iOS and Mac App Store but they don’t do a damned thing when (Dutch-based) Booking.com takes high percentages of hotel/lodging bookings, including keeping customer data. Basically Booking.com is just like an App Store for hotels — hotels agree to a percentage of revenues for the marketing benefit of being in the Booking “store.” But France doesn’t sue Booking.com for that. But they sue Apple on behalf of French developers? Booking.com also prohibits lower pricing being offered to other distribution channels. But the EU or France isn’t trying to sue Booking.com for high commissions they are suing Apple over.
Give me a fucking break. This law is nothing but a trade barrier wrapped in some feel-good packaging. Is the EU really going to fine BNB bank 5% of global revenues when BNP shares my banking data to telemarketers in their insurance division without my explicit permission or knowledge? Of course not. BNB is French.
I am all for increased data hygiene for sure, but the EU has lost its fucking mind if they think they’re just going to be able to start telling non-EU companies what they can and can’t do when those companies aren’t even in the EU.
Countries try to do this all the time; just ask Marc Emery.
The EU could start blocking websites
There are many other tools besides blocking websites, unless your site is purely a source of information, in which case the EU is unlikely to care.
Most likely, they'll try to prevent any business such companies have in the EU (e.g. telling payment providers to cut them off).
It isn’t like I am showing up at their house forcing them to buy my product. If I am a US company and I refuse to do business with an EU citizen — now we have national origin discrimination, which is illegal in the EU.
The GDPR is not based on the nationality or citizenship, but on location. If an EU citizen is in the US, the GDPR doesn't apply.
the EU or France isn’t trying to sue Booking.com for high commissions they are suing Apple over.
Booking.com is under investigation by French and other EU anti-trust regulators, and had to make concessions preventing them from over-controlling hotels[1]. It was also explicitly mentioned as one of the companies whose market dominance could put "the whole European economy at risk"[2].
[1} https://www.reuters.com/article/us-booking-france/france-swe...
[2] https://www.theguardian.com/technology/2015/apr/24/eu-warns-...
Countries try to do this all the time; just ask Marc Emery.
The EU could start blocking websites
There are many other tools besides blocking websites, unless your site is purely a source of information, in which case the EU is unlikely to care.
Most likely, they'll try to prevent any business such companies have in the EU (e.g. telling payment providers to cut them off).
It isn’t like I am showing up at their house forcing them to buy my product. If I am a US company and I refuse to do business with an EU citizen — now we have national origin discrimination, which is illegal in the EU.
The GDPR is not based on the nationality or citizenship, but on location. If an EU citizen is in the US, the GDPR doesn't apply.
the EU or France isn’t trying to sue Booking.com for high commissions they are suing Apple over.
Booking.com is under investigation by French and other EU anti-trust regulators, and had to make concessions preventing them from over-controlling hotels[1]. It was also explicitly mentioned as one of the companies whose market dominance could put "the whole European economy at risk"[2].
[1} https://www.reuters.com/article/us-booking-france/france-swe...
[2] https://www.theguardian.com/technology/2015/apr/24/eu-warns-...
> If an EU citizen is in the US, the GDPR doesn't apply.
Wrong. If a resident in a EU country is temporarily in the US, GDPR does apply.
Wrong. If a resident in a EU country is temporarily in the US, GDPR does apply.
Can you give a citation for that? It goes against everything I've been reading.
The text of the GDPR says: "This Regulation applies to the processing of personal data of data subjects who are in the Union", not to all EU citizens.
The text of the GDPR says: "This Regulation applies to the processing of personal data of data subjects who are in the Union", not to all EU citizens.
Try digging through this:
https://news.ycombinator.com/item?id=16479079
https://news.ycombinator.com/item?id=16479079
"We have to violate HIPPA to follow the EU." is strictly not true, legal requirements is a valid reason (user consent is just one of possible reasons) that allows you store and process private data.
> Where did that 25% come from? Did you just make that up?
Yes they did, it was an example
> My SaaS product is subject to US HIPAA and the HITECH act which directly conflict with this European law.
Law is not trumped by the GDPR. "I can't, it's the law" is a valid reason for not being able to comply
Yes they did, it was an example
> My SaaS product is subject to US HIPAA and the HITECH act which directly conflict with this European law.
Law is not trumped by the GDPR. "I can't, it's the law" is a valid reason for not being able to comply
A colleague (not direct colleague) was fined because he, while executing his normal responsibilities, accidentally broke a German custom rule. He's not German, nor located in Germany. German custom fined him at his private residence. He performed this work on behalf of the company. German customs didn't care; figured out where he currently lives and sent the fine to him personally (his name is on it). So he's basically liable according to German customs.
If you do business with EU then you have to follow certain laws.
If you do business with EU then you have to follow certain laws.
What happens if he doesn't pay?
I'm really interested in more details about this case.
I'm really interested in more details about this case.
Just slightly off topic, has anyone done an opinionated legal analysis of what GDPR means in the context of delivering a complex application. For example let’s say a recruitment company internal system. I think business people and lawyers alone struggle to grasp the meaning and spirit of the rules.
That makes no sense, SaaS makes it harder to be compliant with GDPR since you have to rely on other companies to ensure erasure, and compliance. I know of specific companies who were left vulnerable since they had no idea what was being kept on AWS
This letter is interesting.. and paints a bleak future.
What is stopping someone who wants to make easy money (like me) from going on Fiverr and selling my GDPR request letters?
Example: 5$ for 5 (could be anything) GDPR request letters to any company of your choosing?
This way, a malicious actor can buy thousands of GDPR requests and DDoS anyone but big companies like Google.
The cherry on top is that they have 1 month to comply so after they remove the information, I can simply repeat the process after the time limit. So they will eventually have to implement some kind of banning process which will affect their FTUE/onboarding giving the competition an advantage.
I bet this is the most basic idea that will appear in the blackhat world where they can probably poison the data compliance of various companies so that their services get shuttered.
What is stopping someone who wants to make easy money (like me) from going on Fiverr and selling my GDPR request letters?
Example: 5$ for 5 (could be anything) GDPR request letters to any company of your choosing?
This way, a malicious actor can buy thousands of GDPR requests and DDoS anyone but big companies like Google.
The cherry on top is that they have 1 month to comply so after they remove the information, I can simply repeat the process after the time limit. So they will eventually have to implement some kind of banning process which will affect their FTUE/onboarding giving the competition an advantage.
I bet this is the most basic idea that will appear in the blackhat world where they can probably poison the data compliance of various companies so that their services get shuttered.
I hope people do send lots of GDPR requests. I plan on doing so myself.
The answer is very simple. You should have a simple automated one-click method of knowing where all data relate to each user is, and an automated way of clearing it all. Job done.
The answer is very simple. You should have a simple automated one-click method of knowing where all data relate to each user is, and an automated way of clearing it all. Job done.
My "business" idea would probably last until the tech stack catches up. At this moment there is no easy way to handle this request for a simple helpdesk clerk without involving some pricier jobs.
Even with the tech, it still requires a human (for now) to read the request, understand it and process it.
Perhaps the future is AI interpreting the request and doing all the operations automatically or providing the client with a panel that can do all of these without having to contact the company.
Even with the tech, it still requires a human (for now) to read the request, understand it and process it.
Perhaps the future is AI interpreting the request and doing all the operations automatically or providing the client with a panel that can do all of these without having to contact the company.
I guess there is nothing that restricts the amount of information you can send. Why not just document everything and refer to that instead? Is there anything in GDPR that states you need to give a specific answer tailored to the individual customer?
The easy part is providing the information about how the data is used because it's do once, reuse always. Just refer to a document.
The hard part is the right to be forgotten which requires the company to remove all information that pertains to a person. The tech stack still has to implement some stuff here in order to reduce costs and make it easier.
Having to contact your database administrator because you can't delete something without leaving dangling information all over is bad tech implementation which will probably require a huge rework for some companies.
I wonder how you can send the information to the client. If you use GMail then GMail will also know the personal information (they used to read your emails.. good stuff).
The hard part is the right to be forgotten which requires the company to remove all information that pertains to a person. The tech stack still has to implement some stuff here in order to reduce costs and make it easier.
Having to contact your database administrator because you can't delete something without leaving dangling information all over is bad tech implementation which will probably require a huge rework for some companies.
I wonder how you can send the information to the client. If you use GMail then GMail will also know the personal information (they used to read your emails.. good stuff).
The regulation doesn't specify how a Subject Access Request is delivered, they encourage you to send it in writing, but it doesn't have to be.
As a business, you cannot dictate how or where your customers/employees submit a SAR, so you need to be ready to pick up on the fact that it could be asked anywhere.
So it is actually worse, because you need to train all staff up to recognise a SAR in all areas that you communicate with customers.
As a business, you cannot dictate how or where your customers/employees submit a SAR, so you need to be ready to pick up on the fact that it could be asked anywhere.
So it is actually worse, because you need to train all staff up to recognise a SAR in all areas that you communicate with customers.
Although this is a risk, it has been somewhat accounted for in GDPR:
(from ico.org.uk - https://ico.org.uk/for-organisations/guide-to-the-general-da...)
"Can I charge a fee for dealing with a subject access request?
You must provide a copy of the information free of charge. However, you can charge a 'reasonable fee' when a request is manifestly unfounded or excessive, particularly if it is repetitive.
You may also charge a reasonable fee to comply with requests for further copies of the same information. This does not mean that you can charge for all subsequent access requests."
(from ico.org.uk - https://ico.org.uk/for-organisations/guide-to-the-general-da...)
"Can I charge a fee for dealing with a subject access request?
You must provide a copy of the information free of charge. However, you can charge a 'reasonable fee' when a request is manifestly unfounded or excessive, particularly if it is repetitive.
You may also charge a reasonable fee to comply with requests for further copies of the same information. This does not mean that you can charge for all subsequent access requests."
Subject access requests have existed for twenty years in the UK. The Information Commissioner's Office provides free guides on how to request data. Most people aren't aware of their right to do this. Organisations can charge under the current legislation but often don't.
A lot of organisations forget to discuss the scope of a subject access request. If you imagine an employee at an average company, an undefined subject access request can include months or years of pension contributions, internet and email logs, training records, meal choices for their end of year party... if their issue is a recent performance review, the scope will often be email chains or HR documentation relating to that. The incentive for them is that they can often have the data they're interested in a short space of time rather than wait longer for pages of data they've got no need in. If you do this, make sure it's a genuine conversation with them and it's documented as to the scope they agreed.
Remember that right to be forgotten isn't an absolute right especially where you're relying on basis other than consent. If you ask your employer to erase all data about you, they'd have an argument under 17.1.a. to argue that it's necessary to keep that information in order to pay you. Nor can you ask the police or tax office to erase your data.
A lot of organisations forget to discuss the scope of a subject access request. If you imagine an employee at an average company, an undefined subject access request can include months or years of pension contributions, internet and email logs, training records, meal choices for their end of year party... if their issue is a recent performance review, the scope will often be email chains or HR documentation relating to that. The incentive for them is that they can often have the data they're interested in a short space of time rather than wait longer for pages of data they've got no need in. If you do this, make sure it's a genuine conversation with them and it's documented as to the scope they agreed.
Remember that right to be forgotten isn't an absolute right especially where you're relying on basis other than consent. If you ask your employer to erase all data about you, they'd have an argument under 17.1.a. to argue that it's necessary to keep that information in order to pay you. Nor can you ask the police or tax office to erase your data.
This idea smells of 'one weird trick lawyers HATE'.
I'd be very surprised if a court saw nothing wrong with spamming otherwise-legal requests nonstop every month, in exchange for monetary payment by a third party to boot. I imagine it could easily fall under harassment, or abuse of the court, or some other misdemeaner with sufficient leeway to interpretation (which it would be totally appropriate to apply).
Also, consider that the fact that they are GDPR requests isn't really germane to your idea. Surely there already exist some kind of requests that a customer can legally submit to a company and which can be individually burdensome to answer - perhaps specific to a particular sector, say banking, medical, or insurance. Yet I am not aware of anybody trying this particular route to cripple their competitors.
Another thing, say that the company being spammed stops responding to those malicious requests. Nothing is gonna happen unless you actually file a complaint against them for not responding, and you probably aren't going to do that for a few dollars, especially when you know you are acting in very far from good faith.
I'd be very surprised if a court saw nothing wrong with spamming otherwise-legal requests nonstop every month, in exchange for monetary payment by a third party to boot. I imagine it could easily fall under harassment, or abuse of the court, or some other misdemeaner with sufficient leeway to interpretation (which it would be totally appropriate to apply).
Also, consider that the fact that they are GDPR requests isn't really germane to your idea. Surely there already exist some kind of requests that a customer can legally submit to a company and which can be individually burdensome to answer - perhaps specific to a particular sector, say banking, medical, or insurance. Yet I am not aware of anybody trying this particular route to cripple their competitors.
Another thing, say that the company being spammed stops responding to those malicious requests. Nothing is gonna happen unless you actually file a complaint against them for not responding, and you probably aren't going to do that for a few dollars, especially when you know you are acting in very far from good faith.
> This way, a malicious actor can buy thousands of GDPR requests and DDoS anyone but big companies like Google.
FWIW, request letters like this have been possible in Germany for multiple decades, and I haven't heard of any DDoSing of companies yet. Here's a representative e-mail template whose lineage goes back to 1998:
German: http://www.ulm.ccc.de/old/chaos-seminar/spam/spam-bsdg-auffo...
English: https://translate.google.com/translate?sl=auto&tl=en&js=y&pr...
I have sent similar letters in the past and always received prompt answers.
FWIW, request letters like this have been possible in Germany for multiple decades, and I haven't heard of any DDoSing of companies yet. Here's a representative e-mail template whose lineage goes back to 1998:
German: http://www.ulm.ccc.de/old/chaos-seminar/spam/spam-bsdg-auffo...
English: https://translate.google.com/translate?sl=auto&tl=en&js=y&pr...
I have sent similar letters in the past and always received prompt answers.
While I generally applaud the idea, I cannot help but notice that the most likely abuser of users personal data is the governments of the EU itself.
Put another way, when a consumer goes to a consumer site and gives it personal data, that consumer site is the controller. When the controller uses a third-party SaaS to process or store the data, that third-party is a processor.
If you are a controller you need to ensure that your processors are capable of handling GDPR requests, e.g., they can delete specific data for a user or provide a dump for a user. The processor (third-party SaaS) will have to write that capability into their software.
Bringing that SaaS software on-premises doesn't change much. It eliminates the processor, but if I'm a controller purchasing some big SaaS-like product to run myself, I'm going to insist it have GDPR features built-in. The third-party SaaS vendor will have to write GDPR feature whether they sell it as SaaS or on-prem.