Why is the GDPR so far-reaching?

[Dani]

You may have noticed all of the work I've been doing lately on cookie consent banners, legal links in the footer of every page, etc. I recently received a couple of "right to be forgotten" requests from EU-based members. And that got me thinking: Why is the GDPR so far-reaching? In other words, why, as a US-based company, and a tiny one at that (I don't do any business with non-US based companies), why must I follow the GDPR's right to be forgotten laws? (For those not in the know, the GDPR is an EU-based law.)

[SCBWV]

Well I went down the rabbit hole. Interesting reading though. Your (I assume rhetorical) question reminds me of the Brexit issue of the EU imposing laws on sovereign states. Kind of pisses you off. Most of the reading was rather vague. I'm sure it's difficult to cover every scenario (GDPR.EU). LegalClarity.ORG said "A website being viewable in the EU is not enough to trigger GDPR obligations, as there must be an element of targeting or intentional monitoring."

[jkon]

Short answer: Because you want your website to be accessible in the EU, and in the EU people have certain minimum rights. You could choose not to serve content in the EU, as some American companies do.

Implementing GDPR is rather straightforward, and I dare to say logical and easy. Wouldn't you have a privacy statement somewhere in your web app anyhow? That is the link you mentioned. Wouldn't you let your visitors choose and know what external services you are loading that will track them? Is the "right to be forgotten" so far-fetched, or are the other tools that every site compliant with GDPR must have (like the option for someone to retrieve all the data that a site holds for them)?

There are certain problems with GDPR, and I would never consider those to be among them. There is a fixation on cookies as the tracking mechanism in the law, but I hope that more things will be added. The main problem is how some big companies, from the USA or even the EU, bend the rules at their will, having several lawyers and court cases until the law is enforced.

[Dani]

My preference would be for non-EU companies to only be required to adhere to GDPR laws if they do business with companies or people in the EU. As it currently stands, any American-based blog that has a comment section (e.g. accepts log-ins) must adhere to EU-laws.

In theory, yeah, I don't have any issue with what GDPR is trying to achieve. Theoretically, it all makes perfect sense. Have an easy-to-find privacy policy. Alert users when cookies are tracking them. etc. That all sounds fine and dandy.

My problem is with the implementation requirements. In theory, a cookie consent banner sounds fine. And it is in non-GDPR countries. However, all Google products require a CMP (cookie consent banner) that uses the TCF API for users in GDPR-based countries. Not anyone can just build their own CMP that implements the TCF API. In fact, it's not very straightforward or easy to join the TCF as a CMP. That means that you have to pay for one of the existing CMPs that already has access to the TCF API, such as CookieYes or Cookiebot. They are bulky and slow loading and expensive for sites like DaniWeb that get a lot of traffic but don't make a lot of money. The only free CMP that I am aware of is Google FundingChoices, and it is not user-friendly nor configureable.

Then there's the right to be forgotten. Every so often I get a request. Sometimes they're hard to deal with when I'm bed-bound and trying to run DaniWeb alone and still need to figure out a way to handle the request in a time sensitive manner. There's a reason I'm not able to do freelance work these days, and it's because my illness often takes me sporatically offline for days or weeks or, sometimes, months at a time. Sometimes they're a pain, like a current situation that has taken a lot of back-and-forth because, even though the information has been erased in the database, it still exists cached by Cloudflare, so there has been some back and forth about that. It makes me wonder what would happen if someone has a blog that accepts user account creations for the purpose of comments. That person then goes to school, forgets about their blog, etc. Years and years later, one of those commenters wants to be anonymized. If the former blogger no longer monitors their email or no longer has access to the credentials to the old database, they could face massive fines ... and they're not even in the EU nor ever attempted to make a dime off of an old hobby blog they had in middle school.

[Dani]

Implementing GDPR is rather straightforward, and I dare to say logical and easy.

What CMP do you use?!

[jkon]

@Dani What CMP do you use? We have our own implementation that differs in GDPR tools based on the specific web application.

Cookie consent management is the easiest part. You display a short message like, 'In daniweb.com, we value your privacy... so we use cookies to make your user experience even better,' along with three options: Accept All, Deny All, or Cookie Settings. Of course, you can organize your cookie settings section as you want—as a different page, a modal, etc.—and you can group the cookies as you wish. We list the necessary cookies (session cookies, etc.) that one cannot opt-out of, separate from those used by external services, but you can group them in another way if you prefer. Google is (of course) fine with that. There was a discussion some years ago that you could load an external script/service in a stale mode and activate it only when the user consents (I believe we all understand what that means), but in my opinion (and our lawyer's), this is not the case.

As for the GDPR tools, they are automatic in each web app. The "right to be forgotten" for example, triggers a double verification using password and email (or even an SMS code) and a final confirmation from the user that they actually want to proceed. After that, all the records remain for database integrity, but the actual data is filled with XXX, 000, etc. No manual work is needed for any GDPR tool from an administrator (if it were, they would have a serious compliance problem).

From a technical point of view, if we are talking strictly about the CMP, it's just a few lines of JS code. When someone accepts all, it populates the cookie acceptance cookie with all the services (e.g., [ga], [fbq], etc.) and initializes the JS Tracker object. There, the Tracker object checks for each service that wants to load if it is listed in the cookie (if [ga] is present in the cookie, it will load Google Analytics, for example). All tracking everywhere in the web app is done through this Tracker object, giving you one central place to manage these services.

When the user revisits the web app, and you know client-side that the cookie exists, you use that data without showing the visitor any message again. When the user selects services through a "cookie settings" page, you simply repopulate the cookie with the new data and reload the web app, allowing the Tracker object to know which services it can and cannot load.

As for the kid that has a blog, and we are talking about a comment there that someone wants to delete, Is that blog in another platform, or does that kid have its own platform? If it is the first one, then it's not their issue, it is the platform's issue. If it is their own platform, it had so many years to implement what is needed that it is no longer a kid. In any case, there aren't any irrational fines even for companies inside EU, and certainly not for kids outside EU.

[Dani]

What CMP do you use? We have our own implementation that differs in GDPR tools based on the specific web application.

I use my own implementation for non-GDPR countries. It's pretty standard as far as cookie consent banners go :) Accept, Deny, Configure, link to Privacy Policy, etc.

Unfortunately, Google Ad Manger (and Google AdSense) requires us to use a Google-certified CMP that implements the TCF API. For this reason, I can't use my own CMP within GDPR regions. Within the GDPR, I use Google's shitty FundingChoices CMP because every other Google-certified CMP is cost-prohibitive for us.

No manual work is needed for any GDPR tool from an administrator (if it were, they would have a serious compliance problem).

For the most part, this is true for us, as well. With one notable exception. If a member deletes their account, their posts stay attached to their username. Their username just is no longer clickable and no longer links to any sort of member profile. This has benefitted us a lot in the past where members with a lot of posts will delete their account, but knowing who the posts used to come from (e.g. diafol, to give a good example) helps preserve the integrity of the conversation / community. There is a warning on the delete account page that has a link to let you change your username before confirming account deletion. Unfortunately, most people don't use it, and then they complain, and then I have to go and manually update their username in the database to something more anonymous since they can't log in anymore and they don't have a profile page for even an admin to edit.

My rant is that I get that these problems are solveable for companies with resources. I think it's a little unfair for someone who had a blog in middle school to now have to be held accountable for this years and years later.

If it is the first one, then it's not their issue, it is the platform's issue.

That's not true. If I pay $4.99/month for a hosted Wordpress, it's still my responsibility, not the webhost's. I bring up this example because I'm bed-bound with terminal cancer and haven't made money off of DaniWeb in years and years (since I got sick, at least). It seems like a comparable situation.

[Dani]

I don't know why I completely forgot this, but aside from Google effectively "regulating" by requiring a CMP that utilizes the TCF API, I recall that in order to provide Log In via Facebook, Facebook required that my privacy policy not just say that a member could delete their account via their user settings page, but that I provide an email address where users could email to request deletions manually. I remember not having this and going back and forth with Facebook many times before finally giving in.

No manual work is needed for any GDPR tool from an administrator (if it were, they would have a serious compliance problem).

I guess you'er not using Log In with Facebook lol.

If it is their own platform, it had so many years to implement what is needed that it is no longer a kid.

Why are you assuming that the kid spent their youth learning web development and taking the time or interest to implement it on a hobby blog?

In any case, there aren't any irrational fines even for companies inside EU, and certainly not for kids outside EU.

I think this is a bit of an overreaching statement. In my case, for example, people generally see over one million registered users and 2.5 million posts, 10 million monthly unique visitors at our peak, and assume that we're some large enterprise with deep pockets that should have to pay heavy fines for noncompliance. In reality, I'm just a housewife turned terminal cancer patient, laying in bed, sickly, and not capable of any form of steady work to make any money. :-/

[Dani]

Upon further analysis, it appears my problem is how big tech firms are forcing their implementation of GDPR and CCPA, etc. on anyone who wishes to partner with them. Plus, being a California-based company, I have to follow CCPA, which has its own separate set of headaches from GDPR.

[IS-92]

Several technical inconsistencies in the GDPR are not addressed, but are critically important. The "right to be forgotten" is a typical example of such a technical inconsistency, and I can immediately explain why.

How exactly is the deletion of the "digital environment" carried out so that the requirements are actually met?

As a person who has been working in the field of competitive intelligence and information security for years, I can say that we practically do not have any deletion. The information remains on the servers, and no one even tries to delete it.
After the replacement of the used disks is carried out, the obsolete ones are sent en masse to Ghana. Yes, but in Ghana, the black market in information is a matter of state policy. Every day, over 3,000 (three thousand) devices are "extracted" from the "landfills" in Ghana (where data carriers should be destroyed). All information is then subject to sales on the "black market".
Should I recall what Christopher Robinson and Randal L Schwartz said years ago on the subject? Since then, nothing has changed, and back then, there was no GDPR and other similar directives, but instead of solving technical problems, political solutions were pursued.
Unlike human laws, however, physical and technical ones are irrevocable.
The disadvantages of such solutions are more than obvious. It is enough to mention only Local Shared Objects.
Samy Kamkar has been trying for years to explain what dangers this technology poses in the widely used Session Storage, Local Storage, Global Storage, Database Storage via SQLite, etc.

How has GDPR helped to solve this problem?

Or let's talk about CSS History Knocker, which is definitely outside the scope of GDPR, due to its specificity.

And how exactly does GDPR protect users from something like this?

function getCookie(best_candidate, all_candidates)
{
    alert("The retrieved cookie is: " + best_candidate + "\n" + "You
can see what each storage mechanism returned " + "by looping through the all
candidates object.");

    for (var item in all_candidates) document.write("Storage
mechanism " + item + " returned: " + all_candidates[item] + "<br>");
}

ec.get("id", getCookie);

</script>

The Evercookie library is completely open-source, so you can freely
use it and customize it to suit your needs. There are no significant server requirements. All you need is access to the JavaScript script containing the evercookie code. To use Flash cookies (Local Shared Objects),
the script folder must contain the evercookie.swf file, and techniques based on PNG caching and ETag storage require access to the evercookie_png.php and evercookie_etag.php PHP scripts. You can use evercookie on any page of your website.

The evercookie library is available to everyone. This is a bit scary, especially if you have absolutely no idea what you can do about it.

In this concrete case, the GDPR is quickly harmful, and the authorities are wrong.

I could go on with the examples, but it's better to stop so as not to be accused of illegal activity.

Political solutions do not solve technical problems. The truth is that they create additional ones that we have to contend with.

P.S. I live and work in Bulgaria, and as a citizen of the European Union, I have suffered from wrong decisions. You have no idea what the qualifications of the MEPs in the IT field are. I think you will be horrified if you learn the truth.

[Dani]

I think that the problems you’re complaining about are easily solvable with low level formatting a drive that has sensitive information before discarding it, and using HTTP-only cookies that JavaScript cannot access.

[jkon]

Hello @Dani, yes, we have a few customers who use Facebook login and even fewer (I believe currently only one or two) who have Google AdSense. (We primarily provide web applications for e-commerce, online shops, reservation apps for car rentals - hotels etc.) In the first case (Facebook login), I don't recall the specific custom email address that must be provided to Facebook for users to request account deletion. This was likely set up by our Sales and Demand team (S&D), and since there have never been any issues, the detail hasn't reached me. Regarding the second (Google AdSense), yes, I remember the "Funding Choices" oddity, but the fact that Google was legally compelled to offer a free alternative is still a minor victory.

I wish the issue with Google AdSense were the only problem, but Google's position as the dominant player is telling of how these companies handle regulations. Initially, they did whatever they could to promote false narratives, suggesting things like, "If you've already accepted my cookie settings and rules, there's no need to accept them again in a different web application that uses my services." With their current implementation, they ultimately threw the burden back onto the small companies that want or need to do business with them. How much more would it cost Google to verify that a website seeking AdSense partnership adheres to the law? The small businesses, of course, are the ones paying that cost now.

And this is not the only problem with GDPR. The initial argument I mentioned (that a user shouldn't explicitly accept cookies in our web app because they have already consented on the main corporate site) still persists on some platforms even within the EU. This puts thousands of small companies in a legal limbo, requiring frequent changes to their GDPR implementations. Naturally, you can object or pursue legal recourse, but that big business will then cease working with you and potentially blacklist you, ensuring no other companies of their kind will partner with you (does that practice sound familiar)?

Therefore, the core problem with GDPR and EU policy lies in the enforcement of the law against big tech companies. Instead of closing these loopholes, we have politicians across the aisle advocating for further deregulation of big tech under the guise of "innovation". I argue that the failure to strictly enforce the law against these powerful corporations is what actively stifles genuine innovation.

I hope that after the next round of economic instability that big tech companies will cause to the real economy, EU will enforce stricter measures against them. Perhaps then we can establish a unified regulatory framework that encompasses not only GDPR rules but also, following the same principles, CCPA or whatever new regulation emerges. Just hoping...

[Dani]

yes, I remember the "Funding Choices" oddity, but the fact that Google was legally compelled to offer a free alternative is still a minor victory.

My biggest issue with Funding Choices is that, even though I am using my own CMP outside of GDPR regions, I am required to load the Funding Choices javascript globally, and leave it to that third-party [Google] javascript to only make the CMP visible within GDPR regions. It loads and slows down pages outside of GDPR regions for ... reasons??

[Dani]

Also, a Google-certified CMP isn't just required for AdSense. It's also required to use Google Ad Manager, which is the ad server we use to show ads for our own clients that we work directly with, that we sell to ourselves.

[IS-92]

Hello Dany,

As I mentioned, I have been working in the field of information security for years, and I can assure you that the problems that my colleagues and I have been discussing for years are not only unsolvable but are also getting worse.
One of the biggest fallacies (intentionally spread by people like me) is that low-level formatting can destroy data on a storage device. If this were true, there would be no need to develop standards such as NIST Special Publication 800-88, NIST Special Publication 800-90A, NIST Special Publication 800-90B, U.S. Department of Defense DoD 5220.22-M (ECE), U.S. Department of, Defense DoD 5220.22-M (E), U.S. Department of Defense DoD 5220.28-M - STD, U.S. Army AR 380-19, U.S. Air Force AFSSI-5020, Canadian RCMP TSSIT OPS-II, British HMG IS5, Gutmann, Russian Standard – GOST-R-50739-95, etc..
Recovering critical information is not a problem, and for several years now, it has not even been necessary to purchase expensive hardware solutions.
Even if the IS is turned off, this does not mean that users will be protected. Note that we are talking about digital objects (digital images, audio files, applications, etc., etc.), and without themон, you simply have to refuse to use any software solutions.
It is a completely different matter that the ban on IS does not block packet steganography in any way.
As for text steganography, there is one in GitHub and in each of the open source libraries.
And what is done in this case?
The sect of open source supporters is very strong and definitely loud, which is very well used by a number of agencies for the successful implementation of disinformation campaigns (for reference https://jesbg.com/gtgerasimov-kritika-na-dezinformatsiyata/).

You can read more about disk sanitization at the following address:

https://g-92.com/Crypthor/FDM/Help/ENU/Part_001/Part_002/index.html

Note: The article is in Bulgarian, but you can use an automatic translation system. It describes in detail the mechanisms used in creating the GDPR and not only. After all, this is part of my work, and believe me, what I write is directly related to what I do. Political decisions in Europe are subordinate to lobbying interests. What is prohibited in the US is permitted here, and this leads to serious problems.