Of course, a data protection authority will look at the circumstances, and the GDPR is 80% common sense, 15% communicating better what you do with people's data, and 5% required boilerplate that makes every privacy policy so redundant and dull and long that nobody reads it - but the point it, it does apply, as do most laws. Only when it's about monopoly positions that might disrupt the market, then exceptions are generally in place to protect newcomers that promote competition (or perhaps if you run a communications network only for friends noncommercially you might not be required to make it tap-able).
If the business is based in the US, things get a bit more complicated due to the CLOUD Act[2].
[0]: https://ec.europa.eu/info/law/law-topic/data-protection/refo...
[1]: https://ec.europa.eu/info/law/law-topic/data-protection/refo...
[2]: https://complior.se/cloud-act-and-how-the-new-american-law-c...
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELE...
> 2. This Regulation does not apply to the processing of personal data:
> (c) by a natural person in the course of a purely personal or household activity
My sense (I am neither a lawyer nor European so this is certainly not European legal advice) is that you cannot use GDPR to compel someone to delete your contact info if they're solely a social acquaintance, but you can use it to compel them to delete it if they're a one-person business of some sort (contractor, Etsy seller, lawyer, etc.).
The person you traded phone at the bar last week, your neighbor or your coworker from last job are not.
For instance the baby sitter you hire now and then probably keeps track of the contacts of their potential clients, and you could request deletion of your data if you don’t intend to work with them for a few years.
1) if your data is processed for contractual purposes, the data processor has a right not to delete it on request
2) if your data is processed for law enforcement purposes, the data processor has a duty not to delete it on request
There are several legal grounds for processing personal data under GDPR, and consent is only one of them. I think most of the others outweigh any request for deletion by the data subject.
E.g. if some law requires a company to retain certain data for longer periods than stated in GDPR, that law still applies.
https://gdpr.eu/recital-18-not-applicable-to-personal-or-hou...
The obligation laid down in paragraph 1 of this Article shall not apply to:
* processing which is occasional, does not include, on a large scale, processing of special categories of data as referred to in Article 9(1) or processing of personal data relating to criminal convictions and offences referred to in Article 10, and is unlikely to result in a risk to the rights and freedoms of natural persons, taking into account the nature, context, scope and purposes of the processing; or
* a public authority or body.
But that doesn't matter to you. As long as you're too small to have a server and a (part-time) "controller" inside the EU, you seem to be out of luck (note: IANAL; there might be another way; cooperation with another small company, perhaps?).
As it stands right now, it is not possible for a US owned busniess to provide a service to EU citizens legally, if the business handles PII.
The reason is partly due to the basic rights of the registrant granted by GDPR must be ensured by the data processor (the company), and due to the Schrems II ruling [1] that determines that GDPR is incompatible with US law.
The non-legalese version is that US law that gives Intelligence agencies (etc) the power demand a US owned (not just based) company to hand over any data including PII, means that the basic rights of the GDPR cannot be fullfilled. [1]: https://www.gdprsummary.com/schrems-ii/
Perhaps my best solution is to block any user creation from the EU, any login from the EU, and any signed-in user request from the EU.
Maybe I can allow non-signed-in users from the EU to browse?
Or, you can just do it anyways. Its not like GDPR and Schrems II have stopped Microsoft, Amazon, Google, etc etc.
Just curious whats your product/service? And how is PII used (high level)? As a dev and sw architect, and strong supporter of GDPR, I think its interesting to (attempt to) find engineering solutions for the challenges posed by GDPR (and Schrems)
With the CLOUD Act, I'm wondering if it is illegal.
> Just curious whats your product/service? And how is PII used (high level)? As a dev and sw architect, and strong supporter of GDPR, I think its interesting to (attempt to) find engineering solutions for the challenges posed by GDPR (and Schrems)
It's a code forge.
For users with accounts, I have to store at least email addresses, which I believe are PII. I also need to store public keys (for commit signing), which could be considered "identification numbers" covered by the GDPR.
Even if I got away with not using email addresses, I can't get away with not storing public keys, unfortunately.
I believe that once I store any PII, it's game over, right?
By the way, I'm all for strong consumer privacy protection too. I would want the US to implement something like the GDPR as well. So I'm a supporter on some level. I'm just mad at the US government for the CLOUD Act.
Yes emails are PII. In general anything that can identify a person. Its a broad interpretation of "identify a person", and actually hasn't got anything to do with the sensitivity of the information. There are classes of PII for sensitive data, and extra rules for processing that, but when figuring out _if_ data is PII, sensitivity doesn't really come into it.
And you are correct, _any_ PII is "game over" in this case. But this case (US <-> EU) is also a bit of an edge case to GDPR I think. I mean most of GDPR is concerned with how a company should handle PII. Then there are some rules about transferring data to "unsafe" countries. Unsafe in this case means countries where there is high risk that the company is not handling PII correctly and/or nothing the EU (citizen) can do about it. And this is where your CLOUD Act + Schrems II comes in. It makes US an "unsafe" country to transfer data to because it brings a high risk for the EU citizen that their GDPR rights cannot/will not be enforced (and the Privacy Shield agreenment that used to make it okay away is no longer valid).
Its unfortunate, I think, because it puts GDPR in a special negative light for US engineers, and that takes away from the many good things in GDPR. I actually think most of the stuff in there is pretty good. And just for reference - I run my own company, so I'm "enjoying" GDPR compliance fully, and sure, its more work, but I haven't yet encountered a part of GDPR where I havn't though "isn't this actually how I wanted my data to be handled by other companies?"
Okay, now for the fun part - thinking up designs/architectures where your product would be GDPR compliant. Im just doing this for my own fun btw, and perhaps a nice discussion. Not trying to tell you what to do :)
Since we have the hole "unsafe" third country situation, no transfer of PII is okay. This is a bit more restricted that what we would normally deal with under GDPR.
The basic tenants for being compliant here is two things: 1) If you/your employees hasn't got access to the data, e.g. because you don't have it, you are not handling PII. 2) If data is not being sent from the client (located in EU) to your US servers, you don't have the "unsafe" country data transfer situation. And the your are compliant.
Emails (and other data attributes, like username, name, CC details, shoe size etc). I think the way to go about this is thinking in terms of that you actually need server side to make core functionality work, and what could actually be kept client side and never sent to your servers. See, in this case the problem is transferring the PII to the US. If you can somehow have a "fat" application client side, like a SPA, could you avoid sending the email to the server? What you must have is a unique identifier for users, sure, and email is normally that. But you could hash the email addr and use that as a unique key for the user. You just need it to be guaranteed unique, and dont care (most likely) what the actual mail address is. Note: Stil have to be careful with the hashed email as unique key because that could still identify a user, since its unique, and therefore PII. However if you hash client side and only send the hash, you will only have the hash server side. And if the only datapoint you have is a hash then it cannot identify a person on its own (given the properties of a one-way hash function). You'd need to put that hash in context with other info to be able to identify a person from it. And then its not PII, and you can send it to your server no problem.
The same concept should be usable for most basic data attributes, i.e. shift everything PII to the client, and if data needs to be sent then do you actually the actual value of the data or do you just need the data to have a certain property, e.g. be unique or be not-null or whatever.
Then there is the matter of storing all this data we've now shifted to the client. This is were the textbook would say "left as exercise for the reader" LOL. Storage for web apps especially is gonna be annoying to deal with. If you have an actual (not web app) client, its much easier. If your users are developers, you can get away with less user-friendly ways of managing that data client side in a web app. It seems solvable without too much fuss, with some form of local storage.
Public keys. This one is though. A public key is PII. You need the public key server side because (I'm guessing) when a user submits code (s)he attaches a signature, that you need to verify. You having that public key is part of the hole PKI idea. The first idea that comes to mind is based on the same "do you need the value of the data or do you need to know a property about the data"-thinking. You need to know the signature is valid for the submitted code. If you had a magic black box that could give you a yes/no (that you could trust) on that, you wouldn't actually need the public key, you could just give the code and the signature to your black box and it would say yay or nay.
If there was a service (i.e. API) on a server in europe that played the part of the black box, and you trusted it, you could "just" call the service with the signature (again hashed/encrypted and if you don't have the key, you can't relate the signature to a person, so its not PII) and code as input, and the service would return true/false, when you would have what you need. And no PII i.e. the public key would need to be transferred to your server / you wound't need to handle (store) it. Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup?
I feel like there must be more solutions to the public key one, but they don't come to mind right now. Was a fun exercise anyway :) I'm sure I've made so many assumptions about how your product works, that the above suggestions would never work in practise, but my point was more to illustrate that GDPR compliance can be dealt with by rethinking many of our go-to design patterns (i.e. have a central database with user info).
Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced.
I think your ideas are wonderful, and I might try to implement as many of them as possible, just for privacy reasons, even if it is impossible for me to target the EU market.
In fact, because it's a code forge, there will be a client, just like Git is a "client" for GitHub. (It will be a self-contained VCS like Fossil.) So most of what you said will work.
In fact, you are exactly correct that I need the public key for signatures on code.
But there is one hang-up. While I could let the client handle checking for code signing, I still need to store the public key.
The reason for this is because the public key will also be for account recovery. Recovery via email will also be possible, unless I can't store the email address at all. But either email or public key will be required to recover accounts.
So unless I could make it so random clients could recover accounts for other users, I need to store the public key.
If you have ideas about how to get around that, please contact me. [1] Even if not, I would love to continue talking with you about this; I want to set the standard for protecting user privacy with my code forge.
> Here is the bad part about this idea: Schrems II is actually saying that its not enough for the server/service to be in EU. If the company running the server/service is US owned, its still considered a data transfer to a US entity. So the signature verification service in EU would have to be run by someone not you/your company. And you'd ofc need to pay to use that service, no free lunch. So you'll have to consider if the value of being able to offer your product to EU customers worth the hassle and cost of this setup?
Yeah, I thought so. The biggest problem with that is that I have absolutely NO contacts in Europe that I can use. I may not even be able to travel to Europe to set something like that up. So because I only care about money enough to make what I need to in order to support my wife and me, offering my product to the EU is not worth it for the hassle and cost.
> Btw something like the above would be privacy by design, which is a core principle of GDPR and if one makes a product in that way, that would be way more compliant than 99% of all software that existed pre GPRD and slapped compliance on after GDPR was introduced.
This is encouraging, though sad since I won't be able to make it work.
To be honest, I was hoping I could make an end-to-end encrypted code forge, but I also want to support FOSS projects, which have to do their stuff in public. End-to-end encryption would only work in that case if everyone had the client on their machine, which would not be likely for a VCS; there will be people that just want to download the code from the browser without needing an extra program to do so.
Again, I'd love to chat even more. Please contact me if you feel like doing so.
Do not store any kind of PII as defined by the GDPR, ever, anywhere.
If you do, the PII data you store about your companies must be in respect of the GDPR and in particular access to it by law enforcement has to go through EU court.
Because the US has decided with the CLOUD Act that US access to all data from US companies, or any company owned by a US company, only had to go through US court, it is not possible to comply at the moment.
(before the CLOUD Act, storing the PII data within the EU and owned by a EU subsidiary was the best solution)
One could retain a US subsidiary, which might handle US or even all non-EU data.
Unfortunately it is not clear if an American individual could own or control the EU parent company. It depends on if the owner could be considered "A provider of electronic communication service or remote computing service", because if so, they could subpena you personally, on basis that you control the EU company and thus the information is within your control.
The relevant part of the law is:
> A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.
Like making it clear in the DPA/PP?
You need to protect it under EU court / jurisdiction, and the US broke that and said they have jurisdiction over any piece of data your company ever touches.
That's why the US now wants some sort of privacy shield 2.
As an actual solution you can use: find another company, an EU company, one that you don't own, to handle your PII data for you, so you never store that data yourself.
Also, be sure to read in the GDPR exactly what is and isn't PII under it, a lot of companies can work just fine without much or any PII, and a lot of people think "any" data is PII.
So we basically need to migrate to a EU based could provider ASAP?
Would this privacy shield 2 fix this problem? I suppose we can’t just wait for that.
Sadly no because you still own the data, which is the criteria the US has decided on.
> Would this privacy shield 2 fix this problem?
No idea since at this point it's merely a name for a vague demand being asked by the US.
I'm sorry for the trouble this whole situation causes to your company, though to be honest as you can imagine I am very glad that my representative in the EU didn't back down and protect my rights.
Do you know if that that makes any difference?
As a EU resident myself I completely understand, it just is a bit tough to make the changes as a small company, but if it’s legally required we’ll make them ASAP.
To ensure you don't have problem down the line, make sure they themselves store their data in the EU (for exemple, french OVH allows you to chose where you data is stored, their french datacenters are fine, but I would not go with their canadian datacenters).
Allow me to remind you that it's not just the hosting but anything that touches that data, eg analytics and error reporting services are concerned too
I was just thinking about the other services, for example would Cloudflare be ok? We proxy all our traffic through them, and they are key for DDOS prevention, I suppose data goes encrypted to them.
Anyway sadly no Cloudflare isn't ok, it's specifically one of the three provider that got Shopify convicted in the parent article (other two being Cloudfront and Fastly).
I'm the asker of the question that started this discussion. I'm a US citizen.
I'm actually on the side of the EU here. There needs to be privacy protections for consumers. Even though the requirement for a rep in the EU is impossible for me to fulfill, I admire the fact that they prioritized native EU companies over foreign ones because that is what's best for the EU inside the EU.
I'm mad at the US government for the CLOUD Act, which is egregarious and doesn't serve the interests of the US; it only serves the interests of the US government.
> There are zero plans to collect anything that is not needed
Unfortunately, it's not up for you to decide. The US has laws that makes it legal for your government to harvest data, and it has used these laws against EU citizen in the past. The US has also asked US services to collect data they were not previously collecting, with a gag order to prevent customers from learning it.
Yeah, I was afraid of this.
> The US has also asked US services to collect data they were not previously collecting, with a gag order to prevent customers from learning it.
I'm so bullish on privacy that I would actually shut down my company if this happens. US courts cannot force me to remain in business.
I believe that's what Lavabit did when they were served that kind of order. Not sure that helps with EU legality, though.
Probably not a big issue. GDPR compliance can be challenging without a suitable mindset, but it's not impossible.
* Consider that the GDPR has an extremely broad concept of “personal data” – it's not just identifying info but anything that can be reasonably linked to a person!
* Data minimization – only collecting what is needed, and only using it as actually needed – is already a great step.
* Writing a GDPR-compliant privacy notice can be a good exercise to understand what data you're processing for which purposes. Art 12–15 GDPR are the closest it gets to a checklist.
* And you'll have to implement “appropriate” security measures, but what is appropriate is largely up to you.
The more challenging part is ensuring that you're only using data processors/vendors that are contractually bound to use the data as you instruct, and that you protect “international transfers” where the recipient (e.g. vendor) is outside Europe. If you're looking for server locations in North America, I recommend looking at Canada since they have an “adequacy decision” from Europe.
You will have to be GDPR-compliant if you “offer” your service to people who are in Europe, i.e. actively market to such people, or have testimonials from EU customers, offer French localization, accept payment in EUR, and so on. Mere availability of your service is not an offer.
Offering a B2B SaaS service to companies that need to be GDPR-compliant?
You're fucked. There is no legally safe way for a company to use an US-based data processor, i.e. to engage you as a vendor. However, and this is your “get out of jail” card, many customers don't care, and will be happy as long as they can sign “SCCs”.
The more pragmatic answer is: You can just ignore human rights. The other US companies operating in the EU also don't have issues with that.
The EU isn't going to enforce its own laws in this regard anyway as more or less all EU governments are violating this laws themself. They currently all just waiting for the next round of the "safe harbor" smoke grenade.
On the other side, the EU companies that use US cloud services (so more or less all EU companies) do by the way exactly the same. Nobody cares.
All that's needed is that the USA start to recognize the rights of non US people. That's all.
Nobody likes the current situation. Really.
But it's not OK that governments collect data without proper court warrants, warrants which could be legally challenged. (And no, it's not only the US. We have here in the EU the exact same battle against our local authorities. Now that we've got some additional rights in form of the GDPR this rights need to get enforced finally. In all kinds of directions).
All operations will be in the US (interaction only through a website). The forge will be designed to allow all of a user's data to be downloaded by that user (easy access to all data). It will also allow wiping away any reference to a user in commits (right to be forgotten).
But PII does need to be collected, such as username, password, IP address, public keys, etc. There are zero plans to collect anything that is not needed; only the minimum data needed will be collected.
Edit: Oh, and the forge would not send data to third parties at all, unless such third parties are cloning code, but then they would be users, right?
Would it be legal to accept EU customers? If not, would there be anything to do to make it legal?