The GDPR is a well-intended but terrifyingly broad and not terribly well-considered directive (not a law, although it has the force of law) intended to codify the privacy rights of people in the EU’s European Economic Area. It is very complicated and affects pretty much anyone who interacts with data related to people in the EU, with eye-widening penalties for noncompliance (up to €20 million, or more for really big companies). I’m not even going to try to summarize its provisions, since I am not a lawyer and would not like to give you the impression I understand all of these very complicated rules, or even to what extent Ate Up With Motor (which is based and served in the U.S.) may be subject to them. As far as I can see, no one else knows that for sure either.
In my view, some of the principles of the GDPR are essentially good (if not necessarily well or clearly delineated) and some are likely to have significant unintended consequences. The rules tend, by my reading, to encourage the kind of big data aggregation that people are nervous about in the interests of “data portability.” That’s likely to be bad for actual privacy, even if the other rules encourage greater transparency (which is not the same thing!).
The difficulty regulations this far-reaching present for a website like Ate Up With Motor is that their legal and technical complexity really exceeds my capabilities. Ate Up With Motor is a sole proprietorship — it’s just me, and this is not the only thing I do — and as I am not a software developer nor particularly financially flush, I am greatly dependent on preexisting cheap, free, or open-source solutions, like WordPress and the various plugins I use. In most cases, I did not design these tools and don’t know in any technical detail how they work (what they do, yes; how they do it, not so much). Nonetheless, under rules like the GDPR, I am legally liable for them to an alarming degree.
An example of the kind of thing I’m dealing with: Many WordPress developers love to use free font and script libraries, like the ubiquitous Google Fonts API. These tools have obvious advantages — they’re free, they’re generally simple to use, and they may be faster than having scripts or fonts served locally — but the have privacy implications because the library that serves the font or script generally records the IP address and user agent data (including things like your browser and device) from each person who loads a page containing those elements. Under the GDPR, a bunch of that data, including the IP, is deemed personal information, at which point it becomes a complex liability.
I have over the past few years tried to limit my use of third-part elements like these, setting up the fonts locally and avoiding CDN services. Unfortunately, there are some limits to my ability to do this. For example, some of my WordPress components use Font Awesome, which is served by an external CDN service, for icons and graphics. While I know it’s theoretically possible to have Font Awesome hosted locally (the library itself is open source), I don’t know how to do so reliably. Directly modifying WordPress plugins and themes is bad practice because your changes will be overwritten as soon as the plugin or theme updates, and while you can alter some behavior through a child theme and functions, updates to the theme/plugin may render those efforts futile. (This has happened on another of my websites, where the updated theme refuses to stop calling Google Fonts despite my ongoing efforts.) My hope is that if nothing else, the GDPR will encourage developers to be more cautious about this sort of thing. Presently, many don’t seem terribly concerned about it.
Some straightforward details are now complicated and somewhat fraught. The GDPR considers server access and error logs (which every website has in some form) to contain personal information. Similarly, the metadata in image files (such as Exif information) can count as personal data because some of that information might identify the user or their location. I’ve attempted to account for this as best I can in the policy, although I must confess that full compliance with some of the requirements seem technologically impossible. (For instance, if someone from the EU visits a non-EU website for the first time, the site’s logs gathering their IP and user agent data — which is independent of visitor consent — are already in violation of the rules. Even blocking traffic from all EU addresses is of questionable legality because it would require processing the visitor’s IP address in order to block them.)
In any case, I’m doing the best I can with it within my limited abilities, and I hope you’ll bear with me about it. If you have questions, please let me know.