Re: Next step?

On Fri, Oct 23, 2009 at 7:26 PM, Sylvain Galineau
<sylvaing@microsoft.com>wrote:

> >The problem is, if SOP is a requirement, and we don't have a convenient
> SOP mechanism that works with CWT on all high->market-share browsers that
> support CWT, then CWT isn't very useful. A mechanism doesn't need to be part
> of the spec --- >there could even be more than one --- but at least one does
> need to exist.
>
> If SOP is an EULA requirement, WOFF will be equally pointless in a browser
> that doesn't implement SOP or equivalent for WOFF resources. Given that
> other browser vendors have implemented web font support without SOP, I'd
> think that should be a serious interop concern.


Yes, if other browsers implement WOFF with no same-origin check then WOFF
would become a lot more difficult to deploy with common font licenses.
Hopefully that won't happen. We need to encourage browser developers to
implement the same origin check if they implement WOFF. If a Fonts WG
recommendation would help in practice (I'm not sure if it would or not),
then that would be useful to have.

I am thus puzzled that the SOP issue is so critical when CWT is the topic
> but a vague general statement about access control being up to private
> contracts is sufficient for WOFF ?
>

It's because the main advantage of CWT is IE compatibility, but you don't
get any simple same-origin check with IE, which undermines CWT's touted
advantage.

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.

Well, you're welcome to interpret mailing list posts as EULAs.


When Bill Davis says Ascender's EULAs will continue to require a same-origin
check, surely I can trust that statement?

But if SOP is so critical to the viability of a web font format, shouldn't
> it be specified as a requirement for web fonts in general ? Why is it an
> issue for CWT only ? Surely we don't want to risk the release a 'pointless'
> implementation of WOFF, do we ?
>

You're right. I've changed my mind on this point.

Managing rootstrings are not as kind on authors as SOP - it'll require
> tools, for one - but if it's at least better than referer checking, the
> judgment call on the cost/benefit is, once again, up to said authors.
>
> So, assuming CWT has rootstring space, is still still 'pointless' ?
>

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.

The only scenario where I can imagine CWT being a real win is if font
vendors drop their demands for same-origin restrictions. 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.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]