Category: GDPR

On the 14th September 2019, PSD2 comes in to force. If you receive payments online from your customers, you should understand what changes to expect, and whether or not action will be required on your part to comply with the law and to avoid significant loss of income.

Let’s start with a little glossary

PSD2
The Revised Payment Services Directive is the second iteration of the ‘Payment Services Directive’ (PSD), a European Union (EU) directive first introduced in 2007 to regulate payment services and providers. The directive was introduced to break the banks’ monopoly on payment services, encouraging innovation and improved security.

SCA
Strong Customer Authentication is essentially the same as the Two Factor Authentication you may already be familiar with if you have ever had to receive a code by email or SMS in order to log in to an online service. Its purpose is to improve security by requiring two of the following three things:

  • Something the person knows (such as a password)
  • Something the person has (such as a mobile phone or device)
  • Something that the person is (such as a fingerprint or their face)

3DS2
3D Secure is a term used to describe additional authentication during an online payment. You may remember when 3D Secure first appeared in 2001 as “Verified by Visa” and many online card payments required a password? The interruption to the checkout process was hugely disruptive – damaging to businesses and frustrating to customers, but merchants were obliged to implement it or risk not being protected against fraudulent transactions. 3DS2 aims to address many of the shortcomings of 3D Secure 1 by introducing less disruptive authentication and a better user experience.

Frictionless Authentication

3D Secure 2 allows businesses and their payment provider to send more data elements on each transaction to the cardholder’s bank. This includes payment-specific data like the shipping address, as well as contextual data, such as the customer’s device ID or previous transaction history.

The cardholder’s bank can use this information to assess the risk level of the transaction and select an appropriate response:

  1. If the data is enough for the bank to trust that the real cardholder is making the purchase, the transaction goes through the “frictionless” flow and the authentication is completed without any additional input from the cardholder.
  2. If the bank decides it needs further proof, the transaction is sent through the “challenge” flow and the customer is asked to provide additional input to authenticate the payment.

Although a limited form of risk-based authentication was already supported with 3D Secure 1, the ability to share more data using 3D Secure 2 aims to increase the number of transactions that can be authenticated without further customer input.

Example flow of authenticating a payment using 3D Secure 2 with fallback support for 3D Secure 1

Frictionless Authentication

Even if a transaction follows the frictionless flow, your business will benefit from the same liability shift as for transactions that pass through the challenge flow.

Better user experience

Unlike 3D Secure 1, 3D Secure 2 was designed after the rise of smartphones and makes it easier for banks to offer innovative authentication experiences through their mobile banking apps (sometimes referred to as “out-of-band authentication”). Instead of entering a password or just receiving a text message, the cardholder can authenticate a payment through the banking app by just using their fingerprint, or even facial recognition. We expect many banks to support these smoother authentication experiences with 3D Secure 2.

The second improvement in user experience is that 3D Secure 2 is designed to embed the challenge flow directly within web and mobile checkout flows—without requiring full page redirects. If a customer authenticates on your site or webpage, the 3D Secure prompt now by default appears in a modal on the checkout page (browser flow).

Source: Stripe – https://stripe.com/en-fr/guides/3d-secure-2

How does this affect you and what actions are required of you as an online merchant?

As always, this depends on the platform that you use to sell online. The chances are that you will only have to take any significant action to comply with PSD2 if you host your own website (e.g. WordPress). In most other cases, it will be the responsibility of the website service provider to update their payment processes, and many have already done so. Your responsibility is only to check that the payment processing will be compliant. You can usually do this by browsing their forum or by asking their support team. A few examples include Squarespace, Wix, Shopify, Big Commerce, Etsy, eBay, Amazon, Eventbrite.

If you have a web hosting package and accept payments via a WordPress website for example, you will need to establish what payment gateway you use to receive the payments and if it has been implemented in a compliant way. At time of writing, Stripe are ahead of the curve, and the official Stripe plug-in for Woocommerce is already compliant. Do check your own implementation is up to date and compliant. If you use any PayPal off-site payment methods, no changes should be required as the payments are not processed on your website, but at present (5 August 2019), PayPal Pro (on site payments) is still not compliant.

 

With just a month now until the GDPR comes in to effect, a lot of very small (and some not quite so small) businesses are still finding the prospect of GDPR compliance overwhelming. One aspect of that compliance where I might be able to shine a little light, is the website privacy policy. Once again, I am merely sharing my thoughts here, based on my own research and interpretation of the GDPR, so please do not take these words as any form of legal advice.

Very simple websites

Many of the websites I work with are very simple in their functionality. They are essentially brochure websites, very much like this one, with perhaps at most a contact form as the only vehicle for handling personal data. In many cases these micro businesses are barely in profit and in no position to employ professional help to assure them that their website is “compliant”. The owners of websites such as these are understandably confused and alarmed by the technical terms ringing in their ears and the threat of astronomical fines for non-compliance. If that sounds like you, my advice (were you to ask it) would be above all, not to panic. If you fall in to this category, in GDPR terms, where you are handling personal data at all, it is likely to be in a way that exposes the data subjects (your website visitors) to very low risk. Frankly if you were to choose to ignore the whole thing, the consequences would be…null. In my opinion. But since you ask, I would not advise you to ignore the whole thing. By taking a little time to create a simple privacy policy, you will achieve a few things:

  • That warm, fuzzy feeling from having Dealt With It!
  • Demonstrate to clients and, who knows, maybe even the data protection police, that you take privacy seriously, have some awareness of the laws, and have made an effort to comply.
  • Going through the process will make you more aware of your own practices and may even reveal that you were processing data in ways you were not aware of.

Copycat

I do not believe in copying verbatim, the privacy policies of other websites. Firstly of course, that is plagiarism, and secondly, it’s highly unlikely that the privacy policy of another website will be a perfect fit for yours. That said, taking inspiration from other people’s well written privacy policies is a great idea. I wouldn’t suggest for a moment that my own privacy policy is a good example, but feel free to use parts of it, preferably reworded, if you would like to.

Anatomy of a basic privacy policy

  1. State the identity of the data controller –  This is a legal entity and should include a registration number where appropriate – in the case of a company, the data controller will be the company. More likely, you are an individual and should state your name. Do not hide behind your business name though unless it is a company in the legal sense.
  2. State how you can be contacted – A link to your contact page or email address is adequate if you don’t want to disclose your telephone number or address.
  3. State how (if) you collect personal data on your website – If you do not collect any personal data in any way shape or form, just say so. If you have a contact form, try to understand what happens to the data when the submit button is clicked. If your website is self-hosted (you have your own hosting package, perhaps with a WordPress website on it), there’s every chance the data is sent straight to you via email. If you have a hosted website with Squarespace or Wix for example, or use a hosted form such as Jotform, ask them for advice as they may process that data before sending it on to you. If this is the case, just arm yourself with the information and state it in simple terms in your privacy policy.
  4. State what you do with that data and why – Very likely it sits in your email archives. Perhaps indefinitely? Just state that you collect whatever you collect (name and email address perhaps) in order to reply to their enquiry. If you want to be all legal about it, your legal basis for doing this is probably legitimate interest*. You may also want to state how long you keep the data before destroying it.
  5. Cookies State very simply what a cookie is (see my policy for suggestions). Try to find out if your website is setting cookies, what they are and what they are for, and list them.** State very simply how cookies can be controlled by the user in their browser (see my policy for suggestions).
  6. Users’ rights under GDPR These are extensive, so my preference is to provide a very brief synopsis, accompanied by a link to more information, and information about how to contact me should they wish to exercise those rights (see my policy for help). This section really is a formality. With a super simple website that does not collect personal data, nobody is going to be exercising those rights!

* You do NOT need a checkbox to record consent on your contact form if all it is used for is to send you a message. If you want to get people to subscribe to your mailing list at the same time, or plan to use their submitted data in any other way, that’s another matter entirely.

**Cookies

This is the trickiest bit for most. I covered cookies in some depth in my previous post, so have a look there if you’re ready to grasp the nettle on this one! If that all sounds too terrifying though, it’s still worth trying to find out what cookies your website uses, and the free Cookiebot tool is very easy. Don’t be alarmed when the result comes back saying NON COMPLIANT – they want you to buy their services. What’s especially helpful about the Cookiebot test is that they categorise the cookies for you.

  • If your site sets no cookies – great – say so!
  • If there are cookies in the “statistics” category, just state that the website uses cookies to provide you with statistical information about how it is being used.
  • If there are cookies listed in the marketing category (apart from Google Analytics), you really ought to dig a little deeper, try to understand where these are coming from and clearly state in your cookies section how your visitors may be being tracked and by whom. Likely candidates are Facebook (do you have a pixel installed?), Google (in various guises), AddToAny and ShareThis (social sharing), etc. Do attempt also to provide links to information about how to manage these cookies. In most cases, the companies in question will have information available for you to link to.

Cookie notification banners & consent

If after using Cookiebot’s free audit tool, it turns out that your website does use cookies, of the sort that require consent (that’s pretty much all except those in the necessary category), you do have an obligation to make people aware of the fact and, technically, to gain their consent before placing those cookies. Now, none of this is actually a new requirement under the GDPR. The EU “cookie law” came in in 2011, at which point, we all started seeing the infuriating and now ubiquitous cookie popup banners everywhere.

A note on consent as applied to cookies

At present, in some EU states (e.g. France and The Netherlands), you are required, not just to notify users of the cookies you use, and to assume their implicit consent from their continued use of your website, but in fact to obtain their explicit consent, through an affirmative action (scroll, button click, etc) before placing the cookies on their browsing device. Under GDPR you are also supposed to retain a record of that consent. This is technically a very difficult thing to achieve, and is typically what is provided by the commercial vendors of cookie consent solutions, such as Cookiebot, OneTrust, etc. The same functionality is also available for free from Civic Cookie Control. It’s worth noting that in very few cases (in France at least) is this actually implemented correctly. Yet despite being more than capable of implementing a super-compliant solution like this, and despite being of rather a conservative nature in these regards, after much research and reflection, I have chosen not to do so on the sites that I maintain. This is partly because I find them to be intrusive to users and to have a detrimental impact on the usefulness of whatever services are setting the cookies, and partly because I have a suspicion that within a year they will be redundant.

If, at this point, you have not implemented any sort of mechanism to notify your visitors of your use of cookies, and if, at this point, it feels like something that would be very difficult to achieve, you might want to sit tight for a bit. At some point next year (2019), the various EU state-specific cookie laws will all be replaced with the uniformly applied, revised e-Privacy Directive, and it looks likely that at last a workable solution might be achieved with the responsibility for cookie management passing from individual website owners, to the browser vendors (Chrome, Firefox, etc). If that turns out not to be the case, at least hopefully the dust will have settled and there will be much greater clarity on our obligations as regards cookie consent.

In conclusion

I hope this slightly irreverent but hopefully pragmatic approach has provided some achievable steps to help you to feel more in control and less daunted by GDPR as applied to your ultra simple website. If your website is not quite so simple however, or if you would like assistance to identify the cookies used by your website, as well as any other potential areas of concern: contact me for a quote.

I started this series with a long, hard look at the implications of privacy laws for websites that use Google Analytics, and came to the conclusion that if the only cookies your website is setting are for Google Analytics, you don’t have too much to worry about (though there are a few small things you can do to be squeaky clean compliant). But what if your website uses other cookies too? How would you even know what cookies your website uses?

Let’s first find out what cookies your website is using

Personally I have been using a combination of several tools:

  • Attacat’s free cookie audit tool is a free Google Chrome extension, made in Scotland just like me 🙂 If you don’t use Chrome, there may be a similar tool available for your browser of choice
  • Cookiebot’s free compliance test will scan 5 pages of your website and then email you a very handy list of all of the cookies it detected, with some useful information about each. As it is limited to 5 pages, it may very well be missing some cookies, but for many small, simple websites, all of the cookies that are going to be set, will be on the first page.
  • I also use my browser’s in-built tools. To find out how to view and manage cookies in your browser, try a search for “view and manage cookies in Firefox”, for example. Here is a great tutorial for Google Chrome. The audit tool simplifies the process, but the principle is always the same:
    1. Delete all cookies from your browser (I would also suggest deleting browser cache first as cached files can set cookies)
    2. Browse your website as any visitor would, making sure to use all available functionality
    3. Check to see what cookies have been set during your browsing session. As you deleted all cookies before you started, any cookies that now exist will have been placed by your own website

    So what to do with that information?

    Now that you have a list of cookies that your website is setting, it’s time to figure out what they all do, if they are really necessary, and if any of them are spying on your visitors! Having this information to hand will allow you to find a way to remove the offensive ones and to document the others in your privacy policy.

    Having been through this process with quite a number of websites now, here are some of the more innocent cookies that I see again and again. These just need a quick mention each in your privacy policy:

    • Various Google Analytics cookies (no surprise, not essential but inoffensive)
    • Google ReCAPTCHA – here’s some information on that
    • Google Fonts and Google Maps – anything that ends in .googleapis.com is probably just serving content, such as fonts and maps. Google state that the data they gather from these cookies is used purely in order to provide the service, and is handled separately from any other data they hold on individual users.
    • Various functional and essential cookies, used by Woocommerce shopping cart
    • Various functional and essential cookies, used by Shopify shopping cart
    • wordfence_verifiedHuman and wfvt_xxxxx, set by Wordfence, inoffensive but easily disabled in Wordfence settings
    • PHPSESSID – various uses, nearly always essential to function
    • __cfduid – essential cookie, set by Cloudflare for security purposes (on websites that use Cloudflare directly, or perhaps use resources that use Cloudflare)
    • DYNSRV – essential cookie, set by the web hosts of some cloud hosted websites, used to manage server load
    • Cookie set by whatever script is used for the cookie popup banner to remember preferences

    And here are a few that will require a bit more explanation to your visitors, and possibly prior consent:

    Anything that includes Addthis, Sharethis, Addtoany, etc

    These caught me by surprise and I’m certain they’ll catch a lot of others out too. If you have social sharing buttons on your website, of the sort that link straight to the social networks to allow visitors to share your content on their accounts, they are probably spying on your visitors. There are some alternatives available that do not set cookies (such as Jetpack for WordPress), but, not being satisfied with any of them, I have ended up creating my own plugin that won’t slow down the website and does not use any cookies. The one that really had me scratching my head was a Google Analytics plugin for WordPress that was installed on 3 of the sites I have checked so far. The plugin was created by Sharethis, but even deleting the plug-in did not remove the cookie. The plugin had to be first set to “disable all functionality” and then deleted. Naughty!

    Facebook

    Have you installed a Facebook pixel on your website to track your visitors and retarget them with Facebook ads?  If so, it should come as no surprise that Facebook are planting cookies on your visitors’ devices. The question is how to disclose this to your visitors in a way that is fair to them, compliant with the law, and without depriving you of a marketing channel. You could:

    • Go the whole hog and use a sophisticated cookie popup banner (like Cookiebot as mentioned above for example, or perhaps Cookie Notice plug-in for WordPress) that will allow you to apply the pixel script only after the visitor has given their explicit consent. You’re likely to find a lot of people will not give consent – why would they?
    • Have the pixel script run regardless, but make it very clear in your cookie popup that they are being tracked, and give clear information in your privacy policy about how you are tracking their behaviour and what they can do to opt out. More on this in another post. Possible arguments in favour of this approach are that the alternative could be very damaging to your marketing, and that it looks likely that the new e-Privacy Directive will make this sort of consent manageable by the user in their browser, rather than on individual websites.

    Google AdWords, AdSense, any sort of Google advertising

    If you are using Google AdWords or AdSense rather than straightforward Analytics, you will find yourself in very similar territory to users of the Facebook Pixel and can expect to see a lot of cookies. Google use many different domains for this, including some that sound nothing like “Google”. Look out for “doubleclick” for example.

    YouTube & Vimeo

    If you have embedded YouTube or Vimeo videos on your website, did you know that they will be placing their cookies on your users’ devices? You may decide that the best you can manage is to mention this in your privacy policy, but if you would like to embed the content without the cookies, here is some information on how to go about it. Frankly, if a privacy policy mention is good enough for the BBC, I think it will be adequate for most of  us, especially where the alternative is so difficult to implement.

    In Conclusion

    I am a web designer, I handle web technology all day, every day, and it has taken me hours and hours of research to gather this information. What that tells me is that the average small business owner is not going to come close to this level of understanding and compliance on their own. Part of the problem is that as things currently stand (5th April 2018), the introduction of the GDPR is quite imminent, and the updated e-Privacy law is lagging probably at least a year behind. By the time that new e-Privacy law does come in to effect, it is widely anticipated that very many of the current cookie related obligations faced by individual website owners, will be passed to the browser vendors (Firefox, Chrome, Edge, et al).

    This is to say that, if you can demonstrate that you have made a reasonable effort to understand and to comply with both the GDPR and existing electronic data laws (PECR in the UK), it’s probably quite safe to sit tight and wait for the e-Privacy law to come in to effect before worrying a great deal about complying to the letter of the law. On the other hand, if compliance is very important to your business, and you would like assistance to identify the cookies used by your website, as well as any other potential areas of concern: contact me for a quote.

The GDPR is coming! You may have noticed. Tasked with bringing 20+ websites in to line with the new legislation by the 25th May, I have been up to my elbows in GDPR recently and have found it astonishingly difficult to find authoritative answers to anything beyond the very broadest of questions. While the quantity of articles already written on the subject is naturally very high, the vast majority simply regurgitate a very high level overview of what the GDPR (General Data Protection Regulation) is, normally seasoned with some shock headlines about the eye watering fines that may be imposed for non-compliance.

And so this is not one of those posts. For an overview of the GDPR, the ICO would be a good start. It does not, sadly, provide all of the answers, but at least avoids the scaremongering and misinformation that is so abundant elsewhere. In this series of posts, I will document whatever information I have found to my more specific questions about the nuts and bolts of how my clients’ websites (and my own when I get around to it) can comply with the new regulations. At the bottom of each post will be a small section (subject to revision) that will show the solution I have arrived at. In this particular post, on Google Analytics, I’m shocked at the volume of information I have had to sift through to come to a reasonable understanding of why the solution really doesn’t require much change, if any. It should be clearly understood that I am not a lawyer and none of this constitutes legal advice. Or any sort of advice!

Google Analytics uses Cookies 🙁

First on the hit list – Google Analytics. I’m pretty sure every single website I manage uses Analytics. Analytics does use cookies, and cookies are frightening people just now. Google Analytics cookies are responsible for the vast majority of those annoying cookie banners we have all become blind to now. Without Analytics, millions of small websites would not use any cookies at all, and would be exempt from displaying the cookie banners.

But the GDPR isn’t really about cookies

But there is an important piece of information that is missing from almost every GDPR overview I have read. Cookies are mentioned just once in the 99 articles that make up the GDPR, and then, only those that store personal data are implicated. Which Google Analytics cookies don’t** (sort of – see caveat below). To comply with the GDPR you probably don’t have to do anything different where Analytics are concerned, because the UK law that governs the placement of cookies on a user’s computer is, and continues to be, the Privacy and Electronic Communications Regulations (PECR –no sniggering), which is derived from the EU e-Privacy Directive.

Things might even get easier

Now the e-Privacy Directive is certainly getting a good shake up, but the revised laws will not be implemented until 2019 and until then, apart from some leaked details, we don’t yet know what to expect, and will just have to continue to comply with the existing laws. However, those leaked details sound very encouraging in that it looks likely that the browser vendors (Chrome, Firefox, Edge, et al) may be expected to be the vehicles to give the user control over their cookies, sparing website visitors countless annoying popups, and website owners and managers the need to implement the banners, and the degradation of the customer experience that results. I certainly hope that will be the case.

But until then

In the mean time, how do websites that use only Google Analytics and nothing more intrusive, comply with the existing laws for the next year or so? I’m afraid you probably ought to hang on to your annoying cookie banner for now, and you will certainly want to get your privacy policy up to scratch. Let’s be clear that in the case of Google Analytics, the question is not one of personal data; the reason you should display the information is because Google Analytics places cookies on the user’s device and then they, a third party, process the (non-personal) data that they receive from it. And that I’m afraid, does require consent, as it has done since 2011.

So how do we get consent?

Well yes that is where it all gets a bit vague, and where the GDPR does get involved a little bit. Under GDPR, consent should be explicit and not implicit, as was the case previously. But explicit consent does not necessarily require the tick of a box or the click of a button – a gesture such as scrolling or browsing to another page on the website are accepted as explicit consent, on condition that the user was informed of the use of cookies, provided with the opportunity to find out more detail about their use, and clearly informed what actions on their part will be taken as consent. All of this can easily be incorporated in to the cookie popup banner.

Should consent be obtained before Google Analytics cookies are placed (prior consent)?

What I have found trickier to navigate is the concept of prior consent, particularly in the context of inoffensive little cookies such as those used in Analytics. In other words are we permitted to place cookies on the user’s device in anticipation of their consent being given? The logical answer of course would be no! If consent is required in order to place cookies, the cookies must not be placed until consent has been obtained. In fact this is only partly a GDPR problem, in that GDPR will apply equally to all EU member states (and the UK). In some countries in the EU, prior consent is already required, though rarely implemented, because it is so difficult and obstructive! There are two problems with this approach:

  1. Prior consent requires a solution that is more technically advanced than most cookie consent banners I have encountered to date. In most cases, it requires that whatever script is responsible for the cookie consent banner, is also responsible for placing the scripts that place the cookies (e.g. your Google Analytics tracking code), only once consent has been obtained. In other words, you can’t just paste your Analytics script and your cookie script in to your web pages separately. They need to work together in some way.
  2. If we do this with Analytics code, our Analytics data will be substantially altered because we will not be able to register first time users who only visit a single page. We will only be able to start collecting data about their visit once they navigate to another page. This will mean we can no longer monitor and address our bounce rate, and could prevent any sort of useful tracking of responses to links in social media for example.

Personally, I feel a little pragmatism is called for. Here are the reasons that I don’t think I will be recommending that people who use Analytics tracking should be forced to obtain prior consent. Of course, once again, I am not a lawyer and this is certainly not legal advice, we all have to find our own solutions:

  1. Analytics cookies are un-intrusive, collect no personal data and pose no risk at all to the user. In short, they are not what the GDPR, PECR, or ePrivacy are there for. In spite of the scaremongering about fines, the ICO themselves have made it very clear that fines will be a last resort, in cases where people’s personal data has been misused or put at risk.
  2. It will be difficult and costly for many small businesses to implement a new solution that does gain prior consent.
  3. If they do so it will degrade the usefulness of their Analytics data.
  4. In 2019, the new ePrivacy directive should hopefully solve this problem once and for all by taking it off your hands and giving it to the browsers to deal with.

**That little caveat about personal data

Standard analytics code and cookies do not process any personal data, with one very marginal, borderline exception. The user’s IP address, although not available to you in your Analytics data, is sent to Google and could, maybe, theoretically be seen by Google employees. IP addresses are used to provide geographical data about your users, so you can see what country people come from, but not their actual IP address. There is a way around this though, if it bothers you, which is to adjust your Analytics tracking code to anonymise the IP address before it is sent to Google. This may have a minor impact on the accuracy of your geographical data, but that’s all. Here is some more information from Google.

Just one last point on personal data – while Google Analytics is not itself set up in a way that processes personal data; in a few rare instances, it is possible to inadvertently send them personal data, and if you are doing so, you need to stop it right now! But you’re almost certainly not. An example scenario may be a custom developed membership website that uses email addresses in the URL strings of publicly accessible pages. It’s bad practice anyway, contravenes Google’s own rules, and would also be in contravention of GDPR.

Finally – my solution where only Google Analytics cookies are used

  1. Because I will be providing this as a service and want to be thorough; because it won’t take me too long and won’t have a detrimental impact, I will be adjusting Analytics code to anonymise IP addresses before sending to Google. Here’s how.
  2. Where no other cookies (at least no intrusive ones) are set by the website, if they are already adequate, I will continue to use whatever cookie popups are already in place, ensuring that they state clearly how continued use of the website will constitute acceptance of cookie use. The same banner will also include a link to the website privacy policy. For WordPress users, Cookie Notice is good and can also be used if necessary for those situations where prior consent really is required.
  3. I will be checking that the privacy policy exists, is easily accessible, that it clearly states that we use Google Analytics cookies to collect website data, and why, and providing a link to more information about cookies and how to disable them. Here is a good example of such a link.
  4. As I will be modifying the Analytics tracking code anyway for IP address anonymisation, I may also implement a direct opt out link in the privacy policy, which also requires some modifications to the tracking code. More information from Google on that. Then again, with this solution, the cookies are still set, but just don’t send any data, so I’m not sure it serves any useful purpose.
  5. Don’t panic. As stated, Analytics tracking is really not what any of this is about. So long as you demonstrate at least some effort to comply, it will almost certainly be adequate where you are not in fact handling personal data, as is the case with Google Analytics.