I think it is interesting to hear from the other side of the fence every so often, but the proposed plan is sub-optimal. I would like to suggest what I think is a better model.<p>The "Sampo solution" to licensing (each foundry holds a page listing which domains are allowed to use a font) is frankly unworkable.<p>Imagine if helvetica was licensed this way - on every web page more or less. Every time a browser visited a new domain it would need to download a very big file from a foundry website (there are how many domains? What does a ten million line file cost to download on a mobile?). And what about the TTL for that list, make it a week and every browser around the world needs to download it all again. Even Google would sag under that kind of load.<p>The first idea that comes to mind is to just replace the "root table" with a y/n call - here is my webpage, here is the font name, can i use it. This does not really solve the problem - it reduces traffic sure, but the issue is that if i visit domain x I automatically need to visit another domain, that may or may not be available. Its inelegant, its inefficient and its insecure. The web would effectively 'not work' if a big foundry said 'no to all'. And that is a big ransom demand to put in anyones hands. And I strongly suspect there is a really powerful cross-site scripting vulnerability sitting in there.<p>It also works against the foundries - the solution decides the licensing. There is just one kind of license - per domain. No sophistication, no negotiation. What if you only want to license your font for my mobile readers. What if you want to license it for the first 100,000 views for free as a taster, then stick it to me. What if everyone hosted on rackspace servers gets it. The technology should limit the business options as little as possible.<p>Ok, what do you suggest then ?<p>I prefer a slightly more network-friendly solution. There are not that many foundries (certainly orders of magnitude less than domains) so it is quite feasible for them all to put public root certificates in browsers, or at worst run shared CAs. The technology is already there for SSL. Then each website who wants to license a .wtf (great name!) file pays their money and gets a signed (hashed) license file which sits next to robots.txt. The browser downloads the web page, the font and then decrypts the license file with the known public key.<p>The license file is then located where it should be, on the site with the font, and we can trust the license file is genuine. If its out of date thats the webmasters problem.<p>The license file could hold<p>- domains allowed
- servers / ips allowed
- license type
- an extensible other data section.<p>The license type would need to be pre-agreed with the browsers, the first obvious one is per domain. But any number of types (lets say one byte or 255) could be invented as the browser manufacturers and foundries talk.<p>This solution has a lot more going for it.<p>We avoid the horrors of mass file downloads, of out of date caches causing havoc and of finding that we put the entire web under the control of one small group of font designers.(I am sure they are lovely people each and every one, in fact thats why i dont want to do it. Imagine the stress of avoiding that temptation, lets not put them through it, the dears.)<p>It also follows the same approach as has been proven to work with ssl for a dozen years, and reuses technology instead of inventing it.<p>The downsides - well font designers are asking web browser manufacturers to enforce their copyright. If they get it, the exact same approach can be used for, well anything. If youtube has not got right license file, no playing. Seems like a can of worms to me, and I suspect I would not want to do it if I were Apple or Mozilla.<p>Anyway, my two cents.<p>[edit:removed a comment that might be a bit flame-y]