The issue with google fonts is the CDN tracking I believe, not the license or the font itself.

If you need a google (or other) fonts, do self hosting. Simplest way is to build them into your site as a dependency... npm @fontsource for individual fonts is great for this [0] This is also better in terms of HTTPS overhead, and the process of self hosting is good for font file weight awareness due to the affect on your build size, especially when using lots of styles.

Same principle for any other CDNs you use, they all have the potential to track. The risk benefit of CDNs is being reversed, public CDNs disadvantages are: increased HTTPS overhead, increases points of failure, increased risk of users getting arbitrarily blocked by CDN provider IP blacklists, increased risk of tracking. Benefits: small developer convenience, potential advantage of caching (unlikely these days, and unlikely to outweigh the cost of HTTPS overhead especially in terms of total latency).

[0] https://github.com/fontsource/fontsource

Indeed, the issue with Google Fonts (and Google Analytics) is how they track users. You need explicit consent for your visitors.

In reality, I'd suggest you avoid both services and go for simpler choices. E.g.: fontsource.org for fonts, and maybe something like plausible if you really need analytics.

I looked into this issue over the last weeks and made a list of other solo founders and how they handle it.

You can find many, many of them when you search Twitter for "buildinpublic".

The sad truth is that most successful solo founders these days:

1) Make it very hard to figure out where the service they provide is located.

2) When you find out, it is usually registered in a country outside of the EU. Crunchbase often helps to find the location.

Apart from the USA, Singapore and Colombia seem to be popular choices among solo founders who know what they do:

https://www.crunchbase.com/organization/nomad-list

https://openstartup.tm/remote%20ok

What the discussion about GDPR usually misses is that GDPR does not only apply to Google Analytics and Google Fonts.

A web business needs a hosting solution, a CDN, a payment processor, an email solution, an A/B testing solution, etc etc etc.

If you try to handle all that inside of the EU, you are cut off from all the good tools that startups usually use.

I‘m pretty sure that’s not accurate. Not sure where they scraped that from but I think I remember it being incorporated in Singapore. Which makes a lot more sense if you follow where Pieter is usually located.

Do you confuse Nomadlist with RemoteOK?

RemoteOK is in Singapore.

I added it to the comment now.

What's your source?

If you're servicing the EU you need to take the GDPR into account, so I'm not sure I understand what benefit it gives you to be outside the EU unless you have a service that can refuse to serve an economically rich area of the world?

That is the theory, but not how the web works in reality.

SaaS projects usually service the whole world. I have not found a single solo founder who does that in a way that is compatible with the GDPR.

If the EU would try to enforce the GDPR worldwide, it would mean the EU gets cut off from 99% of the internet. Then Europeans can only use giants like Google and Facebook. Because smaller players can not duplicate all of their infrastructure using tools based in the EU.

It won't happen. It would be as if the EU sanctions itself into stone age. Imagine the physical industry would be told that it can only use parts made in the EU from now on.

How about "Don't use Google Analytics and Google Fonts"?

Like, at all?

There are self-hosted alternatives. Plausible Analytics is good. Find web fonts that you can host yourself.

Not only you will reduce your risk exposure, you'll see that it is not that difficult to get rid of Google.

Your users, European or not, will thank you later.

Although you're right, there are alternatives to Google Analytics, you really should work on your messaging. Snark isn't necessary when someone is (seemingly) genuinely asking for help.

In any case, for the OP I would also recommend to use an alternative. I don't know about Plausible Analytics but I have heard good things about Simple Analytics [1]. I'm not sure about Google Fonts.

In terms of GDPR compliance, just keep in mind that you can't hide this stuff behind T&C, you need the user's explicit consent, and it needs to be timely and you can't forbid them from accessing the service if they decline consent. I would also consider using a service that handles GDPR/cookie consent collection for you so you don't need to keep it up to date as time goes on and you can focus on your business instead.

1: https://www.simpleanalytics.com

There was no snark. It was just the shortest way that I could find to convey the message that "the best way to comply with laws that govern data collection and data processing is by not collecting data and not use third-party services that collect user data in the first place.

It's the same thing with the cookie-banner law, by the way. I am running a service in Europe and I can proudly say that I have no cookie banner on my site. You know why? Because I don't have any tracking cookies on my site in the first place.

Maybe we have different definitions of snark then. When I read

> How about "Don't use Google Analytics and Google Fonts"?

> Like, at all?

It reads quite snarky to me and you could have conveyed your point differently.

I don't disagree with your points and I agree that the OP should ideally not use Google Analytics, but I do think there are better ways to express this.

> I am running a service in Europe and I can proudly say that I have no cookie banner on my site. You know why? Because I don't have any tracking cookies on my site in the first place.

Exactly! I do the same thing and as strange as it might sound: I'm also proud on the fact that I don't serve cookie banners. As in, literally experiencing the feeling of pride for something others might find banal and innocent.

Agree that GP's tone was off, but it kinda rubbed me the wrong way too that OP said the GDPR got worse and then goes ahead ans mentions embedding Google fonts as the first thing. Like you can't even be arsed to self-host static assets and rather expose your visitors/customers to the almighty spying kraken. So while I'm sick and tired of cookie banners, I have little sympathy in this specific case.

I agree. I did this for my Website Builder SaaS. I had this during development: ah yeah, almost forgot, I need analytics or stats of some sort, but I don't want Google. Eventually I ended up writing my own statistics code which works pretty good and doesn't track visitors, but I also heard good stuff about Simple Analytics if you need a plug-n-play solution for your website quickly.

> increase your risk exposure.

How? https://plausible.io/data-policy.

OP already said he is hosting the servers in the EU, so he is in the same situation as plausible's SaaS offering.

You can use privacy-focused drop-in alternatives to Google Analytics and Google Fonts:

• https://www.growthfyi.com/custom-ga

• https://fonts.bunny.net/

I personally choose to use Plausible Analytics with a custom domain [0] and the default "System Font Stack" [1], which means my sites load fast, don't have a flash of unstyled text, and my analytics script doesn't get blocked by ad blockers.

[0] https://plausible.io/docs/proxy/introduction

[1] https://css-tricks.com/snippets/css/system-font-stack/

I don't see a difference with fonts.bunny.net and Google Fonts? From the perspective of GDPR, they still both receive your IPA and browser info, which was what made it illegal to use G fonts.

You can download fonts from both of them and host them on your own server to avoid processing that information.

I'm all for privacy and such (I don't use Google Fonts or tracking ads/analytics), but I don't really see a difference in here. According to G Fonts privacy policy, they don't store any PII. (This also reminds me that based on what I understand of the ruling, almost any 3rd party requests for assets should be blocked? Including G fonts, bunny fonts and jsdelivr)

> According to G Fonts privacy policy, they don't store any PII.

Do they log IP addresses? That would be enough as those count as PII. Maybe bunny.net has logs disabled and that's what makes them stand out.

But especially with fonts it's just so easy to self-host them that it's kind of a no-brainer.

> almost any 3rd party requests for assets should be blocked

That could be a very good practice/state of mind for developing privacy-respecting websites/apps and will save you from stress, before it can happen.

As you have no more advantages due to separated caches from using CDNs for scripts etc., you can self-host those, too. Saves on DNS lookups and you have control over the caching-times, too.

I'd try to run as much as possible from the same domain.

The GDPR also has the concept of data minimization, which I believe would apply in the case where you're unnecessarily sharing IP addresses with a third-party (regardless of whether they ultimately log them) for something that can trivially be done in-house.

There's zero benefit to using a CDN for fonts - browsers have long ago started partitioning caches per origin anyway, so you don't even get a performance benefit. Just put the fonts where you put the rest of your static files and you're good to go.

Court rulings in the EU have found that US law is not compatible with GDPR: US lets law enforcement have unfettered access to the data of EU residents, with no restrictions or redress mechanisms that satisfy the EU court.

This means that sending data from the EU to a US company is almost always a GDPR violation. There are a few nuances to this which are very important.

- The US CLOUD Act gives US law enforcement access to data stored in other jurisdictions. This means that locating the servers in the EU is not sufficient. Nor is operating via an EU subsidiaries.

- IP address counts as personal data, as does pseudonymized identifiers.

The two of these combined mean that GDPR forbids you from having your users connect to Google servers. This is why Google Fonts is straight forbidden, and why most installations of Google Analytics are forbidden. Also the use of basically anything from Google, Azure, AWS, Oracle, Facebook, Akamai, etc except when routed through an EU proxy which obscures the user's original IP address.

In case it's not clear, this "sending data to the US" thing also means storing data in the US (because you have to send it there).

The FAQ for the Schrems II ruling makes it clear that SCCs and BCRs aren't a basis for sending data to the US (BCRs are still valid for other regions that haven't received an unfavorable adequacy decision).

https://edpb.europa.eu/sites/default/files/files/file1/20200...

As far as I can tell, nobody's enforcing the rules about where you store your data right now (as distinct from sending user data to 3rd parties, like the Google Fonts thing).

> sending data from the EU to a US company

1. not data. Personal Data. of course if you know you know, but threads like these are rife with non informed readers.

2. nothing to do with the geo residency of the company. it's about sending the data to the US (or most non-EU countries). Even an EU company can't send the data to the US absent various agreements.

3.You are way overstating the violation part. It's very easy to be able to send the data and be compliant.

> not data. Personal Data.

That's fair. Although a lot of data can become personal data if you're not careful.

> it's about sending the data to the US (or most non-EU countries)

Disagree, the United States is in a worse condition that most other countries. Even in countries without an adequacy decision, you can usually satisfy GDPR by incorporating SCCs into your contract. A US company cannot comply with GDPR because they are beholden to US laws which require them to violate the terms of any contracts they sign protecting the data privacy of their users (according to the CJEU).

> It's very easy to be able to send the data and be compliant

Probably depends on your context. Something like, say, sending a pile of data over to GCP to train an ML model on? Probably easy to comply. Front-end dev work? Anything that makes the user's device connect to a Google URL is forbidden, since that's sending personal data (IP Address). The higher-level your framework, the more care it takes to avoid some dependency doing this behind your back.

This is my understanding too. Meaning, there's a huge backlog of compliance issues at so, so many companies.

Why do people even use Google Fonts? Just put the woff2 (and the other formats) files with your static assets and if necessary configure the mimetype for your webserver and your done.

Self-host matomo, it is super easy to manage.

You can't easily track every mouse movement of every user but maybe it's for the best

Got a relevant question myself:

What bothers me the most for solo founders with GDPR is that you can't analyse individual user journeys without some kind of consent. I don't care who you are, but I care how you use my product so I can improve it. Aggregated / backend analytics will give me only the most basic insights.

Am I right in that? Is it possible to work around that? I don't track to sell or analyse personal data. I just want to understand how you use my product better.

Even with self hosted stuff you need a consent for tracking if I understand it correctly.

If you track Personally Identifable Information, such as IP addresses or emails, yes. If you track completely anonymously, then no. Of course, this limits what kind of anylses you can do (e.g. cohort-based analyses will be impossible). But I would also wager that you don't really need that, especially if you're a small startup. You can have a look at my open-source, self-hostable Mixpanel alternative if you are interested: https://github.com/shafy/fugu

IANAL, but I think you can work around this by running Matomo locally and activate the options to anonymize/scramble IPs directly at the beginning.

If you don't use IP addresses or can't come back from a user profile to an IP address, you should be fine with tracking the user journey. But be careful with tracking actions like "placed an order" and linking to that order then. That link would create an option to identify a specific user and could therefore be a problem.

Anonymizing IP addresses wouldn't do anything it you still collect other data that is unique enough, such as a browser user agent or session ID. The whole thing you're trying to do requires a persistent identifier (to track the user across their browsing session) and since analytics is not functionally-necessary, it will require consent.

The only analytics you can do without consent is effectively a stateless hit counter that increases on every operation. For a lot of features, it's more than enough and saves you from all these headaches.

You need consent to read or write data from the user's computer except that which is strictly necessary for providing the service provided. This torpedoes analytics which identify users by setting their own pseudonymous identifier.

There's a bit more leeway to take data you already need to use for your service, and using it for a secondary purpose like analytics. So things like analyzing logs, including making use of a user identifier which you had to collect and process for other reasons. There are still restrictions, but much less severe than "strict consent." You can use "Legitimate Interest," legitimately.

Note that reading cookies is covered by the ePrivacy Directive, while processing personal data is covered by GDPR (reading cookies with personal data is covered by both). This is the source of many issues. In this case, it means collection is severely restricted (ePD) but use afterwards is less-restricted (GDPR).

What you're asking can't be done without tracking an individual in some way.

Imagine you have a physical store, and want to track which clients come back, what products they look at, and in which aisles they stop.

You could take their photo to recognise them when they come back, that's obviously not privacy-respecting at all.

What Google Analytics does is given them a badge with a unique id the first time they walk in, and expect that person to show that unique id on each subsequent visit. And also expect them to show that same badge on every other store (website) they visit. Even in places where they're registered (e.g.: GMail). It's inevitable that by tracking users like that you can eventually tie it to their real life identity, and also produce a really detailed record of all their activities.

This idea has become pretty common somehow: "I just want to see a single user's journey and don't care about who they are". But imagine how you'd do that on a physical store (including with clients that walk out and in again), and if there's ANY way that it wouldn't be super creepy to customers.

So ask your users for consent. It really is that simple.

A lot of the GDPR tracking stuff is only applicable for anonymous users. Once someone creates an account and accepts the ToS, it's a different relationship. Tracking is fine, GDPR becomes more concerned with data safety.

This is why freemium products are so important. In this future, your marketing should be a sledgehammer with one focus - get people to create accounts. Once people have accounts, then you can do all sorts of analysis to find your product's value prop/customer journey mapping/etc.

Sorry but I don't see how ToS can override GDPR?

GDPR suggests that you can't make non-essential data processing a requirement for using the service, so it seems to me that ToS that force you to accept tracking would still not be compliant.

A course platform you say? For reasons, I am very familiar with this.

Aside from fonts and CDNs pointed out already in other comments, there is also actual content:

How will you serve videos for example? You should look for a GDPR compliant option for that as well. It may exist, or you can self-host videos up to some point. (It is possible, done that before and it worked well.)

Does your platform offer mentoring? How will course participants talk to mentors? Look for a GDPR compliant option here. Don't use services of Google, MS or others that just suck. Probably look for something like Jitsi Meet hosting, or get capable engineer to set that up on your own infrastructure.

How will people inside your company communicate? Look for options for that. Zulip is easy to self-host for example.

That social icon on your website? It better not be loaded directly from FB, insta and the like!

You want to know what visitors do on your website? Well, self-host a matomo or similar. Don't do the usual reach for Google Shnanalytics.

Don't employ dark patterns in your cookie consent popup. Remember: Rejecting tracking and cookies must not take any longer than accepting it. Highly suggestive colors of the buttons are also a no-go. Be honest.

In general, if anyone suggests using any Google services or MS services, look for other options to avoid trouble and pain later. If you cannot do so now, keep book about all the things you still need to fix, to become actually GDPR compliant.

If you can't afford a lawyer, pay for a service like OneTrust or Ketch. You will have so much peace of mind that you are following some sort of best practice. And there will be safety in numbers.

Setting up solid required legal docs as you did is a good first step. In general, don't save data about your users. If you need to, minimize the amount. Don't use non-essential cookie, this allows comes with the benefit of not needing to show an annoying a cookie banner.

As an alternative to Google Analytics, I recommend Plausible. If you need more event-based tracking (like Mixpanel), have a look at my app Fugu (https://github.com/shafy/fugu). It doesn't track unique users and is therefore compliant with GDPR. It's hosted in Germany, and you can self host it for free if you want (it's open-source).

This is not very clear yet, but it might well be possible that using US companies as hosting providers might also become illegal under GDPR, even you use their EU data center. This is because the US government can access all US companies customer data, even if it's not hosted in the US. There are already precendences where this was ruled by a court. So, to be safe, I would also pick a EU provider, such as Hetzner, Clever Cloud or Scalingo.

The idea behind/the backbone of the GDPR is: Whenever you want to process personal information, you'll need the consent of your users and protect the data accordingly.

It's easy as that. You can absolutely use ANY tool or service you want (really), but if it processes personal information (and even IPs count as that) you'll need to ask for consent and inform the user what data is processed and where and how it is processed and how you plan on protecting that data.

That has to happen BEFORE anything is processed if it's not technically ultimately necessary. Hint: Passing user and browser information to Google because your site looks nicer with an external font is technically not necessary. ;-)

With these requirements in mind, you'll find that it's easier to self-host your fonts, run a local Matomo instance with high privacy settings for analytics etc.

It sure is a different approach on "how to do internet", but you'll get the hang of it and it's not that hard after all.

Also: If you don't use any external services that process private information, you don't need a cookie notice after all. ;-)

> A user told me they know of people who got fined because of this.

Yes, some people in Germany are currently running around and try to fine websites that use Google Fonts. It works and is legal, but the morality... That won't stop such people...

Self-hosting fonts can easily help you with that, even Google has a page on that: https://fonts.google.com/knowledge/using_type/self_hosting_w...

The ambition is cool, but the reality of a sweeping sector-wide law with extraterritoriality is it just makes the lawyers rich. No sane business is running a Matomo instance with high privacy settings and hoping for the best.

The objective of the law is to put an end to the current "Wild West" attitude when it comes to data privacy, and the only reason it hasn't (yet?) had the desired effects is because enforcement is significantly lacking, so you're seeing the downsides without significant upsides.

There is tremendous value in having the GDPR enforced properly though. Imagine a world where you can actually talk to someone or buy something or without Google or Facebook knowing about it, webpages no longer embedding dozens of third-party trackers, "data brokers" going out of business, etc.

IMO it's actually quite insane that we let the situation deteriorate so badly that something like the GDPR was needed, both from a "do the right thing" perspective (smearing your PII over tons of third-parties with dubious or outright malicious business models is a sign of disrespect for your users, not to mention security liability) as well as legal perspective (some countries already had existing legislation around electronic data processing that predates the GDPR).

This thread comes at a fortuitous time: I’m exploring a product idea around making a toolkit for reasoning about how schemas and tables are inter related across an organizations database systems.

The near term is to make it easier for organizations to maintain the various gdpr style mandated user data export and deletion capabilities without it getting in the way of / blocked by continuously evolving software systems efforts.

The same sort of tooling could also be used to help data analysis folks navigate the huge sea of tables in various datalake setups organizations are so eager to setup (it can be tricky seeeing which things are usefully joinable among many many evolving datasets that might be in that setting.

This of course isn’t really aimed at solo engineer sized application Systems such as the original poster, but is it something folks would find useful?

If I was starting a startup today. I'd probably just block Europe and focus on other markets initially. Loop back on Europe once you have product market fit and the resources to deal with GDPR.

Nice move. You'll save time/money for the future; that's for sure.

Europe is also not a big software market, and they are increasingly protectionist.

Also, from personal experience, European business partners are much nastier/cutthroat to deal with.

you'd have to block california too because CCPA is essentially the same thing

Or alternatively, think why the GDPR exists and make sure you can deal with privacy concerns from the outset.

European here who honestly agrees with what you're saying but most likely not for the reason you expect. The GDPR may be a bit of a blunt axe but it surely has done a good job of smoking the data parasites out of the woodwork. If whatever business you were to start can not survive without tracking its users without their consent and without giving them the possibility to retract that consent the problem lies with your business plan, not with the EU law which insists on giving users the aforementioned rights.

I'm not going to disagree with that and I'm not opposed to the privacy controls in GDPR. The context here in a solo dev who is dealing with GDPR. When you're trying to get a business off the ground, iterating fast and trying to build a business that can survive to day 2, every single bit of busy work should be avoided. Why reduce your chances of success by chasing a market that takes more work than other markets? The global market without Europe is big enough to support any startup; so long as you build something people want.

> Why reduce your chances of success by chasing a market that takes more work than other markets

That is the same excuse which was - and in IoT-land still is - used to delay thinking about security because it could be bolted on later. The answer to this question is "because if your business ends up successful you will eventually have to implement this functionality so you have to make sure your architecture allows for it". If your "fast iterations" lead to personally identifiable information being scattered all over your system in such a way that removing this for any given user is an onerous task you made the same mistake as those developers of yore - and of now in IoT-land - who assumed everyone who had a 'net connection could be trusted. That was a costly mistake for which we're still paying off the debt.

You don’t need an EU DPO, just an EU representative, according to my reading of it. (At least not under a certain size, which is what I was looking at.) They’re basically a glorified post office box. I used DataRep, which was very reasonably priced.

And what size is that? Do you have a source?

Read the text of the GDPR directly. It’s surprisingly readable, and there’s several well-organized hypertext versions online.

It’s been several years since I read the GDPR, but my recollection is that companies smaller than 150 people, who don’t process “sensitive” data (sexual orientation, etc.) have lighter requirements. Again, read the GDPR itself for details.

No, that's not true at all.

Could you elaborate?

You don't need to hire a separate person as DOO. It's recommended but not mandatory.

Every single official guidance on GDPR that I have seen, such as https://ico.org.uk/for-organisations/guide-to-dp/guide-to-th..., states that I would have conflict of interest serving as DPO because "Basically this means the DPO cannot hold a position within your organization that leads him or her to determine the purposes and the means of the processing of personal data."

The same document specifically points out that as I head marketing, I cannot also the the DPO.

It is recommended, not mandatory. You are a single person company.

Do you think every family run corner shop or plumber or painter in the EU has hired a DPO? No.

I have seen nothing that says it is recommended and not mandatory- do you have a source?

Your own link did, but now the page returns a 404 error.

However, see https://ico.org.uk/for-organisations/guide-to-data-protectio...

> Under the UK GDPR, you must appoint a DPO if:

> - you are a public authority or body (except for courts acting in their judicial capacity);

> - your core activities require large scale, regular and systematic monitoring of individuals (for example, online behaviour tracking); or

> - your core activities consist of large scale processing of special categories of data or data relating to criminal convictions and offences.

It is saying that I MAY not have to appoint a DPO, depending on various criteria... but then when you go to look at what that criteria is, it merely tells you:

--- What does ‘regular and systematic monitoring of data subjects on a large scale’ mean?

There are two key elements to this condition requiring you to appoint a DPO. Although the UK GDPR does not define ‘regular and systematic monitoring’ or ‘large scale’, the Article 29 Working Party (WP29) provided some guidance on these terms in its guidelines on DPOs. WP29 has been replaced by the European Data Protection Board (EDPB) which has endorsed these guidelines. Although these guidelines relate to the EU version of the GDPR, they are also a useful resource for understanding the requirements of the UK GDPR.

‘Regular and systematic’ monitoring of data subjects includes all forms of tracking and profiling, both online and offline. An example of this is for the purposes of behavioural advertising.

When determining if processing is on a large scale, the guidelines say you should take the following factors into consideration:

    the numbers of data subjects concerned;
    the volume of personal data being processed;
    the range of different data items being processed;
    the geographical extent of the activity; and
    the duration or permanence of the processing activity.

---

So neither does this page, nor the law (according to this page itself) or any other guidance I have found, define what "a large scale" means. It gives some really squishy criteria, and then leaves it up to the DPA to fine whoever they want to, because they refuse to define anything in concrete terms. No one except commenters on Hacker News can possibly know whether or not they are in compliance.

That link is about the DPO at EU institutions and bodies. It doesn't apply to your one person startup unless you meet the criteria for needing a DPO.

The UK ICO describes when a company does and doesn't need a DPO, at least with the UK implementation of the GDPR:

https://ico.org.uk/for-organisations/guide-to-data-protectio...

The first question it addresses is "Do we need to appoint a Data Protection Officer?", for which the answer can be "no", depending on your activities and type of organisation.

Roughly, it's a no if you are not a government body and your PII handling is secondary (such as for HR in your startup) rather than a core activity at large scale (such as running a HR service or user-tracking service).

As a startup it is plausible that you are a "yes" if you handle PII as a core activity, for example if you are taking user's PII such as their names, addresses, locations, etc. But even than, you may not be doing so at large enough scale to require a DPO. If you are, though, it's time to hire one, and you're probably at a scale where you can afford to.

Broadly, you could think of a DPO as more like an auditor or independent overseer in a particular area, whose job is to check you are complying. Just like an auditor or security professional, you can hire an external one in to ensure your business is complying and show that you've done so. Larger companies doing large and more intrusive activities need it, the same way as those are the companies which need other forms of auditing and independent oversight.

It's a different function from the DPC (data protection controller), who is in charge of actually processing the PII you hold. See "What are 'controllers' and 'processors'?":

https://ico.org.uk/for-organisations/guide-to-data-protectio...

At a one person startup the DPC is almost certainly you, as you make the decisions on how to process PII, even if you delegate the actual processing sometimes. You have responsibilities as a DPC, but you can do it, and it'll just be one more, among the many duties you have as a director of a one person company. Imho, being a DPC isn't any more onerous than the other duties of a director.

The very document you link to does not say exactly when you have to hire a DPO or not, but it and other documents I have read seem to indicate that if my business is collecting personally information order to provide my service, I need a DPO. There is some question as to scale, but no where is that defined in anything approaching concrete terms. If I have 5 customers and all 5 of them have given me their name, email, and a brief biography that I store for the purposes of providing a my service- at least one guidance document from the the EU states that scale is relative to the size for the business, so I would need a DPO in this case. What about 50, or 500, or 5000? Any number I would pick is arbitrary. What if I collect birthdates or other information that is essentail to my service?

Its easy to say "I'm small and don't need a DPO"... but the law is nothing close to clear on this issue.

And the guidance clearly states that I cannot be the DPO while also holding all the other positions in the company.

"Basically this means the DPO cannot hold a position within your organization that leads him or her to determine the purposes and the means of the processing of personal data."

> As a market, it's not worth the risk until it's worth the legal advice.

i think that is a calculation only op can make. the european union covers over 400 million people. making some early design decisions in what data you collect, how you store it, for a lot of people is an acceptable cost to open up to such a large quantity of people.

in fact, it think advising a founder that is bootstrapping their business that the only "reasonable" course of action is to exclude large swathes of the developed world is frankly, misguided.

Design decisions don’t make you compliant, you have to hire experts whose job is to convince regulators you are remaining compliant over time.

> making some early design decisions in what data you collect, how you store it

This is exactly the kind of thing I'm talking about. "How you store it" very well may include "on any cloud server owned by a US company," including AWS, Google, and Azure. That's a pretty big issue for a solo founder with no legal advice beyond GDPR wishcasting on HN.

Sorry, not an anwser, but curious if others can relate.

Is there any gotcha related to Admob/GDPR in 2022?

What do you mean by that?

I think the truth is that we don't know. There have been rulings that seem to go as far as saying that an American company can be compelled by the US government to share information against GDPR rules so no American company can ever be compliant - not even if they set up an EU subsidiary which nominally controls the data and all the data is hosted in the EU because that American company could simply override their EU subsidiary. Even if you're hosting in the EU, is the company an American one that might be compelled to use their control of the servers to hand over your data?

Yes, if you're using Google Analytics and Google Fonts, you'll need to get permission from each user before loading any of that. Those services are used to track users around the internet and for marketing/ad purposes within Google.

I actually think it's near impossible to make something "GDPR compliant." For example, let's say that you try to do all the right things - trying to be as strict as possible. You put up a cookie banner that has both "accept" and "deny". Molly presses "accept". Two days later, Jane is using the same computer. Jane didn't accept. You're now tracking Jane who did not consent.

I think showing a good-faith approach and genuine caring about user data will go a long way with regulators (but IANAL so don't take that as advice). Things like Google Fonts/Analytics are easy targets because we know they leak data to Google. If you're hosting a MySQL database on Azure, theoretically the US government could get a search warrant and serve it to Microsoft and get access to your database. I personally think regulators should be focusing on the rampant bad-faith compliance targets rather than "well, technically maybe the US government could do X." Websites are putting up "Accept all" and "Manage choices" buttons where you'd have to spend an hour opting out. C'mon, that shows such a blatant disregard for user's rights. Having a database hosted on Azure that the US government could technically get a warrant to search your database and because Microsoft is a US company they'd have to give them access is certainly something that could happen, but such an unlikely vector compared to someone embedding GIPHY and now Facebook knows all the page views.

Realistically, if the EU pushes too far, the US is going to say "you can't ban US companies from the internet in Europe." If the EU seriously said that you couldn't use Azure because Microsoft is a US company (or any other US company), I'm guessing the US would take it to the WTO (World Trade Organization) and it'd likely be considered in violation of trade treaties. There's a certain amount of local rules and regulations you can put in place and some might have a protectionist impact on foreigners, but outright banning foreign companies wouldn't fly.

Plus, the US's reach often extends to EU companies. Hetzner and OVH both have a US presence. I don't know, but I'd guess that people on-call in the US can access a lot of their EU presence. Why wake up someone in Germany or France at 3am when it's 9pm in the US? The US presents their US subsidiary (or US employees) with a warrant and the warrant expressly forbids them from disclosing to anyone so the European parent doesn't even know to restrict access from their US employees, etc. At some point, one needs to be realistic about the threat vectors.

On a practical level, stop using third party services where you (and your users) are the product. Google Fonts is free because you're paying for it with user data. An Azure-hosted database costs money because Microsoft doesn't get access to what you're storing in that database. Do get DPA agreements from your third parties and give them a look over to make sure they seem reasonable. Do genuinely care about your users' data. That does take a bit of effort (not just good feelings). For example, you need to know that Google Analytics feeds the data into Google's larger marketing machine rather than being private storage for you.

On perhaps the most practical level, check what third-party stuff you're serving on your site - javascript, images, fonts, etc. People don't know where your database is stored unless you tell them. They can easily see that you're loading a Facebook tracking pixel since that's in the page you're serving to them. That gives them an easy way to see if going to your website is loading something that's tracking them without their consent - even if you're not wanting that third party to do that tracking. Your users complained to you about the things they could see. I think those are often the most likely ways that GDPR violations will happen too - companies haven't really built their businesses around backend data stealing (err, sharing) because they'd need to make an SDK for Java, C#, PHP, Python, Ruby, etc. JavaScript lets them write once and even push updates without you needing to update dependencies. Focus on the front-end stuff that users can see - both because it's the most likely place you'll have compliance issues and because it's probably the most likely place you'll be caught with compliance issues.

Again, I am not a lawyer and none of this is advice.

Someone should build GDPR-compliance-as-a-service.

There are already a few services. OneTrust, Ketch, a few more as well.

None of those give you compliance?

A consent popup that makes it harder to decline than to accept is not compliant, nor one that merely cares about cookies/local storage while still loading third-party scripts and leaking your IP address & browser fingerprint.

A compliant consent flow would require explicit consent before loading any non-essential third-party scripts, but I'm not aware of any mainstream solution that does this, primarily because an actually compliant solution would put certain employees and maybe even entire companies out of business, thus pseudo-compliance is preferred over actual compliance.

Furthermore, even if you do actually handle tracking consent properly, it is only part of your GDPR compliance approach. It does't matter if your website tracking is compliant if your backend then uses the data without appropriate legal basis.

GDPR compliance is trivial if you build it from the start. Those who can comply can easily do so themselves.

The problem is that a lot of businesses (or careers) just won't be possible without breaching the GDPR, and that's not something a "compliance-as-a-service" company would fix. A honest company would tell you to close your business or severely downsize your marketing team, a dishonest one would just take your money and give you a false sense of security.

We are building one such service and I agree (to name a few services doing GDPRaaS : soveren.io, ethyca.com, securiti.ai, datagrail.com, alias.dev) .this is so much needed as there is almost no legally valid answer on the whole comment section! I started to write an article on all the points above… should get back in 2 hours and post it here

In bullet points : - GDPR is a risk management policy about personal data protection more than a privacy regulation

- for any personal data (PII) all companies must declare the following :

  - purpose of the collection and the treatment of the specific data

  — legal base of the treatment (6 available, they are the field card in Magic the gathering, they define a context of what is possible to do)

  - data category (what type of data you are collecting i.e if you declare collecting delivery shipping information for a purpose, you limit yourself to data that correspond to that category )

  - data retention duration (how long you declare storing the data in production and then in archive)

  - list of recipients (all the 3rd party companies who will access the data)

  - security measures (what is the level of security for keeping that data safe from breaches)

  - some infos about the company, the data controller (who is responsible) etc…

So all companies must do a internal data mapping to know and declare where is the data and where it flows in production and write for every PII a ROPA (record of processing activity) You can find an open source specification UROPA here)

https://github.com/uropa-project/uropa

- consent is just one of the 6 legal bases to collect and treat data. The comment above that everything is possible with consent is wrong.

- below 250 employees you don’t need officially a DPO