On Thursday, 25 January 2024 at 00:15:57 UTC, Adam Wilson wrote:
> On Wednesday, 24 January 2024 at 13:07:26 UTC, Arafel wrote:
>> IANAL, so I have no idea of how this applies to the DLF, who I assume sits in the US, but I thought it might be of interest.
>
> IANAL either, but I did the GDPR compliance engineering for my teams product at MSFT. The basic principle is that, unless the service is physically hosted in the EU, GDPR has no legal force. If a European connects to a US hosted service, they can have no legal expectation that GDPR regulations will be followed and if they do it is as a courtesy and no action may be brought under the GDPR.
>
> IIRC, the EU originally tried to write the law as "any service that any European connects to must comply", but I think someone somewhere along the way pointed at that most of these services were held in the US and the most effective way to "comply" was to simply block EU IPs until the engineering work was completed (if the company had any compelling reason to stay accessible in the EU market). And enforcement would be impossible without US support and they got a hard "no" on that.
>
> When I was doing this for MSFT, we just held off deploying our product into the EU datacenters and product offerings until the engineering and documentation was complete. Took a year of my life that work did.
>
> For my current project, our non-US plans consist of "block their IPs." GDPR is a massive capital sink for an small business.

Erm, IANAL either, but the GDPR does apply to US companies that want to operate inside he EU, since the regulation is extra-territorial in scope[1]. Basically any company/organisation outside of the EU storing/processing information about EU nationals (or non-EU national living in the EU) should be aware that they do run the risk of being fined for non-compliance with the GDPR.

[1] https://gdpr.eu/compliance-checklist-us-companies/

On Thursday, 25 January 2024 at 15:21:25 UTC, Danny Arends wrote:
> On Thursday, 25 January 2024 at 00:15:57 UTC, Adam Wilson wrote:
>> [...]
>
> Erm, IANAL either, but the GDPR does apply to US companies that want to operate inside he EU, since the regulation is extra-territorial in scope[1]. Basically any company/organisation outside of the EU storing/processing information about EU nationals (or non-EU national living in the EU) should be aware that they do run the risk of being fined for non-compliance with the GDPR.
>
> [1] https://gdpr.eu/compliance-checklist-us-companies/

Just to add, The D foundation is exempt as long as it has less than 250 employees [2]

[2] https://gdpr.eu/companies-outside-of-europe/

On Thursday, 25 January 2024 at 00:15:57 UTC, Adam Wilson wrote:
> 
> For my current project, our non-US plans consist of "block their IPs." GDPR is a massive capital sink for an small business.

Why block eu ips for the eu?

"GDPR Notice, we are not in the eu and if you wish to enforce this please invade newyork, make your way through the midwest, then conquer California; eu citizens may be interest in reading the [a]declaration of independence[/a] and the [a]first ammendment[/a] for futher details"

On Thursday, 25 January 2024 at 16:00:21 UTC, monkyyy wrote:
> On Thursday, 25 January 2024 at 00:15:57 UTC, Adam Wilson wrote:
>> 
>> For my current project, our non-US plans consist of "block their IPs." GDPR is a massive capital sink for an small business.
>
> Why block eu ips for the eu?
>

To avoid threads like this? It clearly and unambiguously solves the entire question.

Also, localization is a massive headache (re: expensive) that we'd rather just not deal with. To be fair, we won't be exporting outside the US in general, because we aren't going to localize to French (Canada) either and that's a legal requirement there.

The US is far and away the biggest market for our software, so we find it easier to focus on that.

I am all for following the local laws. But there is no requirement that we do business with locales whose laws we find too onerous to comply with.

On Sunday, 28 January 2024 at 03:42:41 UTC, Adam Wilson wrote:
> ...
> I am all for following the local laws. But there is no requirement that we do business with locales whose laws we find too onerous to comply with.

That is certainly fairenough.

However, the focus (and your focus as a developer) should be on protecting the personal data of citizens, and not on geography.

That GDPR compliance can be too onerous for some, is certainly an issue, but not an excuse to not take all reasonable measures to protect the personal data of citizens, including U.S citizens.

Privacy by design and default, should be the guiding principle, regardless of local laws and geography. If it's not, it WILL come back to bite you, that's is for certain.

On Sunday, 28 January 2024 at 04:04:42 UTC, FairEnough wrote:
> However, the focus (and your focus as a developer) should be on protecting the personal data of citizens, and not on geography.
>
> That GDPR compliance can be too onerous for some, is certainly an issue, but not an excuse to not take all reasonable measures to protect the personal data of citizens, including U.S citizens.
>
> Privacy by design and default, should be the guiding principle, regardless of local laws and geography. If it's not, it WILL come back to bite you, that's is for certain.

I don't disagree with any of that, and we do take it very seriously, probably more so than most. And I've actually done this kind of work for MSFT and others. But most regulation compliance regimes do very little in practice to actually ensure that data is secure, and GDPR is no exception.

These types of laws are all about liability and redress when something does go wrong. By complying with GDPR the company gets a "pass" on liability so long as it complied with said regulations. A simple example would be: Company implements a compliant password hashing regime, Customer selects weak password that is on a rainbow table, Customers data is stolen. The company can say "We complied with the regulations, the customer as at fault for selecting a weak password." You could argue that the companies password hashing regime was also sufficiently weak to allow a hashed password that appears in a rainbow table, but the company gets a pass because it "complied".

Essentially, this is incredibly expensive cover for businesses so that they can outsource their liability to the user or government. I can either spend the money on meeting some regulations, or spend the money on implementing actually systems. In a capital constrained environment, it is better to solve the regulation problem as cheaply as possible (IP blocks are free), and focus on building a secure system.

In any case, a sufficiently well developed security system is going to far exceed the standards of any government regulation, so if one day down the road you decide to open up to other countries, you aren't paying to redevelop the whole security system for "compliance." You pay the fat legal/audit fees and move on.