Podcast Summary
Font security: Serving licensed fonts securely and avoiding potential tracking by using a custom font serving platform enhances security, privacy, and user experience.
When you're using licensed fonts in your application, it's important to serve them securely while also being aware of potential tracking in font scripts, like those provided by Google Fonts. To address this issue, Scott and Wes built a font serving platform to help them serve fonts with a whitelist across their sites. This platform ensures that only authorized sites can access the licensed fonts, and it also allows them to avoid using Google Fonts and the associated tracking. By hosting their own fonts, they maintain control over their application and user experience, while also enhancing security and privacy. If you're interested in learning more from back-end experts on various topics, be sure to check out the upcoming Behind-the-Code discussion on July 16th, featuring industry leaders like Paul Copplestone, Taylor Otwell, and Yogis Nisiply. Sign up and tune in for valuable insights from some of the brightest minds in the space.
GitHub, fonts, copyright: Be cautious when sharing licensed fonts or other content in GitHub repositories to avoid copyright issues. Consider using a simple font server or CDN, and tools like CloudFlare pages and Spelt Kit for efficient static file serving and routing management.
When it comes to sharing licensed fonts or other content in GitHub repositories, it's important to be mindful of potential copyright issues. The speaker shared a personal experience of receiving a DMCA (Digital Millennium Copyright Act) notice for having a licensed premium plugin in a GitHub repo, even though it was not actively being distributed. To avoid such issues, the speaker created a simple font server using CloudFlare pages. Initially, the speaker tried using a worker for the font server but soon realized the need for routing and pages for managing the whitelist and serving individual functions. The speaker also discussed the functional similarity between CloudFlare pages functions and workers and the ease of use of Spelt Kit for routing and serving static files. The speaker also shared their surprise that CloudFlare workers do not have folder-based routing and opted for Spelt Kit for its built-in routing system and helpers. The decision to use Spelt Kit instead of a simple path server was made to manage the whitelist and serve individual functions. In summary, the key takeaway is to be cautious when sharing licensed content in GitHub repositories and consider using a simple font server or content delivery network (CDN) to serve such content while adhering to copyright laws. Additionally, the use of tools like CloudFlare pages and Spelt Kit can make the process of serving static files and managing routing easier and more efficient.
Font performance: Using a Key Value store for font files instead of a bucket led to faster performance in the speaker's specific use case, involving uploading font files with unique keys, checking origin against a whitelist, and caching font values as strings.
Using a Key Value (KV) store instead of a bucket to store and serve font files via a worker resulted in faster performance for the speaker's specific use case. The speaker experimented with loading fonts from a bucket and from KV via a worker and CloudFlare pages, and consistently found that the worker and pages were faster. This approach involves uploading the font file into KV with a unique key, and then passing and caching the font value as a string data. The whitelist, which is a list of allowed domains, is also stored as a key value in the same KV store. When a request comes in, the origin is checked against the whitelist, and if it matches, the font is served with hard caching. For security, an access pin is used to manage updates to the whitelist, ensuring only authorized individuals can make changes. This setup led to faster loading times compared to loading fonts from a bucket. However, it's important to note that this might not be the fastest approach for all use cases, and other services like Google Fonts can still provide very fast font loading.
Font hosting security: Implementing a font hosting solution using CloudFlare's KV store and JavaScript for whitelisting provides security, control, and prevents hotlinking, saving bandwidth and font costs.
The speaker implemented a simple yet effective font hosting solution using CloudFlare's Key Value (KV) store and JavaScript for whitelisting. The fonts are encrypted and stored securely on CloudFlare, and the KV store allows the speaker to have full control over which fonts are served and uploaded. This setup prevents unauthorized websites from hotlinking the fonts, saving bandwidth and font costs. Although the approach could be considered an overkill solution compared to using a bucket, the speaker mentioned that these types of projects are often the most enjoyable. The speaker encountered challenges with Safari not reliably setting the origin header, which led to implementing a proper URL parser in JavaScript for whitelisting. The question was raised about whether the JavaScript whitelisting is necessary or if it would be better to have it handled entirely through the allow origin header. The answer is that since the font is loaded as an array buffer, stopping the font from being loaded before being passed into a request saves compute. Additionally, a font face respects CORS issues, so using CORS for whitelisting would also be effective. Overall, the speaker's solution demonstrates a creative and effective way to manage font hosting while ensuring security and control.
Font access control with CDNs: Using a unique URL for each whitelisted site with a custom string appended to the URL might be a more effective solution for font access control on CDNs than using the 'Access-Control-Allow-Origin' header to allow specific origins, as the latter caches forever and can be inefficient for serving to multiple origins.
When it comes to serving fonts from a CDN and implementing access control, using the "Access-Control-Allow-Origin" header to allow specific origins might not be the most effective solution, especially when dealing with multiple websites. This is because once an origin is added to the allow list, it is cached forever. Changing the allow origin would require updating the file name or adding a hash to the URL, which can be inefficient and impractical for serving to multiple origins. Instead, having a unique URL for each whitelisted site, with a custom string appended to the URL, might be a more viable solution. However, this approach may not work for local hosts, as they are automatically whitelisted. Additionally, it's important to note that font files can still be accessed and stolen, regardless of the measures taken to protect them. The most common ways to get around font theft include only serving limited weights or characters of the font and using rendering canvases to test and buy the font. Ultimately, this discussion highlights the importance of understanding the limitations and implications of various access control methods when dealing with fonts and CDNs.
Font loading limitations, domain name transfers: While font loading using Web Workers can improve page performance, transferring a domain name between Cloudflare accounts involves a lengthy process and potential complications.
While there are no built-in DRM solutions for specific fonts in web browsers, it's essential to support font foundries. The idea of using Web Workers to load fonts without impacting page performance is an interesting one, and the code for this project is publicly available. To use a font, simply load it up with the font name, and as long as access is good, it will load like a normal font and cache it forever. Another topic discussed was the challenge of transferring a domain name from one Cloudflare account to another. Unlike DNS settings, the actual ownership of the domain name cannot be transferred within the Cloudflare platform. Instead, it must be transferred out to another registrar, waited 60 days, and then transferred back to the desired Cloudflare account. This process can be a significant pain, especially when dealing with multiple workers and subdomains. It's recommended to avoid using personal accounts for domain name ownership to avoid such complications. Overall, the conversation highlighted the importance of understanding the limitations and complexities of various web technologies, from font loading to domain name transfers. It's crucial to be aware of these challenges and plan accordingly to ensure a smooth web development experience.