RE: Thoughts on font linking and embedding

Hello Maciej,

Thank you very much for your thoughtful and detailed response, and welcome to the WebFonts WG.

See comments inline.

On Wednesday, February 16, 2011 2:28 PM Maciej Stachowiak wrote:
> 
> == (3) Hotlinking prevention is useful, but not a very strong license
> enforcement mechanism ==
> 
> Besides protecting the hosting site's bandwidth, same-origin embedding
> restrictions are proposed as a lightweight aid to following font
> licenses that limit use to a single site. It is reasonable that font
> vendors may want this, but I think we need to keep this threat in
> perspective. Most sites wanting to make unauthorized use of a font will
> simply download it and host it from their own site. Same-origin
> restrictions will do nothing to prevent that. Hotlinking seems like a
> less likely scenario for license violation.
> 

I agree with you that hotlinking prevention is useful for all resource types, but there are some special considerations that I believe are warranted for fonts. First and foremost, there are specific security concerns - fonts provide very fruitful grounds for malware, and allowing font hotlinking (or embedding, as you explained in your excellent Web platform overview) would, undoubtfully, create security risks. We already know how powerful font exploits can be:
http://news.cnet.com/8301-31021_3-20012511-260.html

I also agree with you that same-origin restriction is not a strong license enforcement mechanism, but I suspect you've misinterpreted typical font license conditions. It's true that most font licenses would be limited to specific domains, and same-origin restriction would provide an easy mechanism to satisfy this license condition. However, font licenses do not have provisions that would require authors to _eliminate_ the risk of theft of the resource, therefore the example that you presented has nothing to do with license enforcement. If the case you described were to happen - I'd say that the same-origin restriction has accomplished its purpose creating a situation where an IP thief is exposed. The original licensee of the resource therefore has fulfilled his responsibilities and prevented an unlicensed use of fonts hosted on his server.

> 
> == (5) Cross-origin access restrictions should be tied to embedding
> mechanisms, not data formats ==
> 
> Regardless of the embedding rules for fonts, and whether CORS or a new
> Embed-Only-From-Origin/From-Origin header is used to control them,
> these rules should be tied to the relevant embedding API, namely @font-
> face, not to a specific font file format. There are a few key reasons
> for this:
> 
> A) It is a layering violation for a data format to place constraints on
> how embedding mechanisms can use it. The embedding mechanism itself
> should define the restrictions.
> 
> B) It is confusing and undesirable for everyone if different font
> formats have different embedding rules. It would be silly if WOFF fonts
> and OpenType fonts had different embedding rules.
> 
> C) It may not be practical to implement same-origin embedding
> restrictions with CORS exception for WOFF fonts only, and not other
> font formats (e.g. TrueType, OpenType, SVG). This has so far not
> affected Firefox or IE, since those browsers actually implement same-
> origin restrictions for all font formats in the most recent versions.
> However, if that is the desired end-game, that is how it should be
> specced. The restrictions should attach to @font-face, not to the WOFF
> format.
> 

I agree, and this is exactly how it is currently implemented by IE9 and Firefox.
The WOFF specification may not be the best place to specify SOR for @font-face rule, but I guess at the time we approached this issue it seemed to be most convenient way to accomplish it. If there is a possibility to make this part of the CSS3 Fonts spec to attach SOR to @font-face, I agree this would be better way to do it.

> 
> == (6) Pros and cons of different approaches to restricting cross-site
> font embedding ==
> 
> I believe that making fonts consistent with the rest of the Web
> platform, and adding an anti-hotlinking mechanism that applies to the
> whole Web platform, has a number of advantages:
> 
> A) Consistency and clarity for authors.
> B) Applies to all font formats, not just WOFF, which is presumably more
> desirable for font vendors.
> C) Appears to be something that all browsers would be on board to
> implement, which seems better than a more restrictive rule that only a
> subset of browsers would implement.
> D) Better fit with the architecture of the Web.
> 

I don't see any contradiction with allowing From-Origin/Embed-Only-From-Origin header be used for any resource type, and, at the same time, creating a link-specific @font-face rule to apply SOR by default, as if "From-Origin: same" is presented.

Thank you,
Vlad

> 
> I hope these remarks clarify our position.
> 
> Regards,
> Maciej
> 
> 
> 
> 
> 
> 
>

Received on Wednesday, 16 February 2011 20:35:11 UTC