Yes please! That sounds great.

This is the difference between a data processor and a data controller in the GDPR.

Adding friction makes sense in this context. The ease with which we as technologists move customer data between systems directly contributes to the privacy problem. It’s not the only avenue to improve end-user privacy, but as long it remains easy for companies to move sensitive customer data between systems, this will continue to be abused.

The EU solution for that is specific 'data processor' agreements where (a) they process the data on your behalf; (b) they don't gain any permission whatsoever to use that data for their own purposes, only what you ask them to do; (c) they only have the right to do with that data the same things you are permitted to do; (d) you have to inform users (but not necessarily get consent) of all the processors which are handling their data; (e) you're fully responsible for what the processor does with that data. Reasonable cloud providers like Saleforce, Splunk (and pretty much all others which do business in EU) all have adapted to GDPR and will give contractual guarantees that they'll do everything properly but it's up to you to pick providers which will actually uphold that contract.

It sounds nice in theory and in legal words, but in practice it's very hard to control that it works and that everyone follows this.

You can just think of how complex it is from a technical perspective to implement this. Sync all those systems, databases and vendors if a user on my website deletes his data or account. And in case one of those vendors or sub vendors fail to delete (let's say their API responds with an error or I had implemented it wrong or it stopped working due to an API change). It gets hairy quite fast.

It's not simple, but also from the technical and business process perspective it's mostly a solved problem, all the international cloud B2B services know how to handle that for their customers.

I mean, that's not theory or some hypothetical proposal, that's the established practice of how handling private data works for more than 5 years for almost half a billion people and all the businesses in EU; that's how (for example) Salesforce works with all the many EU companies handling data in Salesforce systems.

In general, the process for handling actual business data for all kinds of companies from manufacturing to retail is quite clear, and the only disputes we see are for the (relatively few) global online consumer service companies handling the exploitation of online customer data. If you're e.g. a flower shop (even with online ordering) or a dental clinic (even with online appointments) and you don't want to explicitly stretch the limits with some shenanigans, then you just follow the same standard practices as all other shops in your country, all while using whatever online services you need - it's very rare that some global B2B service doesn't handle GDPR compliance, all that I wrote above is what almost every cloud company will do for you because they do that for so many customers for years already.

Point d is not true.

If you hire Salesforce you generally disclose to your users that you use Salesforce. But you don't tell them all of Salesforce's processors, and all of their professors, and so on down the infinite loop.

No, in short, all of them that want to do with data anything, other than what you instruct them to do, needs an explicit consent.

There is a difference between data controller and data processor. AWS FAQ on GDPR [1] has actually a good paragraph on it, see "Is AWS a data processor or a data controller under the GDPR?".

In your example all cloud providers and SaaS businesses like Splunk store data on your behalf and you own and control it. For them it's just a blob of data and they are supposed to be agnostic of its business meaning. With more targeted SaaS business like Salesforce, it might be more nuanced, depends if they want to do any kind data mining / processing themselves, but if they want to, then yeah, they need an explicit consent. A law like this forces SaaS companies to remove any ambiguity from their service agreements to make sure they are strictly designated as data processors when it comes to user data their customers supply them. This AWS GDPR addendum [2] exists for this reason. Otherwise, as a small business you rarely can negotiate a tailored agreement with a large SaaS company to make sure that the data you pump into it aren't going places.

[1] https://aws.amazon.com/compliance/gdpr-center/

[2] https://d1.awsstatic.com/legal/aws-gdpr/AWS_GDPR_DPA.pdf

Saas vendors typically can use customer data both to "provide" their services but also to "improve" their services. It's not entirely clear what is and isn't okay under "improve."