As a user, I think GDPR is great, tracking is pretty much getting out of hand. But as a web tinkerer I wonder how do you get your side projects compliant. Where do you start?
I'm sure I'll be shot by HN for this, but I'm not bothering. If a side project starts to gain traction then I'll look in to it, but if it's a small web app with a handful of users then sod it.
While I understand the sentiment this might be risky. Creating the required documentation after the fact should your project take off might not be possible in every case.
However, the rules are vague enough to be interpreted in other ways as well. If some authority decides to make an example of pesky local startups for whatever reason there is little that prevents them from doing so. Remember, both the actual implementation and the enforcement of the regulation lies with the EU member countries, which even might decide to further devolve that responsibility to a local level.
Moreover, in the past similar regulations such as the legal notice requirement for websites in some EU member countries were abused by shady lawyers who specifically target small business that supposedly don't comply with these rules.
GDPR requires companies to use “state-of-the-art measures” to protect personal data, which is intentionally vague because the state of the art obviously changes over time.
However, who will decide what the state of the art actually is at any given time? Politicians, lawyers, competitors, actual IT experts? The latter don’t commonly work for either EU or local authorities.
Because the laws are implemented by each EU member state that state of the art might even differ depending on whether you’re located in, say, France or Germany.
I wouldn’t bother about documentation, but I would bother about thinking about the basics: do I need all this personal information? On what legitame basis am I collecting it? Am I storing it safely? Do I explain to people clearly how I’m using it, how they can see it, amend it or delete it?
Get the basics down, the documentation can follow. Get the basics wrong and it becomes painful.
I agree in that the major benefit of GDPR for small companies is that you have to review and perhaps revise your processes accordingly.
However, the documentation still is required. You can create some of that later or just in case you're requested to do so but as soon as third parties (i.e. data processors) are involved that might not be possible anymore.
At the very least you'll be very busy for a few days because such requests by relevant authorities will come attached with a somewhat tight deadline ("Please supply these documents within 2 weeks or else ...").
That's not correct. As soon as you want to do business with someone currently located in the EU (doesn't even have to be an EU citizen), GDPR applies, no matter where your company is located.
1. Stop collecting any data you don't need. If you don't collect it, it's not an issue!
2. Have a way for users to access their data or request it be deleted. This can be a manual process.
3. Make sure you gain explicit consent for any data you capture from users, and explain why you are using it.
4. Make sure any data you capture is stored securely using industry best practices.
5. Put a retention policy in place for backups and logs – for example, delete them after 30 days.
That's basically it. It's more complex if you have a product that needs to store lots of data to function, or if you have a sprawling set of databases, or if you have some kind of un-deletable storage. But in general, you only need to do the sort of things that you should really already be doing if you use personal data.
And bear in mind that the goal of GDPR is not to fleece companies for fines, but to achieve compliance with the rules. If you do something wrong but act in good faith, you can expect a letter from whichever SA is coming after you. But you're not going to see a €20m fine any time soon.
> Stop collecting any data you don't need. If you don't collect it, it's not an issue!
That's trickier than it sounds.
If you embed a copy of jQuery on your page hosted by a CDN, you're collecting and sending personal data to the CDN. Do you have consent for that?
Same with web fonts, icon fonts, javascript libraries, social media follow/share buttons, analytics tags, etc you embed in the tags.
Every time your page is loaded, you're sending personal data to all those third parties, most of them not even located in the EU, which means you're sharing with a third party and doing a cross-border transfer.
You need more than just consent to do that, they're sub-processors for you, and you likely need signed Data Processing Addendums with each of those companies, and they need to have adequate protections for cross-border data transfers, like participation in the EU-US Privacy Shield Framework. Have you signed those agreements?
You can easily be sharing more data than you meant to, too. Let's say you send a newsletter for your website and you host a copy of phpList or similar software to manage and send it. In each mail you send out, you include an unsubscribe link, which has the address to unsubscribe embedded in the link.
When someone clicks that link, their email address will be part of the HTTP referrer header sent to all those third party scripts on your page. Now you're transferring email addresses to a half dozen third parties with no legitimate business reason to do so. Do you have consent to do that?
> If you embed a copy of jQuery on your page hosted by a CDN, you're collecting and sending personal data to the CDN. Do you have consent for that?
You're not collecting anything there, so it's nothing to do with the GDPR - it might impact the CDN, but it's unlikely without them tying your IP to other personally identifying information. Analytics would be, because that's personal data you are collecting, so you'd need to ask permission for that.
I try not to be an asshole with user’s data and it worked out great for me even before GDPR.
I haven’t actually read the regulation and couldn’t care less if I comply (I’m sure there is like 10% of it that I might not comply with), but my point is that nobody ever complained - I give users an easy way to nuke all their data (actual delete, not pretending to delete), I don’t share their data with anyone, no analytics/tracking/advertising and problem solved.
I have enough on my plate working on GDPR for the sites I pay my bills with, so I shut down almost all of my side projects (and one business with a few customers) to avoid having to worry about them.
Some people here have mentioned ignoring it completely in the short term. While I wouldn't recommend this, for a small, personal, non-profit side-project, it is worth mentioning that lot of the checklists and advice out there are:
1. aimed at, at the very least, medium-sized for-profit businesses, and as such include requirements that explicitly don't apply to very small projects
2. very often are trying to sell you something (consulting services, compliance audits, training, etc.) and as such are motivated to make GDPR sound as scary as possible.
There is a little more to it than this, but, my advice would be to just be mindful of any info you collect on users.
If you are worried about it, you can focus on projects that are open-access or don't necessarily involve accounts and login, but if you are implementing auth, just note what the auth collects, and be careful with it, both in terms of consent and securiy.
Don't give it to 3rd-parties (the easiest way to do this is doing things like sending userIds to Google Analytics in custom JS events). Consider whether your small side-project really needs Google Analytics (logging, crash analytics is good for debugging issues, but behavioural analytics is moving towards building a business, imo).
Note: I'm not implying side-projects shouldn't be moving toward building a business, but I'm just making the point that if that is your intent, you should be spending a little bit more time considering user privacy and compliance. And getting proper advice about it. You don't even need a DPO for <250 employees, so this really isn't that burdensome.
Can someone clarify what exactly is the legal liability that comes from GDPR?
My very basic understanding is that countries set up SAs (supervisory authorities) to deal with complaints, and have the legal power to sanction and so forth.
So is it only the SA that can take action against you? If someone wanted to harass you, must they complain through the SA, or can they bring a civil suit based on the GDPR?
I'm not clear on how to revoke PII from distributed systems, like git, when mischievous peers can copy data or ignore changes as they wish. Likewise for any other distributed information storage.
All the most important data that shouldn't be for my eyes -- is 256-bit encrypted as it gets entered into any database. All passwords and most user-inputted data is encrypted. Stripe takes care of the payment information which I don't store, but I do keep the expiration date in my database which usually cannot be used to identify anything. Definitely trying to be more GDPR-compliant as I take privacy and security very seriously. Wouldn't want my data exposed if I was using someone else's product and that is how I try to think when developing and encrypting the data.
What's interesting is that I've had to meet many of those already for California's COPPA and previous privacy laws, so I'm quite confused at why people are acting like this is all brand new and never existed before...
As an aside that checklist is misleading. Some of the requirements they list expressly don't apply to small businesses, for example you don't need a DPO unless you're over 250 employees.
Are you a large scale data processor of special categories of data as defined in Article 9? That includes data that can be used to determine racial or ethnic origin, health data, and data about sexual activity and orientation.
Large scale is helpfully not defined anywhere.
So if you run a site around a health condition or that lets
people specify their sexual orientation some place you might need a DPO.
I don't, but I've never kept personal information. As someone with a background in the security and finance industry. I don't want that burden. If you don't have it, you don't have to deal with it. So if you have a side project, why would you collect personal info?
Many side projects involve people signing up for something, like an account or an email list. A username is personal info. An email address is personal info. An IP address is personal info. Your side project can't be much more than static webpages without analytics to avoid collecting "personal data" as defined by this regulation.
It's my understanding that an IP address is not personal info and that nobody can, say, make a GDPR request for information associated with an IP address. An IP address is not personally identifiable information.
It’s a little more subtle than that AIUI - they’re only personal if you have a way of linking them to a user. E.g. if someone logs in with an email and you record that with the IP, or if you’re an ISP. I don’t think the IP is personal if you are just hosting a static site say.
If you have a project that doesn't allow users to enter any kind of information but simply displays ads (via Adsense), is that in scope for GDPR or is a proper Privacy Policy enough?
Do you set cookies that are not functionally required for the site to operate? Have to allow opt-in and opt-out of those cookies. Adsense cookies almost certainly fall into this bucket.
Do you set cookies that are required? Need to identify them and inform the user.
Server logs? You probably have ip addresses. Despite what us nerds think the EU considers them personal data.
Thanks for the answer. The only cookies are adsense and those are functionally required to run the site (as it's the only revenue stream). I already use a cookie banner for that.
I run the site behind cloudflare and don't store X-Forwarded-For IP, the analytics software I use immediately anonymizes them before storing them. So I should be fine I hope.
Functional for GDPR does not take into account revenue from my understanding. You’d need a fallback ad solution that doesn’t rely on cookie targeting for users who don’t opt in.
Cold emails to EU region recipients aren’t allowed unless they give you consent to receive your email (you as a company or marketer can do this by mentioning or using check-boxes in the web form’s popup template)
Email list needs to be updated - Only consented customer data needs to be stored, and erase the other unless you want a fine of 20 million euros or so. (remove data of those who have unsubscribed to your service immediately).
Data erasure - Remove data of those who have unsubscribed to your service.
Check for the Unsubscribe button everywhere - It’s mandatory that each and every mail of yours needs to contain an unsubscribe button with updated privacy policy given below.
Update the privacy policy & terms of service - these need to contain what and how you are going to use the user’s data. For more info, read from the links given below in this answer.
Double opt-in- for both entry and exit needs to be mentioned.
Permission for profiling - Sales people can get prospective customer’s data through gated content(whitepapers, e-books) etc and they shouldn’t get this data from any other source like email hunters etc. (without their consent you can’t even breathe!)
Employee data handling - You need to mention how and where is the data used and stored and for which purpose too. If you are using the data for multiple purposes, then you need to mention each purpose every time.
Referral Program - You can’t process the referral email ids/data gained through offers/discounts etc. Yes, even they have to be GDPR compliant.
Data usage policy - already mentioned in this answer(this is just to remind its importance in this context)
Right to forget - option to be provided if the user wants you to erase(forget) their data from your databases.
Usage of cookies - to track email opens etc you need to mention you are using cookies to the user.
Some notes you would want to keep for GDPR compliance: