Live data from Hacker News

GDPR for side-projects? Blocking all EU traffic with Nginx in 3 simple steps

medium.com

41–50 of 54 posts

Re: GDPR for side-projects? Blocking all EU traffic with Nginx in 3 simple steps

#41
post #39
post #34

Earlier quoted context omitted.

If it makes no money why spend money on storage?

Storage is cheap. Time is not.

Clearly it isn’t anymore.

Also realistically storage has never been cheap - it’s just that historically the only people for whom it was expensive were the users.

Re: GDPR for side-projects? Blocking all EU traffic with Nginx in 3 simple steps

#42
Along with the author, I am hesitant to needlessly follow regulations which only apply to a small portion of global population of which I am not a part. Especially since there are simple ways to sidestep the liability.

This, however, does give me an idea. Does anyone have an interest in a web framework which provides user/data management in a gdpr compliant way?

Re: GDPR for side-projects? Blocking all EU traffic with Nginx in 3 simple steps

#44

Earlier quoted context omitted.

Yes, but my understanding is that you don't need to automate these features, so you would just do it all manually until your scale starts to make building tools worth it.

Maybe they don't want to spend time doing it manually...?

Statistically, we're not talking about a lot of requests here and they're most likely to be deletions which should be trivial.

Re: GDPR for side-projects? Blocking all EU traffic with Nginx in 3 simple steps

#46
post #40
post #38

Earlier quoted context omitted.

This is an extremely naive bunch of statements. For side projects where there is only a single developer, it's not a matter of "not caring" but literally not having the time to do these things. Putting an archive system into a service may not be as easy as a DB query. It could be pulling images out of a file storage system, generating thousands of PDF documents or a million other ways data is stored. I hope you can r…

ok, I am going to be nice here: * how are you structuring data such that it is available to you and your site, without also being able to pull it all out into an archive? * literally all of my experience has been that securing data is a much harder challenge than any other part of a web facing system. Also, the thing that everyone seems he’ll bent on ignoring: you do not need an archive mechanism if you do not store…

Not the parent poster but:

> how are you structuring data such that it is available to you and your site, without also being able to pull it all out into an archive?

I don't believe the point is that it cannot be pulled into an archive, but that collecting all the data that belongs in such an archive of an specific user (and that user alone) can easily be a very complex task for projects of certain size:available manpower ratio, to the point that showing a query to a relational database with a well defined schema as an example strikes me either as ignorance of the state of real world software development or a gargantuan middle finger.

> literally all of my experience has been that securing data is a much harder challenge than any other part of a web facing system.

Depending on the project that can easily be the case. There's of course the fact that no one can really claim all their stored data is safe from malicious actors, just reasonably secure according to their knowledge and what they're aware their software does; so comparing its difficulty to other things seems overly simplistic.

And sure, there's a lot of things that will be harder than an archival feature regardless of the data storage mess a project may be in, but it does not diminish the work required to implement archival on many of those.

> Also, the thing that everyone seems he’ll bent on ignoring: you do not need an archive mechanism if you do not store data

Congratulations if you happened to store absolutely no PII when building your product. You not only have the luxury of being able to provide any value at all without data, you happened to not store things that a lot of people often don't consider PII but that the GDPR does such as IP addresses.

> And given we’ve known gdpr has been coming for at least a year - aside from companies that tried to bribe it away I guess - new projects should have there data set up so that archiving isn’t a monumentally challenging task.

Can we really pretend with a straight face that the overwhelmingly massive cost of changing legacy software can be handwaved away and that all new projects are developed by people that not only are aware of the GDPR (that's an absurdly minuscule amount of all software developers) but that they are competent enough to fully comply with everything in it? I've worked on HIPAA-compliant software, I've seen people that have been working for years in the industry (both health and software) screwing up and/or making extremely close calls. This is not "escape user input in SQL calls", this is a sizeable piece of regulation without a clear course of action for compliance that will fall on the laps of developers of all skills around the world.

Re: GDPR for side-projects? Blocking all EU traffic with Nginx in 3 simple steps

#47
post #10

Earlier quoted context omitted.

those interpretations are wrong. but even so, blocking eu traffic by IP isn’t sufficient.

> those interpretations are wrong. Source?

Not from a regulator, but: https://www.linkedin.com/pulse/gdpr-does-apply-eu-citizens-g...

Re: GDPR for side-projects? Blocking all EU traffic with Nginx in 3 simple steps

#48

Earlier quoted context omitted.

https://gdpr-info.eu/art-83-gdpr/ The wording says fines "up to 20,000,000 Euros" "up to" usually implies a minimum, not a maximum.

> "up to" usually implies a minimum, not a maximum. “Up to” literally means a maximum.

Errr...I typoed my previous message and accidentally flipped them.

The previous commenter said the fine was a 20m "minimum" fine. The GDPR text says it's "up to" 20m. I meant to say that that means it's a maximum.

Re: GDPR for side-projects? Blocking all EU traffic with Nginx in 3 simple steps

#49

This seems to be flawed logic, many EU devices have IP addresses from non EU address blocks. Assuming there is any significant adoption of your proposed solution to avoid GDPR rules the likelyhood is EU citizens will use VPN or Proxy services to bypass the restrictions. I don’t think the use of a VPN would remove the GDPR obligations on the data controller or data processor.

It pretty much does. Sites are not automatically subject to the GDPR, even if they happen to be accessible, there must be some evidence that they intend to be used by users in the EU. Blocking it seems pretty good evidence that they don't.

See https://gdpr-info.eu/recitals/no-23/

Re: GDPR for side-projects? Blocking all EU traffic with Nginx in 3 simple steps

#50
post #10

Earlier quoted context omitted.

those interpretations are wrong. but even so, blocking eu traffic by IP isn’t sufficient.

> those interpretations are wrong. Source?

Not a lawyer myself, but according to the regulation (https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...): "In order to ensure that natural persons are not deprived of the protection to which they are entitled under this Regulation, the processing of personal data of data subjects who are in the Union by a controller or a processor not established in the Union should be subject to this Regulation where the processing activities are related to offering goods or services to such data subjects irrespective of whether connected to a payment"

So if the users are in the Union and you're not, you're still on the hook. If the users aren't in the Union, you're free and clear.

Also applies to EEA countries like Norway and Lichtenstein btw (source: am currently working on GDPR compliance in Norway).

Post reply on HN