Nathan Willis

How to decrease Debian font bugs by decreasing Debian fonts

Font packages preset a distinct mix of challenges for an OS project like Debian. In addition to their fundamental weirdness (providing bits that are simultaneously a content element and executable code), fonts can be installed in multiple locations — system-wide and per-user, free-software and proprietary, from upstream repositories and from downloaded .zip files — and user applications are expected to gracefully handle all of the permutations within a single “Font” menu item. Font packages are a recurring stumbling block for smaller language communities, where operating-system support may lag behind and upstream designers may be wholly unacquainted with free software.

Furthermore, the low-level privileges granted to font binaries poses practical and security challenges for newer application-packaging formats like Snap and Flatpak, as well as for transactional system-image operating system projects like OSTree and Ubuntu Core.

This talk will outline the concerns of such app-packaging and OS-image projects, then present a possible solution in the form of a simple thought experiment: what if Debian stopped providing font packages altogether?

In the hypothetical font-packageless world, individual users would install their own fonts on a per-user basis only. That change would trigger a number of ripple effects, from altering how system libraries like fontconfig match font names, to how GTK and Qt access fonts, to how end-user applications provide fonts. A user-only font stack would be simpler and have fewer security issues, and it could reduce the lag between an upstream font’s release and its availability to Debian users.

This talk will conclude with a look at the down sides of upending the font-packaging mindset, such as font management on the desktop, font versioning, global-language support, font synchronization, and font discovery. But it will, hopefully, ask attendees to reconsider how and why individual fonts are packaged for Debian and for other free-software distributions, and to explore possible alternatives in the years ahead.

Running your FreedomBox over Tor

The FreedomBox blend of Debian offers people the chance to run a suite of personal web services free from the control of third parties … but it does still require a traditional Internet connection, complete with all of the privacy and anonymity concerns that entails. That caveat disappears, however, if the FreedomBox has the Tor network as its only connection to the outside world. Entirely by chance, I found myself cut off from own public FreedomBox machine last year, but I soon discovered that Tor-only access has some distinct advantages.

This talk will describe my personal experience installing and running a FreedomBox installation that is accessible only over Tor. Some of the difficulties found in combining FreedomBox and Tor are easily overcome, such as properly configuring multiple Tor hidden “.onion” services and securely distributing cryptographic key material. Other hurdles, however, point to weak points that users would be unwise to fiddle with, such as using long-term cookies with Tor Browser.

The talk will describe the challenges and shortcomings encountered in depth — including Tor hidden-service management en masse, working with Let’s Encrypt, key management, service persistence, remote monitoring, and mobile-device access. It will offer suggestions for expanding what packages FreedomBox offers, and will detail the configuration and preference settings required to use Tor Browser and Tor for Android with essential services.

Whatever the obstacles, however, audience members will see that it is possible to not only combine the user freedom of FreedomBox with the anonymity of the Tor network, but to come away with a stronger system when the two work in concert.