5 ms·
Wow, I didn't even realise Helvetica needed a licence. Nor that its pay per click: "When purchasing your digital ad license, you specify the number of impressi
by ian0 8y ago
Wow, I didn't even realise Helvetica needed a licence. Nor that its pay per click:
"When purchasing your digital ad license, you specify the number of impressions your campaign will require. If you’re uncertain how many impressions you will need, you can purchase a small allotment and true up at the end of the month."
https://www.fonts.com/font/linotype/helvetica/licenses https://www.fonts.com/font/linotype/helvetica/licenses
- azinman2 8y agoFonts are expensive, generally.
- cosmie 8y agoThis year I happen to work for a client that licenses all of their brand fonts. Licensed and pay-per-use fonts have easily and quickly worked their way up to the top 5 most agitating things to work with. - They track use by embedding a link to the third party font provider, which does a 302 redirect to a file on your server that requires revalidation every load. So while you host the actual file delivered to the client, you can't optimize away the time added by that needless redirect on every single pageload[1]. - On some clients, invalidating that original link will also invalidate the cache for the destination of the 302 redirect, so the user is forced to truly redownload the font each pageload. - Automated bot traffic, whether benign, malicious, search engines, or anything at all, becomes very expensive. A flood of scrapers hitting your site shifts from a minor nuisance to a very big deal. Something that your infrastructure can absorb without a hiccup can easily rack up hundreds of thousands of dollars worth of font usage costs. You can put security measures in place to prevent some of this, but at the risk of adding friction to legitimate traffic. And don't wan't to stop legitimate bots like social media crawlers and search engines. So you can either leave the risk open ended or "fail open" where, rather than blocking a visit, you selectively decide when to include the custom font and when not to. Cloudflare's SSE[2] comes in handy for this, combined with dynamic inclusion in the server side code to exclude it from being served to legitimate bots like Googlebot which don't need the custom font. I've also experimented recently with using Cloudflare Workers for handling that process and abstracting it completely from the original site. While Cloudflare Workers also have variable pricing based on usage, it's over an order of magnitude cheaper than the usage-based pricing of the font itself, and well worth the cost. - Maintaining that added complexity, purely to cap the risk of the pay-per-view pricing model of the font, adds a needless amount of friction to the website management and development process. [1] https://www.smugmug.com/ https://www.smugmug.com/ is a site that shows this workflow. They load a font file from cloud.typography.com which 302 redirects to the real font file hosted on Smugmug's CDN. While the response is usually fairly quick, I've seen inconsistent response times from the third party providers. And the fact that in some scenarios the must-revalidate flag from the 302 response causes the cache setting from the destination font file to be ignored as well, making it get downloaded every single pageview. [2] https://support.cloudflare.com/hc/en-us/articles/200170036-What-does-Server-Side-Excludes-SSE-do- https://support.cloudflare.com/hc/en-us/articles/200170036-W...
- msla 8y ago> They track use by embedding a link to the third party font provider, which does a 302 redirect to a file on your server that requires revalidation every load. GDPR, here we come! > Automated bot traffic, whether benign, malicious, search engines, or anything at all, becomes very expensive. A flood of scrapers hitting your site shifts from a minor nuisance to a very big deal. As they used to say on the chans: "Oh, exploitable!" This would be a wonderful way to financially DDoS some organization you just don't like very much.
- cosmie 8y ago> GDPR, here we come! I wish I had that card to play! For that specific provider in the example, their ToS explicitly says that, other than your login credentials, they're allowed to do and distribute any and everything they want with any data they collect from the usage of their service[1]. I'd be really curious to see exactly what usage is hiding behind that clause. > This would be a wonderful way to financially DDoS some organization you just don't like very much. Right?! It was mind boggling to learn how easily abused of a system it is. Their ToS even states that it's your problem, not theirs, and any call whatsoever to the "CSS key" (the nonexistent font file on their server that redirects to the real file on your server) is and will be charged as a view. You don't even need to hit the site it's embedded in - just hook up to TOR tunnel and throw a curl command to the "CSS Key" URL into an endless loop. And for optional flourish, add fake user-agent, origin, and referrer headers to the curl command. Let it run for a couple hours every week. Since you didn't hit their site, their site analytics never triggered, and they won't know what hit 'em until months later when it reaches a level that warrants finance asking why you blew so far past your budget. [1] https://www.typography.com/home/cloud-terms.php https://www.typography.com/home/cloud-terms.php
- tomcam 8y agoWow. This is one of the most comprehensive and eye-opening posts I’ve ever read on HN. Thank you
- cosmie 8y ago