It’s been a while since I wrote The Problems of Running an Author Website–and How to Avoid Them, and a lot has changed this then. For one thing, GDPR now requires much more care in the way in which a website is constructed. For another, both my sites got hacked. While the advice I gave at the time is still generally sound, it’s clear that it needs to be updated. This post will concern the privacy aspect, and I’ll have another one along soon that deals with security.
GDPR Overview
The European Union’s Global Data Protection Regulation caused a lot of confusion (bordering on panic) outside the EU as the May 25, 2018 enforcement deadline approached. As it turns out, it’s by no means as impossible to live with as some feared, but there is still confusion because different sources are still saying different things about what GDPR really means. For instance, I’ve noticed that makers of WordPress GDPR compliance plugins all describe it in somewhat different terms what the regulation requires. (Coincidentally, in these descriptions, the regulation always requires exactly what the plugin does–go figure!) You can read the regulation itself here, and you can find the accompanying directive here. but the technical detail is likely to confuse you at least a little bit.
All of that said, the philosophy behind GDPR is easy to understand. At the heart of the regulation is the idea that the personal data of website visitors is under their control. They have the right to decline consent to most types of data collection. Depending on circumstances, they may be able to consent to some kinds of collection and decline others. They have the right to know why data is being collected, to access that data, to rectify that data (correct errors), to erase data (be forgotten), to receive the data for use elsewhere (right of portability), to restrict processing, and to object. You can find more detailed explanations here.
This sound like an intimidatingly large number of requirements, but it probably isn’t–for major corporations with their own legal departments. For smaller business, such as independent authors, the requirements might be tougher to deal with, particularly if one collects a lot of data. However, there are ways to make the requirements more manageable.
Collect Less Data
Think carefully about whether or not you really need the information you’re currently collecting. There’s no question that customer data helps to make informed decisions about advertising, and in some cases it might even influence what you decide to write next or how you decide to write. But how much use are you actually making of customer data? Below are some of the ways I cut back to make GDPR compliance easier.
Dump Google Analytics
Some people will see this as heresy. Prior to GDPR, I had Google Analytics on my site, but to be honest, I wasn’t using the data all that much. Also, the more people who opt out of it, the less useful the data will be. There are ways to anonymize the data, but even that kind of collection requires consent. It’s just easier not to mess with it unless you’re deriving a huge number of actionable insights from it. I still collect some statistics through Jetpack, which is better behaved (easier to block cookies prior to consent) and doesn’t collect as much data in the first place.
Keep Advertising to a Minimum
Businesses often use advertising to defray the cost of their sites, and it might be tempting for you to do the same. Based on my own experience, though, I’d have to say you’d need a sizable amount of traffic to generate enough ad revenue to be worthwhile. And ads tend to use tracking cookies and collect lots of data, so you’d need user consent. Think carefully about how much ad revenue you have or expect to get. You can still use ads if you have proper consent machinery in place, but evaluate carefully whether or not it’s worth the hassle. The only thing akin to advertising that I have on this site are the book previews (which generate Amazon cookies) and the occasional affiliate link.
Use a Minimalist Social Media Plugin
It’s nice to have some social proof on your website, but many social media plugins collect a lot of data. Use something like Social Warfare, which I wrote about in my earlier website post. It has many configuration options but remains lightweight. It does make ajax calls when a page first loads, but they occur after the onload point (when a page becomes interactive for the user) and thus won’t create a perceived slowdown. SW support also assured me that the ajax calls don’t run when the site is being crawled by something like a Google bot, so it doesn’t hurt SEO. Most important for our purposes, it sets no cookies and collects no data itself. When a user shares through one of SW’s buttons, the user is interacting the API of the particular social media involved, not with SW. That kind of interaction is governed by the privacy policy of the whichever social media is involved, and it’s obvious to the user that’s what’s happening. The result is that you get your social proof without any GDPR complications.
Don’t Require Users To Create Accounts or Log in
You can’t entirely implement this recommendation if you are making direct sales from your site. At least in WordPress, you can implement it if you have a special area you want to leave open only to certain people, such as email subscribers. In a case like that, just password-protect the page and make sure users who need the password have it. (I send it in my welcome email.)
The reason for making a change like this is to avoid having user data you don’t really need. Unless someone comments (see below), he or she can use all the features of your site without leaving even a name or an email address. And what’s the point of having that data, anyway? Unless the same person has subscribed to your email list, you can’t use their data for marketing purposes–and if they have subscribed, you already have that data.
An objection might be made that, if people aren’t required to log in, their GDPR consent can’t be recorded. However, the relevant legislation says that you have to prove consent; it doesn’t mandate a particular form of proof. If your site is set up in such a way that users can’t give data without consent (see below for site setup) it seems to me that constitutes proof that if they gave data, they consented to it. Of course, I am not a lawyer, so that doesn’t constitute legal advice.
Make Sure Your Comment Setup Is Properly Configured
In theory, you don’t have to require an email address to allow comments, but doing so helps with spam prevention if you use a plugin like Akismet. If you require email, WordPress makes you also require a name, though a user could give a fake name if he or she wished to be anonymous. I even point that out in my privacy policy. Comments can also be a valuable source of social proof, not to mention a good place for discussion if you have a blog post that sparks interest. Fortunately, you don’t have to disable comments to be GDPR-compliant. There are built-in mechanisms in recent versions of WordPress and a handy WordPress plugin that will do that for you.
WordPress creates cookies that preserve a commenter’s information for a while so that it can be filled in automatically if the user comments again. To put control of this feature in the hands of your users, go to discussion settings and check “Show comments cookies opt-in checkbox, allowing comment author cookies to be set.” If a user doesn’t want those cookies, he or she leaves the box unchecked.
The fact that someone writes in his or her own email address rather than having it be collected in some other way ought to make it fairly obvious that he or she consented, but to be on the safe side, you can install WP Comment Policy Check plugin. What it does is give you the option to add a checkbox that requires users to agree to the privacy policy before posting a comment. (The post comment button will remind a user of this and send him or her back to the form if the box hasn’t been checked yet.) Some of the GDPR plugins incorporate this kind of function as well.
Embed Videos with Something Like Advanced Responsive Video Embedder Plugin
Oddly enough, this plugin didn’t start out as a plugin having anything to do with GDPR compliance. Rather, it’s designed to give site owners control over how videos load and enable the use of videos from a wide variety of different services.
That said, it meets the guidelines about no cookies prior to consent through its lazy-loading feature. To speed page-loading, ARVE loads a static image instead of the player. That also means that the video provider doesn’t set cookies. That doesn’t happen unless the user clicks on the image, and by that point, you’d have a chance to warn a prospective viewer about cookies, so only those who chose to have them would be likely to click. (Note: Lazy-loading is only available in the pro version of the plugin. However, if you use a lot of video on your sight, this plugin is a worthwhile investment, both for SEO, because the page loads faster, and for GDPR compliance.)
However, ARVE takes one more step for YouTube videos–it plays them via YouTube’s no-cookie domain. In my tests, no YouTube cookies were set even if I clicked, and the video started playing. I don’t know how that works with the other video providers.
Keep Services for Which You Can’t Seem To Stop the Cookies Offsite
I’ll talk a little later about how to ensure that cookies aren’t set before consent. Unfortunately, no method is entirely foolproof. If you find something that sets cookies no matter what steps you take, try to figure out a way to utilize that provider by linking to its site rather than embedding or otherwise displaying forms, widgets, etc. on your site.
For example, I just switched to Mailerlite, and their form sets a functional cookie that isn’t blocked by my current solution. (It would be if I used the JavaScript implementation, but that required the incorporation of JavaScript on every page of the site, and it was JavaScript that didn’t want to be combined, so it would have slowed loading. Instead, I used an HTML implementation that wasn’t blockable prior to consent. The solution? Instead of having the widget in my sidebar point to a sign-up page on my site, I pointed it to the page on which Mailerlite hosts the form. That way no cookies are set on my site, and I have a chance to warn people that cookies will be used on Mailerite’s site and link to ML’s privacy policy. Users can make an informed choice under those circumstances.
Find a Solution That Blocks All but Essential Cookies Prior to Consent
Prior to the GDPR deadline, I vetted a number of plugins and picked the one I thought was the best. Unfortunately, I discovered later that the plugin blocked only first-party cookies (the ones set by my own domain) prior to consent. That led me to another round of vetting, a greater understanding of how blocking worked, and a solution that did what I needed it to do.
To get this part of the process right, you need to understand that cookies are insidious. The basic motivation isn’t evil. As someone who wants to sell books, you can appreciate the value of targeted advertising, and the more data one has, the easier it is to target effectively. Most people probably wouldn’t mind tracking if that’s all it did. Unfortunately, the behavior of some companies has called the whole idea into question. We have all heard about data being sold, accidentally leaked, or otherwise handled in an unprofessional way. It’s tempting to be annoyed by privacy demands, but they have their roots in common-sense concerns about wanting to control one’s own data.
Modern browsers all have a setting to block third-party cookies, and if everyone used that setting, we wouldn’t have to worry about GDPR compliance as much, because it’s comparatively easy to find plugins that block first-party cookies effectively. It’s much harder to find plugins that do the same for third-party cookies. That’s because third-party cookies are set in a variety of different ways and come from a variety of different sources. Providers of web application firewalls often use cookies to track traffic for security reasons, though those typically aren’t a GDPR problem because it would be easy to defend them as necessary as long as the data being collected is only data necessary for site security and is not being used for any other purpose. Analytics services always produce cookies. Ads virtually always produce cookies. Those are all pretty obvious. It’s less obvious that embedded materials like videos do. Email subscription forms can, as I mentioned above. Recaptchas do. How do you get this bakery full of cookies under control?
Determine What Cookies Exist on Your Site
There are probably more than you think, but it’s easy to identify them. You can get a pretty good idea from the Firefox Storage Inspector tool (under the web development tap). Chrome’s Cookie Manager Extension also works, though it doesn’t seem to catch as many as Firefox does. However, you’d have to check every page and post on your site, which could be quite time-consuming. I also use Cookiebot to do periodic audits. Its plugin didn’t work for me, for reasons I’ll explain below, but I kept the subscription to be able to audit my site efficiently. When I first started, in the days just before GDPR, Cookiebot caught all kinds of cookies I had no idea were even on my site. You need information like that in order to have a more accurate privacy policy.
Cookiebot scans without clicking to accept cookies, so what you should see in an audit is a list of necessary cookies only. Of particular concern are cookies flagged with a message that prior consent is not enabled. In other words, these cookies will load regardless of whether someone has consented or not. Unless Cookiebot has them misclassified, and they should be listed as necessary, a cookie like that is a definite problem.
Eliminate the Elements That Produce Cookies When You Can
See the section above that discusses this. Some people will be able to address all their cookies this way, but you may have some cookies which can’t be handled this way.
Find a Workable Blocking Strategy for What’s Left
I’m sure there must be more than one, but I could only find one that worked for me.
Why? GDPR plugins have a variety of different issues, but the biggest problem with most of them is that they require the end user to rewrite plugin scripts in order to make them responsive to the GDPR plugin’s blocking function. That works if you’re comfortable doing that kind of thing. I’m fairly intuitive about a lot of technology-related subjects, but I found myself hesitant to start adding code to plugins. At the very least, I’d have to test to make sure the plugin still worked correctly, which might always be easy to tell from superficial examination. And what about plugin updates? With at least some of these solutions, I’d have had to rewrite a plugin’s script every time it updated, or at the very least check to make sure the added code was still there. This isn’t an easy solution, and I’m not sure it would always work. This approach also wouldn’t affect cookies set by elements other than plugins. Embedded elements, iframes, and similar content can generate cookies that aren’t plugin related.
I did find one plugin that didn’t require script rewriting and blocked almost every cookie–but it blocked too much. Even ordinary images didn’t show prior to cookie consent. That kind of overblocking seems excessive and might look like an attempt to coerce people into consenting to cookies. Even if it didn’t create that impression, it wasn’t exactly a visitor-friendly solution.
However, there was one plugin that did what I wanted: Weepie Cookie Allow. (Try not to be put off by the name!) Yes, it’s a premium plugin, but at $14, it’s a worthwhile investment.
- It blocks many of the most popular cookie-produces services right out of the box. If you need Google Analytics, Google AdSense ads, Google AdWords remarketing, Amazon adsystem, JotForm, and a huge number of other statistical, social media and video platforms (see the complete list here), WCA has you covered.
- It can block all iframes, which removes another big source of cookies. For me it took care of the Amazon book previews, for example. It leaves a placeholder with a button to accept cookies and a customizable message.
- A lot of cookies are set through JavaScript, and all of those can’t be blocked automatically. However, WCA provides a solution in the form of shortcodes. Enclose the JavaScript in appropriate shortcodes, and the scripted element that produces cookies is blocked and replaced with a placeholder and handy accept button, just as iframes are. For me this took care of Screencast videos and Gleam giveaway widgets, the latter of which was particularly hard to block. (And yes, the process of adding shortcodes to JavaScript is a lot easier than rewriting plugin code.)
- The plugin is highly customizable. The consent banner is obvious but not annoying. The requirement that visitors be allowed to change their consent settings at any time is covered by shortcodes that enable the placement of buttons that are labeled accept cookies if the user has declined cookies or hasn’t acted and reset cookie consent if the user has accepted cookies. (I placed one on my privacy settings page and in the footer on every page.) You can also allow for consent by type of cookie, though I’m not sure that function works for certain cookie implementations.
Weepie Cookie Allow is a good way to keep elements on your site that you really don’t want to eliminate. What about the people who don’t want to accept cookies? To avoid losing potential users, offer an external link as an alternative. Users may be asked to accept cookies at the external source as well, but in that case, they can accept only for that particular purpose and not have to accept cookies globally.
Why Not Just Avoid the Problem by Geoblocking Users from EU Countries?
The short answer is that there are a lot of English-speaking prospective book buyers in the UK and Ireland, as well as a fair number of English speakers in other EU member states. (Yes, I know about Brexit, but the UK has committed itself to following GDPR after the separation.) Blocking part of your possible customer base doesn’t really make sense unless there’s no other option.
The longer, more technical answer is that geoblocking is not one hundred percent reliable. First, GDPR covers citizens of any EU member state even if they aren’t currently residing within the EU. You can usually tell in what country an IP address is located but not what the user’s citizenship is. Second, IP addresses may not always accurately reflect a user’s true location–and I’m not just talking about hackers here. Anyone using a virtual private network (VPN) could appear to be in one place when the person is actually in another. I’m in the Los Angeles area, but by switching the way I connect to my VPN, I can appear to be in a variety of places in the United States or in thirty-one other countries. Typically, people would use the access point closest to them, but they don’t have to. I can easily imagine a geoblocked EU citizen using a VPN to get around the block. I doubt not knowing someone was an EU citizen would be a valid response to a GDPR complain. By the way, that’s a reason for applying GDPR standards to all of your visitors, not just the ones you’re sure are connected to the EU.
Email Considerations
Email is governed partly by GDPR and partly by other regulations in the EU, as well as by various laws in areas outside the EU, such as the CANSPAM Act in the United States. Here the requirements are clearer and even easier to deal with.
The basic principle underlying all this legislation is that a sender needs recipient consent to send commercial emails. A few simple precautions will keep you in compliance.
Consent Must Be Explicit
You might be tempted to say, “Well, duh!” However, sometimes people think they can add all their personal friends to their email marketing list. No. Sometimes, people also assume that posting an email address online makes someone fair game. No. Users must specifically subscribe in order to be legally placed on your list.
Use an Email List Provider
There are ways to host your own list, but one thing a list provider can do is provide external verification of the validity of the sign-ups. That’s one extra level of protection that makes the typical email service well worth the money.
Make Sure Your Subscription Form Is Clear, Accurate and Legally Compliant
It’s important that people know what they’re consenting to. That means the form should include a general description of the kind of content you’ll be sending out. Someone signing up for an author’s newsletter doesn’t mean that person has consented to receive information about a seemingly unrelated topic, particularly not if it appears to be advertising. Don’t do your local auto mechanic a favor by advertising his services in your newsletter–unless you’ve told your potential subscribers that you’ll do that kind of thing from time to time.
To ensure that consent is explicit, make sure the form doesn’t have the checkbox checked by default. Having the potential subscriber check the box makes the intent clearer.
Use Double Opt-In for Your Own Forms
Though not legally required, double opt-in provides an extra layer of protection by making consent even more explicit. It also avoids the problem of someone using someone else’s email address to subscribe. I imagine that kind of prank is rare, but why take the risk?
Setting up double opt-in is usually as simple as choosing the right options with your email provider. When someone subscribes, the provider sends a confirmation email. The subscriber needs to click the link in that email to complete the subscription process.
Yes, this means that some people who might have subscribed won’t respond to the email and not end up getting all the way there. To me, making the consent as explicit as possible is worth it. My hunch, though I have no evidence for this, is that the people who don’t confirm in general are probably not as eager to subscribe in the first place, though that wouldn’t be true of people whose confirmation email ended up in the spam folder.
Check Before Using Double Opt-In with a Service Connected through Integration or API
At first glance, it seems as if you would want all your subscribers to be filtered through double opt-in. That’s certainly what I thought. However, check how the services you want to integrate your email list with handle subscriptions.
What I found out was that a lot of services essentially build double opt-in into their processes, so that if you also require double opt-in, your potential subscribers are really doing triple opt-in. I’m cautious, and even I think that’s overkill.
The question came up when I noticed that subscribers from BookFunnel were going straight onto my list without a confirmation email. BookFunnel support told me that BF didn’t support double opt-in because they already confirmed subscribers on their end. I knew subscribers from BF went through some kind of process, so I went to one of BF’s download links and tested. Just like double opt-in, BookFunnel sends a confirmation email. I checked StoryOrigin and Gleam, and they both do the same thing with email subscriptions. In addition, all three companies keep records of their activities, so it’s easy to use their data to prove the validity of a subscription if there is ever any doubt.
Be Cautious with Using “GDPR” Subscription Forms
This one also seems counter-intuitive. What better way to be in compliance with GDPR? I certainly thought so at first.
The problem is not with including the GDPR verbiage on the form. The problem is with using an actual GDPR consent-to-email-marketing checkbox. Why? Because at least some of the email providers don’t properly connect consenting to email marketing with subscribing.
For example, some providers don’t prevent the subscription form from going through if that email marketing checkbox isn’t checked. What that means is that someone can end up subscribed to your list without having consented to email marketing. No, that doesn’t make any sense, but I’ve seen people do it, probably by accident. The problem is that their consent status is then ambiguous.
The ambiguity is even worse with some providers because a user can remove consent to email marketing without being unsubscribed. Again, I’ve seen this happen. Then you have someone who explicitly withdrew consent but who will still receive emails if you’re not careful. I don’t know what an EU court would do with that situation–and I don’t want to find out!
Check with your email provider. So far, both Mailchimp and Mailerlite have some form of this problem. Fortunately, there’s a workaround with any provider whose forms are customizable. (I suspect that’s all of them.) As long has the form as a check box of some kind as well as the subscribe button, and as long as that box has to be checked before the subscribe button can be clicked, you can simulate the GDPR form by making clear that checked box means that the user is consenting to email marketing. To be on the safe side, make sure that that opt-in box input isn’t carried separately in a user’s profile the way formal GDPR consent is. (Data like opt-in IP and date isn’t a problem.) That way a subscriber can’t create ambiguity by withdrawing consent from email marketing without unsubscribing.
Final Words
It took me weeks of experimentation to work all this out. Hopefully, my experience will be helpful to at least some of you.
Compliance with GDPR and other privacy laws seems daunting at first, but it doesn’t have to be. It takes a little time, but both your website and email lists can easily be whipped into shape if they aren’t already.
I hope I win