EU GDPR – Another reason for SaaS to reconsider on-premise
gravitational.com
gravitational.com
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.
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.
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?
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.
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!
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.
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...
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).
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.
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...
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.
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.
Does GDPR prevent data from being leaked or mismanaged?
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.
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.
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)
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.
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.
* 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?
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.
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.
Same for event processing, can we get by with a preprocessing step that filters out data when reprocessing the event list?
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.
Your point is highly hypothetical.
[1]http://www.zdnet.com/article/facebook-releasing-your-persona...
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).
"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.
> 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).
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."
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
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.
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.
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.
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.
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.
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.
Other businesses who want to be GDPR compliant might not be able to use your service either.
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"
"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"
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.
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.
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
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-...
Wrong. If a resident in a EU country is temporarily in the US, GDPR does apply.
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.
If you do business with EU then you have to follow certain laws.
I'm really interested in more details about this case.
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.
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.
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.
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).
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.
(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."
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.
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.
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.