RE: WOFF without same origin restriction in Opera?

[John Hudson:]
> I presume we have Anne van Kesteren to thank for this. At the face-to-face
> meeting in Lyon, Håkon intimated that there was debate within Opera over
> same origin restriction, and Anne has made it perfectly clear in the past
> that he opposes it (apparently protecting a company's data is acceptable
> but protecting a company's assets from being used by competitors is not);
> he also publicly endorsed the 'Fuck the Foundries' approach to web fonts
> on his blog.
> 
> Opera have had plenty of opportunity to make a formal objection to SOR in
> the WOFF specification. We're at last call for comments and they have not
> done so. Håkon made no objection at the face-to-face in Lyon. Maybe
> someone at Opera thinks they can do an end run by producing an
> implementation that ignores this MUST clause, but I think they're just
> going to end up being non-conformant. Maybe they'd listen to one of their
> own customers who wants to protect an investment in a font asset?

I'm not sure where this rant can get us. Granted, it's far more articulate 
and intelligent than 'Fuck the Foundries' but when the rhetorical bar is that
low, pretty much anything goes...

Whatever 'protection' SOP provides is already built in IE9 and Firefox. 
In practice this represents enough browser market share to ensure most 
content will be designed and tested to comply with this restriction. It
also means that other browser vendors may take a free-ride on IE and 
Firefox, save themselves a little coding and maybe even boast about 
their stance to people who care more about technical purity than web 
typography (because those people and their opinion are far more 
important to them).

Beyond possible license violations, this makes web authors' lives 
a bit more complicated by adding yet another browser incompatibility 
as a web developer may find her page works in one browser but not 
the other for a cause that will be rather hard to debug since there 
is just nothing to see. (Note that I'm less worried about Opera than 
WebKit in this case as I don't know whether they'll implement this 
either). We have in fact added some functionality to our IE9 dev 
tools to report same-origin policy font load failures for this reason. 

Anne and others would of course argue that such confusing silent 
failures are another good reason to not implement this; and that's 
a rational response when technical cleanliness ranks higher on your 
priority list than achieving the richest possible web typography now. 
That someone honestly expects an industry he knows nothing about to 
conform to the way he wants the code to work regardless of the actual 
cost of accommodating them should give you an idea of the priority 
gap. When most of the engineering cost resides in decoding the format, 
saying no to the remaining 2% of work may seem quite intransigent. 
That Opera nominated a representative who so strongly believes the WG's 
effort to a waste of time does not help.  But it also indicates that 
this is a much deeper 'political'/'philosophical' issue - one that is 
not limited to fonts - so I wouldn't expect it to be resolved here any 
better than it has been in the past. And even if it were resolved to the 
WG's satisfaction, another implementor may still choose to not enforce 
this requirement.

Ultimately, the issue is that we have a MUST requirement in the spec 
that exists for non-technical reasons. When that happens, you can 
certainly end up with implementations who choose to be deliberately
non-conformant for any number of reasons. I frankly don't think anything
can be done by the WG to prevent that. I'm not sure it should try either.

And I also believe other issues are far more important than this one. 
Today, we run into fonts that IE9 rejects in accordance with the spec
but load fine in Firefox. Day to day, that is going to be a far more
expensive issue for web authors, browser vendors and font makers than
Opera allowing any font to load across domains.

Received on Wednesday, 26 January 2011 00:07:46 UTC