reCAPTCHA v3 is loading unnecessary fonts

[galford-tillster]

Hi,

Per the reCAPTCHA V3 documentation we are allowed to hide the badge:

https://developers.google.com/recaptcha/docs/faq#id-like-to-hide-the-recaptcha-badge.-what-is-allowed

However, hiding the badge does not prevent the two fonts used on the badge from downloading. reCAPTCHA V3 downloads two fonts each about 10KB, so that's 20KB of unnecessary data being loaded each time.

We cannot block the request because the CSS is inside the iFrame.

Is it possible to provide a configuration option that will disable the font, or maybe disable the badge altogether?

[shirnschall]

I have the same issue plus google pagespeed insights thinks the text is not visible while loading these fonts.

[khanakia]

I have the same issue because recaptcha loading that roboto font and google pagespeed insights consider it while analyzing

[levipadre]

Same problem here:

[lea-pw]

Same problem. Anybody solved this?

[joaquinvexels]

Same!

[swaranan]

Same problem here.

[federer11]

Same problem here. Any solutions?

[Nincha]

Also interested in resolution for this.

[quadcom]

Classic Google, be the cause of the problem while also dinging us for having a problem.

My site uses Roboto as the fonts already and I host them myself. Now the script goes and downloads another copy of them from Google fonts. Fantastic.

[emendo-web]

Same problem. Hope a option to disable font loading.

[khanakia]

Hi All,

Simply add this to your head and then Google Pagespeed will not complaint

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>

[ansmlc]

Same problem here.

[novvac]

Same problem. Any solutions?

[khanakia]

Same problem. Any solutions?

@khanakia Just use preconnect event google fonts itself suggesting this.

[ansmlc]

Same problem. Any solutions?

@khanakia Just use preconnect event google fonts itself suggesting this.

That doesn’t solve the invisible font issue as shown by @levipadre

Or the fact fonts are still being requested even when they are already self-hosted.

[steve-buri]

I am facing the same problem in reCAPTCHA v2. Google Fonts are always loaded from fonts.gstatic.com. I want them to be loaded from my server.

After taking a look into it, the font-face's are loaded from the inline styles (inside https://www.google.com/recaptcha/api2/anchor).

/* inside the inline styles */

/* cyrillic-ext */
--
  | @font-face {
  | font-family: 'Roboto';
  | font-style: normal;
  | font-weight: 400;
  | src: url(//fonts.gstatic.com/s/roboto/v18/KFOmCnqEu92Fr1Mu72xKKTU1Kvnz.woff2) format('woff2');
  | unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
  | }

Changing the theme parameter to dark or light mode still loads the fonts. There is not any setting in the documentation to switch of the font or CSS.

Is there a way to remove these inline styles?

[mohsinr]

Wow it is almost 2 years since this issue was reported, and still google report this error in pagespeed, no way to disable or recaptcha developers should have added display:swap parameter so it is not issue anymore in pagespeed.

[gnaaromat]

Plus there was a lawsuit in Germany that makes it potentially illegal to load fonts from google servers. Which in turn makes it illegal to use recaptcha now?!

[alorbach]

any google person here? Cant be that hard to remove the unnecessary font loading from css?! Or make it even optional.

EDIT: At the moment the only option is to get rid of recaptcha :(

[nessor]

Plus there was a lawsuit in Germany that makes it potentially illegal to load fonts from google servers. Which in turn makes it illegal to use recaptcha now?!

Yes. Seems a bit difficult at the moment. Article (in german): https://www.golem.de/news/google-fonts-abmahnungen-an-webseitenbetreiber-mit-google-schriftarten-2208-167472.html

[seanconklin]

Same problem here.

[websuits]

Same, that font is useless, there should be a way to remove or edit that css.

[23tux]

Same here, we already received complaints. Is there no way to remove that font?

[iMartn]

Same problem here we need to change the captcha solution for our customers because of that.

[websuits]

Implemented workaround preventing the initial load and then added a mouse move event to load the iframe, works well for page speed.

[NiklasBr]

@rowan-m you tagged this almost 30 months ago, do you have any progress to share?

[23tux]

Within 2 1/2 years, it went from @galford-tillster's original "20KB of unnecessary data being loaded each time" to legal actions being taken against companies in Germany

[alorbach]

Common Google cant be that hard to come up with a solution?!

[sfritzsche]

Note: It should be possible to block this via the "Content Security Policy": https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/font-src

[23tux]

@sfritzsche I'm not sure if this is right, because the font is loaded from within an iFrame that is rendered by reCaptcha, and you can't set a header for that AFAIK. Have you tried this, if it really works?

[sfritzsche]

@23tux We will implement this only in the next few days, but according to the specification, it does not matter if the resource comes from an iframe or not:

https://www.w3.org/TR/CSP2/#processing-model-iframe-srcdoc

We would also test the "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/child-src" directive.

[iMartn]

@sfritzsche @23tux it seems like it doesn't block the google fonts I tried it with "Content-Security-Policy: font-src ;" So it blocks fonts from other vendors which are not in "font-src". But the google fonts which are injected from the iFrames inline css are not blocked somehow.

[marcelfrenz]

Since the webfont-requests are nested in an iframe, the CSP directive font-src wont work. Is there any progress working on a solution to prevent loading webfonts when using reCAPTCHA v3?

[23tux]

@sfritzsche @iMartn @marcelfrenz I haven't found a good solution so far. I'm thinking about implementing a consent screen the first time a user uses a form that requires reCaptcha.

But this comes with a huge drawback: Because reCaptcha couldn't gather information about the user beforehand, it displays the v2 captcha with all the chimneys, traffic lights and crosswalks for every first time user (or users coming from incognito windows). Definitely a conversion killer!

And all thanks to loading a single font file that isn't event used... *facepalm-intensifies*

[sfritzsche]

@marcelfrenz Did you really check this 100% ? (Link 1, Link 2) I only ask because it would absolutely baffle me if that were the case. I absolutely cannot imagine a panel from the W3C getting together, specifying these security things, and then them not working as intended. And iframe-ressources, in my opinion, should have been considered.

[myyxl]

@sfritzsche I used the follwing CSP header and it seems to work just fine: Content-Security-Policy: child-src 'self';

[marcelfrenz]

Sorry for the late response.

@sfritzsche At least in my test scenario the following URL (shortened) was dynamically injected as src for an iFrame: https://www.recaptcha.net/recaptcha/api2/anchor?{...}.

The response document contains, among other things, style-definitions in which font-faces are defined, hosted on fonts.gstatic.com.

In Chrome Dev-Tools Network-Panel (some) of these font resources are loaded with "Initiator" pointing to the above mentioned document.

The host document itself contains the following CSP (used for testing).

<meta http-equiv="Content-Security-Policy" content="font-src 'self';" />

Should block all requests except 'self'. This is not working as intended - still loading fonts from fonts.gstatic.com.

---

@myyxl setting child-src to 'self' prevents/blocks the iFrame from loading https://www.recaptcha.net/recaptcha/api2/anchor?{...} and of course as a consequence also the fonts - for me this is not working because reCAPTCHA itself should not be blocked.

---

Quite possible that I have made mistakes in the test scenario.

[rafczow]

I`ve tried the solution suggested by @sfritzsche to use CSP. Here are my findings.

❌Content-Security-Policy: font-src 'self'; Font from another cdn is blocked while gstatic still gets to pass. Important mention is that blocked one is not loaded by iframe but in head (im not sure if thats a problem here tho),

❌Content-Security-Policy "child-src 'self';"; This will of course cause recaptcha to not work at all. Notice that error says refused to frame https://www.google.com/ but source on the right says www.gstatic.com

So what if we try to just allow google.com like this: ❌Content-Security-Policy "child-src https://www.google.com/;"; Should still block all other domains right? Wrong. Recaptcha will be working again but you get resources from www.gstatic.com as a bonus:

I`ve also tried to play with the iframe sandbox argument but without success.

---

Within 2 1/2 years, it went from @galford-tillster's original "20KB of unnecessary data being loaded each time" to legal actions being taken against companies in Germany

GDPR is the reason I'm working on this and I guess we just have to start looking for alternatives (probably paid options)

[FKautnik]

Hope this will help somebody: The Roboto font is loaded by the script tag in the HTML head with src='https://www.google.com/recaptcha/api.js?render=6Lfll4waAAAAAEO0LOU&ver=3.0' id='google-recaptcha-js'> --> Just search for recaptcha in the code Its possible to stop executing the script. For example, we only execute the script if the user accepts the data policy in the cookie banner. For WordPress users this could be achieved with the Borlabs Plugin (>> Script blocker settings)

[rimmeh]

same problem! In Germany google font loading via cdn is forbidden. The Badge is Loading Roboto. So i had to disable Google Recaptcha on ALL sites.

[FKautnik]

same problem! In Germany google font loading via cdn is forbidden. The Badge is Loading Roboto. So i had to disable Google Recaptcha on ALL sites.

If you have problems with the DSGVO in Germany just let the user accept your data policy first, after this you can execute the recaptcha script so the font is loaded after the user has given his permission

[rimmeh]

I know that yes, but not the lawyers here that sending mass warnings. I just want to protect customers from that letters.

[ashtonmv]

Since this is obviously not getting any attention from Google, some of you may want to check out Turnstile: https://developers.cloudflare.com/turnstile/

"Turnstile is Cloudflare’s smart CAPTCHA alternative. It can be embedded into any website without sending traffic through Cloudflare and works without showing visitors a CAPTCHA."

It's in beta but it seems pretty stable on our sites. I have no affiliation with Cloudflare, but as an EU developer I'm excited about a performant, user-friendly and (most of all) free Captcha solution with no trojan-horse font nonsense. Hope this can help someone else.

[jamacoe]

Plus there was a lawsuit in Germany that makes it potentially illegal to load fonts from google servers. Which in turn makes it illegal to use recaptcha now?!

Yes. Seems a bit difficult at the moment. Article (in german): https://www.golem.de/news/google-fonts-abmahnungen-an-webseitenbetreiber-mit-google-schriftarten-2208-167472.html

The article states that the court argues that 'Google Fonts' isn't an essential, functional requirement and as such, the user should be able to opt out or alternatively must consent. But, on the other hand, 'Google recaptcha' is essential to my web page. My site won't send a form without. Following this reasoning, I could load 'Google recaptcha' without consent. As this thread proves, the loading of 'Google fonts' is implicit and can't be suppressed. Thus loading 'Google Fonts' without consent could be legal if utilizing 'Google recaptcha'. --- And if I may connect once to gstatic.com, I should be allowed to connect again and load all other required fonts for my site. What do you think?

[NiklasBr]

I think you are misunderstanding the ruling. It states that a subset of the CAPTCHA service that is non-essential (the loading of fonts from a third party server), therefore the loading of fonts requires consent, not the CAPTCHA as a whole. The court says that there has been no facts laid that the loading of fonts from a third-party server is essential to the functioning of the CAPTCHA.

Or in other words, the use of any CAPTCHA may very well be a functional requirement for both our services to operate, but since the specific implementation does not differentiate between optional and functional data collection it as a whole is not within the bounds of the law.

To illustrate. A more extreme version would be if we were to code a shoe-selling site and have parts of it hard-coded to require the collection of political affiliation. Just because it is coded that way and the parts cannot be easily separated into an optional and required section does not provide us with a carte blanc to continue to collect political data on our customers.

So yes, it's not a nice situation. Since Google won't let us properly use their service in a GDPR-compliant manner we are potentially on the hook legally since there are other judgements that unambiguously shows that publishers are responsible for data collected by analytics services they use. We have to continue to ask Google to fix this situation or move to a better service.

[nessor]

Are you sure about that? In the court's decision (https://www.gesetze-bayern.de/Content/Document/Y-300-Z-BECKRS-B-2022-N-612?hl=true) it clearly states

"(...) A legitimate interest of the defendant (...), as claimed by it, does not exist, because Google Fonts can also be used by the defendant without a connection to a Google server being established when the website is called up and a transmission of the IP address of the website user to Google taking place."

So, in the end, the use of Google Fonts is only not allowed if there is an alternative for using Google Fonts (hosting on own server). Since this is not possible with the integration and use of reCAPTCHA, but there is a legitimate interest of use for this, the use of reCAPTCHA should not be covered by the ruling in my layman's opinion.

[gnaaromat]

Just to leave my 50 cents on that 👯‍♂️

reCAPTCHA in and of itself isn't needed per se as alternatives exist without a connection to a Google server. reCAPTCHA should therefore be behind a permission wall along that reasoning.

Sounds more and more like we should avoid reCAPTCHA as of lately. Plus there's a lot of user interaction data that Google can potentially log from a sites clients. Try using the internet through a bigger VPN and you'll be bombarded with CloudFlare reCAPTCHAs left and right. Everytime Google will get your reaction time, browser session if applicabale and the target website. As of now that's - imho - not really protected by the GDPR but maybe that will change as talks about data sovereignty being an ongoing topic in the EU parliament...

[betsch85]

it's ridiculous that we can't just add &nofonts=true to the URL and be done with it

[sinanisler]

google is making this on purpose to track people. no wonder Europe is punishing them all the time........

[Sixl-Daniel]

Well, what to say. In addition to breaching the GDPR, why would I want to load additional fonts that I don't need?