Graeme Johnston and James Friel / 15 February 2022
We published a short article recently about how to establish a conveniently administered website with modern graphics but no cookies. Quite a few people have told us they found it useful.
This article covers two more practical privacy-related topics we had to address. They’re not unique to us, so we’re writing this in the hope that it may be useful to other people developing or improving a website.
As with so much in the tech world:
- The points are not obvious if you don’t already know about them.
- Once you do know of them, it may not be clear how to fix them, depending on how technically-minded you are.
- Once you know both these things, actually doing it can still be a little fiddly.
This article seeks to help with all three points.
Bear in mind, as noted in our recent piece, that we’re using WordPress and Elementor for our website, and that the precise steps (e.g. the buttons to press) may well vary over time: products change.
First issue: JetPack tracking pixel
WordPress comes packaged with a product called JetPack. This is designed to help with the security, performance and growth of a WordPress website. It include an analytics feature called Site Stats.
By default, Site Stats sets a tracking pixel when someone browses a WordPress / JetPack site. This isn’t picked up by some browsers. However, it is flagged by, for example, the specialist privacy-focused browser, Brave.
We wanted to remove this:
- As a matter of business and ethics, we don’t want to be tracking people.
- As a matter of UK law, cookies isn’t a defined term, but the relevant legal language prohibits storing information on people’s devices without explanation and the option to refuse, unless strictly necessary to deliver the service requested (PECR, article 6). ICO guidance is that analytics aren’t “strictly necessary.”
How to fix the JetPack tracking pixel issue
- Visit the Jetpack dashboard on your website’s WordPress admin page
- Scroll down to the bottom of the page and select “Debug” in the footer
- Even if Jetpack tells you that your setup “looks a-okay!” ignore that reassurance
- Choose “the full list of Jetpack modules available on your site” option at the bottom of the page.
- This should bring up a long list of options. Find “Site Stats” and disable it.
- Verify: use Brave or another method of your choice to check that there are no more “Cross-site trackers and other creepy things” – as Brave puts it.
Be warned: Jetpack will nudge you to re-enable Site Stats. Repeat the above steps if you accidentally do so.
Second issue: Google Fonts
Google Fonts is used by most websites, including ours.
By default, using it stores information on the device of a person browsing a site.
Predictably, most websites use that default setting, although it is possible to self-host the chosen fonts.
If you use Safari, for example, to look at such a site, you’ll see these two things under Cookies and Website Data, described as HTTP Alternative Services:
- fonts.googleapis.com
- gstatic.com
These direct the user’s browser to fetch Google Fonts data from those sites, which are controlled by Google. This necessarily discloses the user’s IP address to Google.
The legality of this under GDPR has been disputed, but on 20 January 2022 a Munich court ruled this practice to be illegal if done without the user’s consent or a specific legitimate interest. You can fix this by hosting the fonts yourself.
How to fix the Google Fonts issue
This is how to self host the relevant Google Fonts if you’re using Elementor for your website.
- Visit https://fonts.google.com/ and download the font bundles for the fonts you want to use
- Unpack these files
- Convert the .ttf files to .woff files to improve cross-device compatibility
- In Elementor:
- Add a new custom font e.g “Roboto – Local”
- Upload the .ttf and .woff files for each variant of the font
- Save the new font
- Repeat for each font you want to use
- Use Elementor to edit a page
- Click the hamburger button (☰) in the top right
- Select Site settings
- Select Global Fonts
- Update these options to use the local versions of the fonts
- Visit the various pages of the website
- Track down any items that aren’t using the global fonts
- Edit those components to use a local font variant
- In the Global Theme
- Change the default font to System Default
- Add a new custom font e.g “Roboto – Local”
- Verify by checking the browser’s network tab for calls to fonts.googleapis.com and gstatic.com
Further hints and tips:
- Assuming that your site uses https, make sure that your file uploads point to an https file e.g. ‘https://yourdomainname.com/…/my_font.ttf”
- If you’ve tried that and it still doesn’t work, try these things:
- In Elementor, visit Tools and click the Regenerate Files & Data button
- In Elementor, use the Replace url button to replace “http://” with “https://”
- If it’s still not working, verify that your wordpress and site address under Settings point to “https://your-domain”. If they don’t, edit them to use https
- Text field not editable? You’ll have to do it manually, by editing the wp-config.php file
- Don’t forget to check mobile versions of your page for rogue fonts, as different elements may be displayed on mobile
- Third-party integrations need to be addressed separately e.g. Google’s reCAPTCHA service for contact forms
**
Image by Bia Andrade on Unsplash