Custom Fonts

[Kunsi]

For a lot of conferences, some sort of "event style" is preferred by the design team.

I got asked:

Would it be possible to allow the @font-face css property in custom css?

Personally, i like the idea of not having that feature, because allowing custom fonts will inevitably lead to someone using a totally unreadable font. However, i understand the need of events wanting to have some sort of control over the design of their schedule.

Maybe the community has some ideas on how to solve that problem?
Maybe pretalx should have some (admin-provided) fonts to choose from?

[rashfael]

I can only speak for the schedule, but some widths in the shedule (for example the colored left border of each talk) are tuned to the font and font-size, changing the font will probably change the width of "16:00" and in extrem cases break the layout. While we probably could solve that by using different css units or something, it will take more work and more importantly, more maintenance effort (visually testing different fonts not breaking stuff would be an absolute pain).

So should we allow @font-face we need to make people aware that they need to check some absolute values.
And of course as usual I am wary of people footgunning themselves design-wise.

[Kunsi]

I agree this isn't an easy thing to do.

I got asked about custom fonts because they wanted the lower-thirds (from Kunsi/pretalx-plugin-broadcast-tools) to be more like the event design. If we can't find any other use case for custom fonts, i'll implement custom css support inside the plugin, too.

[rixx]

While I agree with @rashfael about the issues custom fonts will inevitably bring, I also don't think we can avoid the interest in them forever.

That said, I don't think allowing font faces in custom CSS is the way forward, because for that to work, we'd need to either allow users to upload fonts (big nope), or open our CSP headers to permit style sources from external locations (possibly parsing them from custom CSS?), which seems brittle and not particularly nice to me.

I think at least as a first step, and hopefully as a last step too, I'd suggest going for plugin-sourced fonts. This has the advantage of a) having a clear interface that an administrator gets to look over and approve, not one-per-event, and b) allows the whole topic to exist independently from the core project. And of course, c), it allows us to yoink most of pretix's approach. Even with administrator approved fonts, we might have to warn that not all of them are equally well-suited to the schedule display, or maybe even make the plugin hook so that fonts can also provide CSS changes.

[rixx]

Tracking in #1242

[benabraham]

@rixx I know this is an old and closed issue but #1242 is already a suggested solution which seems too complicated and I’d like to suggest one that much simpler one that covers most of cases.

I don’t see any danger which poses simply linking (with @import in CSS) fonts from Google Fonts which would cover vast majority of needs as most websites use those opensource fonts anyway.

Google curates what goes in, it’s widely used so any security problems are probably taken care of.

Does making an exception in your @import rule validation for custom CSS + changing your CSP headers to allow fonts.google.com sound simpler and secure enough?

[rixx]

I'm a bit confused by your characterisation of this change as "simple". We would need to:

• on every update, parse the CSS for included remote fonts
• either allow arbitrary font sources, or create a whitelist with acceptable font sources, as allowing just Google fonts seems like the worst of all worlds
• save the font domains for the event
• write a middleware that updates the CSP for every request based on that event's font domains
• rewrite the currently-static privacy / GDPR info page to include dynamic info on the event's font sources
• to do things actually properly: have a user consent pop-up, per event, asking for consent to load in external fonts, and, crucially, not loading them otherwise

This is something that you can absolutely do in a fork of pretalx with a two-line change (exception to the CSS parsing + updated CSP), and I would encourage you to do so, as your comments on various issues today sound like this is a topic that is very important to you. When running your own fork, you could decide that GDPR compliance is not an issue for you, or simply hard-code your choices, but that's not an option for the project as a whole, I'm afraid.

[benabraham]

@rixx Thank you for a detailed answer.

As usually things seem easier for an outsider than the insider.

Sometimes this out-of-the-box thinking can help people deeply buried in complex problems to see a simpler path and many times it’s just too naive which is the case here.
Most importantly I was not aware about GDPR issue with Google Fonts. 🤯

And yes I was thinking about hardcoded whitelisting for all events as one service would be enough for most needs. It might be a simpler solution other than making it completely dynamic if I catch all the points you made correctly. Also I saw other hardcoded options in the project so it didn’t seem something out of the question.

This led me to find a EU-based service that's a drop-in replacement for Google Fonts https://fonts.bunny.net/ They claim:

What personal data do you collect?
When using Bunny Fonts, no personal data or logs are stored. All the requests are processed completely anonymously.

This would remove some of the points regarding to GDPR.

But that’s just explanation of my thinking. You’re right, that a fork would be probably the best solution for the needs we have right now.

And thank you for an opportunity to learn something new today. ❤️