W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: same-origin restrictions and EULA (Re: A way forward)

From: Erik van Blokland <erik@letterror.com>
Date: Sat, 25 Jul 2009 12:12:50 +0200
Cc: www-font <www-font@w3.org>, Sylvain Galineau <sylvaing@microsoft.com>
Message-Id: <0D919561-80CC-438C-8041-53B0D3B2A4B0@letterror.com>
To: Chris Fynn <cfynn@gmx.net>

On Jul 25, 2009, at 10:40 AM, Chris Fynn wrote:

> If same origin restrictions are enforced by the UA how can an EULA  
> reasonably require them? Surely web authors cannot be held  
> responsible for how particular browsers accessing their sites happen  
> to behave in this regard. Or is the server supposed to check each  
> time which UA is accessing the site and only serve web fonts to  
> those it knows enforce same-origin restrictions?

I think John Daggett used a hypothetical same-origin-requiring-EULA as  
an example. Perhaps there is confusion about same-origin as specified  
in CORS [1] and a more general referrer checking?

Given that same-origin-as-in-CORS would have to be implemented in the  
UA, not in the font nor in the webauthor's server app, it is outside  
the realm of responsibility for a EULA between foundry and webauthor.  
Restricting the use of a webfont to one particular (or group of) User  
Agents in a EULA is very difficult. Foundries would not specify such a  
condition in EULAs, webauthors would not follow it if there was.  
Referrer checking is a different thing, and it could theoretically be  
part of a EULA as it involves the server app of webauthor. But IANAL,  
I'm also not pointing out foundries should or should not do this.

That said, I'm convinced most (if not all) foundries will strongly  
appeal to /all/ UA developers to start supporting same-origin-as-in- 
CORS for font data if they don't already do so. I think this point  
will be raised once there is some light at the end of this tunnel.


[1] http://www.w3.org/TR/access-control/
Received on Saturday, 25 July 2009 10:13:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:32 UTC