RE: Next step?

I'd like to remind us all that the same-origin restriction and CORS have significant utility value for both web authors and users - they help protect server bandwidth from unauthorized resource sharing, and possibly helping to protect users from malicious attacks using fonts (e.g. phishing scams).

The fact that by restricting resource sharing SOP also help protect the font IP is a happy coincidence, and I am sure many font vendors will want to see their font resources protected this way (as evidenced by the statements of support for WOFF *and* same-origin restriction plus CORS [1]). Since older versions of IE do not support SOP, "root strings in padding" present a viable alternative to same origin restriction and, likewise, would provide the same value for all parties involved: web authors (protecting server bandwidth), web users (protecting them from malicious attacks) and font vendors' IP protection. 

Let me remind you that we are not talking about introducing root strings as part of CWT but merely tolerating their presence in the padding, where the specification would say in strongest possible terms that any data in padding must be ignored by all compliant browsers. All that is necessary to tolerate their presence is to ignore the version number as well, making CWT implementation a couple of lines of code shorter.

Speaking on behalf of Monotype - our license does and will require some kind of protection mechanism be in place for our fonts to be used on the web - either same-origin restrictions or root strings or referrer checking or by another means (e.g. JS) that web authors would find appropriate to satisfy the license conditions.

Regards,
Vlad

[1] http://lists.w3.org/Archives/Public/www-font/2009JulSep/0851.html



> -----Original Message-----
> From: www-font-request@w3.org [mailto:www-font-request@w3.org] On
> Behalf Of Sylvain Galineau
> Sent: Friday, October 23, 2009 10:24 AM
> To: robert@ocallahan.org
> Cc: Tab Atkins Jr.; www-font@w3.org
> Subject: RE: Next step?
> 
> From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of
> Robert O'Callahan
> 
> >However you've convinced me that a WOFF recommendation, if there is
> one, should also recommend implementation of the same->origin check +
> CORS. Thanks! Whether and how authors use that to satisfy their font
> license obligations is still between >them and their font vendors, but
> a standard mechanism should be available in all browsers.
> 
> Indeed. Happy to settle that.
> 
> >When Bill Davis says Ascender's EULAs will continue to require a same-
> origin check, surely I can trust that statement?
> He said a referer check would comply with a requirement to 'reasonably
> restrict access'. So until I have the EULA and professional lawyers
> tell me what it means and how it shall be enforced in technical terms I
> shall trust Bill's statement as is. And, based on my experience, trust
> that it may not mean what non-lawyers like you and me think it means :)
> 
> >As you know, I think that change would make CWT more useful. However
> we both know other people have a problem with it... >Overall I'd still
> be tepid about CWT; adding rootstrings will generally require tools to
> be introduced into the Web author >workflow, and once you have that, it
> would be just as easy to generate both WOFF and EOT-Classic files, and
> CWT is not >needed. IMHO.
> 
> If the goal is to get others to support it then EOT-Classic seems a
> non-starter as an interoperable implementation must respect rootstrings
> and support MTX compression. I'm cautiously optimistic that a subset
> that effectively requires clients to ignore rootstrings and has no
> proprietary compression would be a lot more palatable.
> 
> >The only scenario where I can imagine CWT being a real win is if font
> vendors drop their demands for same-origin >restrictions.
> Or interpret 'reasonable restriction' as : no overriding default SOP
> for clients that support it. Legacy clients won't be around forever
> (although at times, it does feel that way...)
> 
> >Then you could conveniently produce CWT fonts that are easy to deploy,
> and you can serve a single font file served to IE >users and other
> browser users without violating your font license. I genuinely would
> like to see that scenario happen and I >would support implementing CWT
> if we thought it would come about. Based on what Bill Davis and others
> have said, I just see >no hope it will.
> 
> Very valuable feedback. This ball is now in my camp. Thanks !

Received on Friday, 23 October 2009 14:56:54 UTC