Host Google Fonts Locally Instead of Using Google Services

[amrutadotorg]

Hi, I propose modifying the SQLPage shell component to host Google Fonts locally rather than relying on Google’s servers. This change is crucial for ensuring adherence to the General Data Protection Regulation (GDPR), especially in light of recent legal developments.

Context and Justification: In January 2022, a significant legal decision in Germany highlighted the importance of this issue. A German court fined a website owner for using Google Fonts hosted on Google's servers without proper user consent, which was deemed a violation of GDPR. The case, reported by The Register, concluded that transmitting user IP addresses to Google without consent breaches GDPR requirements, resulting in a fine of €100.

To avoid similar legal risks and enhance the privacy of our users, hosting Google Fonts locally is a necessary step. This approach will prevent user data from being sent to third-party servers, thereby ensuring better compliance with GDPR and safeguarding user privacy.

It's worth noting that WordPress has also started hosting Google Fonts locally to address these GDPR concerns.

By hosting Google Fonts locally, we not only comply with GDPR but also improve the loading speed of the web application by reducing external requests. This enhancement demonstrates SQLPage dedication to privacy and user data protection.

References:

• The Register - Website fined for using Google Fonts in violation of GDPR
• WordPress - Google Fonts are Included Locally in Bundled Themes

Thank you.

[lovasoa]

Hello! I don't think it's realistic to include all of Google fonts inside the SQLPage binary by default. But we should definitely allow referencing a local font file on the server. We can detect if the font name starts with a / and reference it locally. Can you make a PR?

[amrutadotorg]

Sure. In case of a font not found should we gracefully fallback to using Google Fonts?

[lovasoa]

No, just test whether font starts with /, and if so create a style tag with a font declaration.

https://github.com/lovasoa/SQLpage/blob/c0efd148d12f144fe953dead4de1572e359a6e33/sqlpage/templates/shell.handlebars#L19-L20

And we should document this logic in the shell component documentation.

[amrutadotorg]

Ok. Have you considered having multiple fonts registered? This might be useful for example in the hero component where a user might use different font to display a nice looking quote along with a picture.

[lovasoa]

No, that's not something I had considered so far. May be interesting indeed.

[lovasoa]

Fixed by https://github.com/lovasoa/SQLpage/pull/439

[amrutadotorg]

What would you say of having multiple fonts like this and then use the name of a font as a property in the hero component?

{{#each (to_array font) as |fontEntry|}}
    {{#if fontEntry}}
        {{#if (starts_with fontEntry "/")}}
            <style>
                @font-face {
                    font-family: 'LocalFont';
                    src: url('{{fontEntry}}') format('woff2');
                    font-weight: normal;
                    font-style: normal;
                }
                :root {
                    --tblr-font-sans-serif: 'LocalFont', Arial, sans-serif;
                }
            </style>
        {{else}}
            <link rel="preconnect" href="https://fonts.googleapis.com">
            <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
            <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family={{fontEntry}}&display=fallback">
            <style>:root { --tblr-font-sans-serif: '{{fontEntry}}', Arial, sans-serif;}</style>
        {{/if}}
    {{/if}}
{{/each}}

[lovasoa]

That would just repeatedly re-define the same --tblr-font-sans-serif variable. Probably not what you want.

I think it's fine to ask users to write 5 lines of CSS themselves if they want multiple fonts on the same page, which I think is rare among SQLPage users.