Monthly Archives: April 2018

Apr 16

Major Chrome SSL certificate issue – Could your site now be insecure?

By Graham Hansell | Trust & Technology

 

Chrome is not accepting Symantec SSL certificates from the 17th April 2018. Check and update your certificate ASAP.

Reading time: 3 mins 40 sec

As from the 17th April 2018, your website might just be about to go insecure with all Chrome users – Google Chrome will no longer be accepting the Symantec SSL certificate.
To put this into context, this could affect ‘one out of every two’ of your customers – as powerful as that sounds Google Chrome is used by over 50% of the worlds Mobile, Tablet and Desktop web browsers, now I’ve got your attention best you read on…

Here’s the story so far, Google has fallen out with a company called Symantec over the leaking of private keys of secure domain certificates.
You probably never noticed or even +heard of it, but this particular spat has had a butterfly effect that we will all feel from today.
You could see this as another example of how the Web has fallen into the powerful hands of just a few companies (Facebook, Google, etc.) but it seems to be in this case that Google has been right in not trusting Symantec. 

Google Chrome developers have decided to ignore all secure certificates from the following issuing authorities:

  • Thawte
  • VeriSign
  • Equifax
  • GeoTrust
  • RapidSSL

This means if your website has a secure certificate issued by one of these companies it will become useless to your website for all Chrome users.
The result will look something like below when they go to your domain using the Chrome browser (by any means not just search!).

SSL certificate distrusted by Google Chrome and other major browsers

This doesn’t look like the start of a happy visit, does it?

To give you some context, Chrome makes up over 50% of the worlds Mobile, Tablet and Desktop web browsers, so having this happen in Chrome is a big deal.

Google Chrome is the most popular browser worldwide

Chrome Rules the World

Yes, Google Chrome is represented by Green in this World Map from 2017. In addition to the coming of GDPR, secure websites are even more important as anytime any personally identifiable information (PII) is being handled by a company it needs to be secure. Therefore any enquiry form should be secure, not just e-commerce sites.
The timeline for this has been-

  • 15 March 2018
    • On or around March 15, 2018, a Chrome 66 beta release will distrust all Symantec SSL/TLS certificates issued before June 1, 2016.
  • 17 April 2018
    • Google plans to release the public version
  • September 13, 2018
    • a Chrome 70 beta release will distrust all Symantec SSL/TLS certificates issued after June 1, 2016.
    • Google plans to release the public version mid-October 2018.

To get a size of the problem a test was done in February showed of the Top Alexa sites one million websites, 11,510 are going to go insecure in April, with another 91,627 on going to be hit in October. You can see a quick test of those that were using Symantec SSL all have updated since.
Those included:

 

Testing the traffic impact

In Google Analytics you can test your traffic to see if the new Chrome 66 version browser is getting impacted quickly with a custom segment.

  1. Go to Google Analytics and login
  2. Select the Audience Overview Report
  3. Google Analytics Audience Overview
  4. Create a customer segment for Google Chrome Users
    Custom Chrome Users Segment Analytics

    Just add a Custom Segment for Google Chrome and even try Version 66

Once you have done this look at the daily Chrome Browser traffic for today by the hour compared to the previous day, is there a change? Then compare to the same day the previous week, again any change?

If you are seeing a constant drop hour on hour this could be the insight that your SSL certificate is scaring people using Chrome away.

Your next action is to prove it is your SSL certificate causing the problem.

Is your SSL Certificate affected?

This is technical and if you have a web developer/agency or site support team it is best to talk to them first but you can test free of charge yourself using the links below.

First step is to test if your certificate is at risk.

There are a few options and it is worth testing on a couple of services as they are all free of charge.

Hopefully, you find everything is up to date (normally using Digicert or Comodo) but if not your team will have to fix it ASAP!

How to fix your SSL certificate for Google Chrome

Options are to move to upgrade with the new company who owns the Symantec SSL business (DigiCert) or move to another provider for free.

Or you can use the free upgrade from Comodo

Or replace your certificate for free with this open source service (backed by Google Chrome)

Once you have updated your certificate then it might be interesting to test others, check your competitors, see if they’re secure or are they going insecure for Chrome browser uses? If they are what tactics could you use to capitalise on it, it if you’re feeling friendly how about telling them? Remember – Knowledge is power

Checklist:

  • From 17th April 2018 Google Chrome stops accepting some Symantec SSL certificates
  • October 2018 all Symantec SSL certificates will be ignored
  • eCommerce sites and any sites using lead generation forms will need to be secured (GDPR requirement)
  • Check your site’s certificate is going to be secure
  • Check your competitors

Confused? Concerned? Not getting the help you need?

Apr 12

Google Analytics & GDPR – how to be compliant?

By Graham Hansell | GDPR & marketing

Is GDPR going to kill your company’s Google Analytics?

Reading Time: 6 mins 6 sec

OK, I get asked by a lot by clients when I’m training “will  still be legal after ?”.

With the follow up question “do I need all users to opt-in so you can track them?”.

These are two good questions so I’ve put together a review of the current understanding and what needs to be done.

Please note this is not legal advice and you need to talk to your own counsel to understand your company’s position depending on your set up.

If you need help with preparing your company for GDPR then SLX has partnered with LawBite’s low-cost GDPR documentation and review service.

GDPR is not a problem for Google Analytics, however E-privacy changes in 2019 will be.

To clarify, the law that will impact Google Analytics in most installation cases will not be GDPR, because GA stores very limited   – personally identifiable information and GDPR is designed to protect PII . In most Google Analytics installations PII is only stored in certain specific circumstances. You still have to check that your version of GA is GDPR compliant but it is not going to kill its use.

Coming soon – ePrivacy Regulations

However, the law that will impact Google Analytics will be ePrivacy regulation but that isn’t ready yet (it was going to launch with GDPR but has been delayed due to negotiations).

We will be covering more on the development of ePrivacy Regulations later so stay in touch with SLX on our social media spaces where we’ll notify you through our future newsletters.

Ok, so when does GDPR impact Google Analytics?

We need to start with what GDPR is focused on – personally identifiable information. And that means any data you can identify a real natural person. IP addresses and unique ID’s can all be combined to identify the real person and so have to be considered as PII.

A standard installation of Google Analytics doesn’t expose these in the standard report, instead it reports on volumes of site sessions, pages viewed and has data thresholds in place to stop drilling down to an individual visitors behaviour.

However there are ways where Google Analytics can trip you up with GDPR.

For full compliance, your company needs to be able to audit/confirm that Google Analytics is not storing PII.

Let’s start with what PII can be stored in Google Analytics.

The circumstance for PII in GA vary from the hidden (IP) to the obvious (Customer ID) but can be boiled down to:

  • IP addresses – visitors IP address are collected
  • Form URLs – this can have PII data shown in URLs
  • Tracking Users with User IDs – could be seen as PII
  • Customer data – is obviously PII if you have their details in there

In each of these cases, you need to check, then document and remedy your installation of GA to stop this tracking without consent by 25th May to stay comfortably legal or seek authority from users to continue this kind of tracking through your privacy policy.

PII in IP addresses.

These are tracked automatically by GA but aren’t exposed via any of the reports or through the API, so we are safe, aren’t we?
No, it turns out legally we may not be if you are a special category data controller processing this type of information:

  • race
  • ethnic origin
  • politics
  • religion
  • trade union membership
  • genetics
  • biometrics (where used for ID purposes)
  • health
  • sex life
  • sexual orientation

As a company, you are a Data Controller, and Google is a Data Processor. In this special category relationship, the Data Controller must protect the data subject from the Processor’s risks.

As Google states in its new Data Processing Amendment

7.1.2. Security Compliance by Google Staff. Google will take appropriate steps to ensure compliance with the Security Measures by its employees, contractors and Subprocessors to the extent applicable to their scope of performance, including ensuring that all persons authorized to process Customer Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. 

The risk is that users IP addresses could be accessed by a Google employee and that is used to track users (this is an outlier risk as it would take a rogue employee to be part of the GA team).

If you are processing special category data through Google Analytics you may consider “hiding” the IP of visitors from the system

There is a tool provided by Google (yep who knew) but thanks to the German privacy requirements this has been created and is available here.

This tool stops the IP being fully recorded to disk in the Google Analytics Collection Network and instead removes the last digits from being stored.

Its use could cause less accuracy at country and city level reporting but its a small penalty.

The other downside is many companies filter their reports by IP to remove visits and activity from their internal users. By using the German tool it will remove your ability to remove users at an IP level which will change the numbers in your reports,  Therefore if your reports are relying on removing internal IP addresses from reports do this in a test view and filter before adding it to your main view.

PII in Form URLs.

Now, this is definitely a rogue CMS issue rather than a direct intentional PII data collection.

When users complete sign up forms or sign into an authorised area, some CMS systems pass PII within the URL, that URL will be passed to GA and recorded in your reports.

This is bad practice, it breaks GA service level agreement (no PII to be stored in GA duh!) but has historically been ignored as webmasters just saw it as junk data.

However, come GDPR this will make your GA illegal!

So to check your Google Analytics do this:

  • GA – behaviour-all pages
  • Now there is no hard and fast rule (as CMS’s will behave differently) but test Filtering on:
  • Email sign – @
  • Common names – Sarah, Karen, Jane, Rebecca, John, Richard, David, Paul
  • Is there a form posting – form, post, get

Please note this list is for starters please share any thing you find that matched in the comments box below please so I can update this post and help everyone out.

So is anything coming up?

  • No – great another GDPR box ticked off
  • Yes – you will need to create a new view which filters or fix alternatively contact your developers to correct the CMS, quick!

To correct this problem contact the website developer and ask them for a solution to prevent this happening.

A further note on this, we are investigating if it is necessary to remove old data prior to 25th May 2018. If it is then you may need to start a new Profile! More to follow on this….

UTM tagged campaigns.

We all track campaigns in Google Analytics, and you might have specialist tags for specific Source, Medium, Keyword, Campaign, Content. Check that these don’t contain PII especially an email address or name.

To do that look at your campaign report, you can ignore Google Adwords campaigns unless your naming scheme is particularly specific (people level!)

More PII in Google Analytics.

Google Analytics User tracking and PII.

When “Users” have been turned on in settings, Each User will have a unique ID generated by GA and this can be seen by this report:
Google Analytics Audience > User Explorer Report

User Report - Google Analytics

If you want to see a report that shows tracking a real person – this looks like it to me!

Obviously, if you are covered by consent or legitimate interest then you can continue but otherwise, it could be seen as a GDPR risk.

To disable this you will need to stop tracking users, which is done by:

  • Admin > Profile
  • Property Settings
  • Scroll down to User Analysis and make sure it is off

This will have the added benefit of stopping the use of a couple of cookies (_ga/_gid), technically there two but most people don’t tend to use the other one.

Update – Google Analytics has recently released a new tool to allow for user and event data to have a “lifetime” in Google Analytics of between 14 months and just over 4 years. If you are going to continue with the user function you should strongly consider this as it will demonstrate that you are no holding data for  “no longer than is necessary” part of GDPR.

Injecting data into Google Analytics

And finally if your company activity stores customer data in GA by injecting data from other sources which could be any of these:

  • CMS
  • CRM
  • Customer Dimensions / Metrics
  • Customer ID

This will normally be handled by a bespoke development that will have been an IT / Developer project and therefore it should be known what it is doing, how it works and how to fix it.

You will need to go talk amongst your marketing, legal and developers on the legal coverage for using this data and if it needs to stop.

Google Analytics and GDPR Summary:

These are the key points to take out of this post, but as I said before, your company needs to make its own decisions and most importantly document them.

  • Google Analytics in its standard set up is pretty GDPR / PII compliant
  • Risks vary from low to high depending on how customised your installation of Google Analytics is
  • To improve the standard set up look at:
    • Anonymising IPs
    • Check and remove PII in URLs
    • Turn on Data retention limits for User and Event data
  • Check if PII is intentionally being stored and consider that this breaks GA Service Level Agreement and what legal right (consent / legitimate interest) you may have to hold that data

If you have a custom GA setup using known PII then you have 4 options

  1. Get users to give consent to use it
  2. Build a legitimate interest case for it
  3. Remove it
  4. Anonymise it

Also, remember you could be breaking the Google Analytics Service level agreement by storing PII in there!

Please remember none of this is legal advice, do your own research and if you need help SLX can do a full GA GDPR (email and other systems) audit for your company.