Getting rid of google fonts/services on alaveteli #GDPR

[laurent...@gmail.com]

Hi all,

We switched to self-hosting the google provided fonts that alaveteli uses in the standard theme (we had customised it, but kept the fonts). This is in big part to be in line with GDPR, as it would require us to ask users for consent before loading them, which is horrible UX.

We've had some users complain they didn't want their data on our site because of our use of google services.

In case this is something you stumble on, this issue shows how we did it:

https://gitlab.com/madada-team/dada-core/-/issues/110

We're also aiming to get rid of google recaptcha, but haven't found any good alternative. Again, mostly a GDPR thing, as we've found that any miscompliance with the law on our site is used as an excuse to avoid answering requests. If you have any tips, I'd be very grateful.

As a bonus question: are there any better ways to share (tech) solutions like these between the various sites? In my dreams, each improvement we make in code would be pushed upstream to alaveteli so that all sites benefit, but in practice, it's often a lot more work than just fixing our own problem and moving on. Which is why I'm posting this, as I suspect it might be useful to others. But I also feel like we can't all just spam the list with "hey I fixed X" type messages :)

Thanks for your thoughts!

Laurent / madada.fr

[Petter Reinholdtsen]

[Laurent]

> We switched to self-hosting the google provided fonts that alaveteli uses
> in the standard theme (we had customised it, but kept the fonts).

Do not really have much to offer regarding integrating the changes
across all sites, but just wanted to say *Thank you very muuch* for
doing this to protect your users from the data gathering actors on the
Internet.

I believe it should be obvious that it is the right thing to do, but
sadly to many it is not.

Did you also get rid of the Google Captcha?

--
Happy hacking
Petter Reinholdtsen

[Gareth Rees]

> This is in big part to be in line with GDPR, as it would require us to ask users for consent before loading them

Copying some internal write up of when mySociety discussed this…

Earlier this year we discussed the use of Google Fonts on our sites following reporting on a case in Germany where a company was fined a nominal amount for using Google Fonts without seeking user authorisation or having a legitimate interest as the user's IP address is exposed to Google when the font is served.

Our conclusion at present is essentially that we'll not make any changes as Google assures Fonts data isn’t used for tracking or combining with other Google datasets, and if we take the stance of believing they’d break that promise, then by extension we should simply be withdrawing from all Google services (including "cookie-less" Google Analytics), since we can’t trust them to follow their word in those services either.

> We're also aiming to get rid of google recaptcha, but haven't found any good alternative

We have a stub issue around this [2] but similarly I don't know of what we could replace it with.

> As a bonus question: are there any better ways to share (tech) solutions like these between the various sites?

In this case you could essentially make a pull request of your changes to alavetelitheme [1] so that new installs get self-hosted fonts. Wouldn't object to this at all; it's just not been a priority for us. Other sites would then have to apply the changes themselves on their own themes, which is a bit of a pain, but much less difficult than figuring it out from scratch.  Ideally you'd make it as a single commit, as that way a git cherry-pick / git patch apply has a higher chance of Just Working. 

> pushed upstream to alaveteli so that all sites benefit, but in practice, it's often a lot more work than just fixing our own problem and moving on

I don't think there's a great way around this. Just like democracy, the more people you serve and the more fundamental the changes you're making, the more scrutiny and time they take to integrate.

We really appreciate all your contributions so far! [3]

> I also feel like we can't all just spam the list with "hey I fixed X" type messages

Even linking between our issues [4] and your issues / fixes would be really valuable. That way we can see if we can apply your improvements to Alaveteli. It's often not possible due to our current focus, but at some point we'll get to them – for example, we've finally had some funding that's enabled us to tackle a 9 year old issue! – so having a leg up when we do get to them is just as useful.

Best,

Gareth

[1] https://github.com/mysociety/alavetelitheme
[2] https://github.com/mysociety/alaveteli/issues/5995

[3] https://github.com/mysociety/alaveteli/commits?author=laurentS

[4] https://github.com/mysociety/alaveteli/issues/

[5] https://github.com/mysociety/alaveteli/issues/1005

[Petter Reinholdtsen]

[Gareth Rees]

> Our conclusion at present is essentially that we'll not make any
> changes as Google assures Fonts data isn’t used for tracking or
> combining with other Google datasets, and if we take the stance of
> believing they’d break that promise, then by extension we should
> simply be withdrawing from all Google services (including
> "cookie-less" Google Analytics), since we can’t trust them to follow
> their word in those services either.

Reading the Schrems II decision, it seem fairly obvious that the
question is not really if Google will break their promise, and more that
the promise is worthless given the existence of laws allowing secret
court rules with the ability to force Googles hand without them being
able to tell anyone.

I would very much welcome Alaveteli to move compltely away from all
Google services and keep the user information away from all the big
techs eyes.

[Laurent Savaëte]

> As a bonus question: are there any better ways to share (tech) solutions like these between the various sites?

In this case you could essentially make a pull request of your changes to alavetelitheme [1] so that new installs get self-hosted fonts. Wouldn't object to this at all; it's just not been a priority for us. Other sites would then have to apply the changes themselves on their own themes, which is a bit of a pain, but much less difficult than figuring it out from scratch.  Ideally you'd make it as a single commit, as that way a git cherry-pick / git patch apply has a higher chance of Just Working.

I'll put that on my todolist. Not urgent though, given how often a new alaveteli site pops up :)

As a potentially more immediately impactful PR, would you be interested in the same PR against WDTK theme? https://github.com/mysociety/whatdotheyknow-theme seems to be the repo you're using?

> I also feel like we can't all just spam the list with "hey I fixed X" type messages

Even linking between our issues [4] and your issues / fixes would be really valuable. That way we can see if we can apply your improvements to Alaveteli. It's often not possible due to our current focus, but at some point we'll get to them – for example, we've finally had some funding that's enabled us to tackle a 9 year old issue! – so having a leg up when we do get to them is just as useful.

Noted, I've tried to do that wherever I found a relevant issue.

[Gareth Rees]

As a potentially more immediately impactful PR, would you be interested in the same PR against WDTK theme? https://github.com/mysociety/whatdotheyknow-theme seems to be the repo you're using?

That is indeed our theme repo.

Thanks for the offer. I think we’re happy with Google Fonts at the moment because we don’t believe there’s a privacy implication for us, and self-hosting would lose the CDN performance benefits, which may be material at WDTK’s scale. I’ve also considered removing custom fonts entirely for WDTK.

Will certainly circle back to this if and when we decide to review this position.

Here are some further notes from when we investigated this:

We’ll want to make sure that our servers are set to serve the fonts with long cache policies, eg:

Cache-Control: public, immutable, max-age=31536000

Since the font files are unlikely to ever change, we could consider very long, or even infinite, cache times.

We’ll also want to pre-load the font files, alongside the CSS, to speed up rendering, eg:

<link rel="preload" href="/whatever.woff2" as="font" type="font/woff2" />

I’m definitely not up to date on webfonts, so not sure if your code already does this.

Even linking between our issues [4] and your issues…

Noted, I've tried to do that wherever I found a relevant issue.

Thanks!

--

Gareth Rees

[Laurent Savaëte]

Thanks for the offer. I think we’re happy with Google Fonts at the moment because we don’t believe there’s a privacy implication for us, and self-hosting would lose the CDN performance benefits, which may be material at WDTK’s scale. I’ve also considered removing custom fonts entirely for WDTK.

Understood. Thanks for sharing.

Will certainly circle back to this if and when we decide to review this position.

Here are some further notes from when we investigated this:

[...]

I’m definitely not up to date on webfonts, so not sure if your code already does this.

Not yet, but it's on my todolist. I've setup fonts so that they are processed with other static assets, so they get a fontname-digest.woff2 filename. That way we can add infinite cache times on them without second thoughts. I just need to tweak the webserver config. Hopefully this should help with the scale issue, although we don't really have this yet!

I'll link all those changes to the tickets mentioned before, in case it can be of use to anyone else.