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

Re: the discussion is over, resistance time

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 2 Jul 2009 21:39:04 -0500
Message-ID: <dd0fbad0907021939k731b5371vbe06e823fc72ae9@mail.gmail.com>
To: Thomas Lord <lord@emf.net>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, luke whitmore <lwhitmore@gmail.com>, "www-font@w3.org" <www-font@w3.org>
On Thu, Jul 2, 2009 at 7:33 PM, Thomas Lord<lord@emf.net> wrote:
> On Thu, 2009-07-02 at 19:19 -0500, Tab Atkins Jr. wrote:
>
>> Unless I'm *completely* wrong (and I don't think I am, because Anne
>> has been very assertive in correcting people about how same-origin and
>> CORS works), you're wrong.
>
>> Same-origin restrictions do not affect the server *at all*.  If a
>> same-origin restriction is in effect, the *browser* enforces it,
>> *after* receiving the resource from the server.
>
>
> Very briefly:
>
> http://www.w3.org/TR/access-control/
>
>  1 Introduction
>  [....]
>
>  Server-side applications are enabled to discover
>  that an HTTP request was deemed a cross-origin
>  request by the user agent, through the Origin header.
>
>  This extension enables server-side applications to
>  enforce limitations on the cross-origin requests that
>  they are willing to service.
>
> CORS concedes the right of servers to not serve
> up a given resource and constructs a system in which
> conforming clients, which we presume most users will
> use, help to streamline that process to the benefit
> of both parties.

Ah, okay, point.  However, doing it that way is also a bit of a pain,
same as restricting on Referer.  As well, while Origin *shouldn't* be
a privacy risk that makes people turn it off, for some time you'll
still have legacy clients not sending it, giving you a functionally
similar situation to current Referer-based headaches.  (Though, unless
we adopt EOT or some compatible variant, down-level clients aren't
really going to be an issue we have to worry about.)

Still though, standard same-origin restriction, and all the other CORS
headers, are intended for client-level origin checks, and *are*
functionally identical to rootstrings.

>> The needless non-feature on offer is the same your own proposal aims for.
>
> As with Chris, I must ask, are you an
> honest debater, ma'am?
>
> That kind of statement simply does not follow
> from any of the preceding conversation.  I have
> difficulty forming any generous interpretation
> of how you arrived at that.

I agree with Sylvain in this matter; I don't find your idea of
wrapping a font with licensing information to be that compelling.  If
I had to choose between that and a compression-based obfuscation
method, I'd choose the latter, as it gives me some actual benefit.

Now, I don't find it be particularly noxious, either, so if it was
settled on I wouldn't really complain.  I just don't have much
sentiment *for* it.

>> A server might be reasonably configured to
>> refuse certain requests for a font.  Systems
>> like CORS allow conforming browsers to
>> streamline and simplify that server's right
>> of refusal.
> Not quite. CORS aims to enable same-origin policy overrides. It does not refuse access,
> it allows access to resources that would otherwise not be loaded. It's an allow mechanism.

For those playing at home, CORS is the allow mechanism that
complements the same-origin deny mechanism.  Rootstrings include both
an allow and deny mechanism in one (a conforming agent denies from
*all* origins, except for those specified as allowed in the
rootstring).

>>> A system of rootstrings forbids a client from
>>> performing certain computations with a file that
>>> is already in hand, if the client is to be called
>>> conforming.  This refusal is in spite of the fact
>>> that no interop enhancement is thus obtained.
>>  The first sentence is correct. The second does not logically follow. Today, Mozilla may reject a web font that WebKit would not. That is not interoperable even though rootstrings are not involved.
>
> That is not an *inter*-op issue.  No
> program in what you describe is confused
> as to the meaning of any particular bit of
> data.  They diverge only in terms of what
> they afford users.

It most certainly is an interop issue, as Sylvain notes in a later
response.  Two UAs receiving identical data but performing differently
(in the absence of a user decision to do so) is the *definition* of an
interop failure.

> Switching my gender, however, is as good a demonstration as any of the number of conclusions you may be too casually jumping to around here.
>
> It's Mr Galineau to you, Mr Lord. And it shall remain so until I undertake expensive - and expansive - surgery. (...even if some people may argue the French do not need transgender surgery...)

To be fair, even though I *know* I've seen you correct people before,
I still automatically think of you as female.  Sylvain is a sounds
feminine to my American ears, and, as Thomas noted, is close enough to
Sylvia to trick someone not paying close attention.  I have to be
careful when referring to Anne van Kesteren for the same reason.  >_<


>> I think there's *some* (not necessarily good,
>> but *some) chance you, me, Chris, howcome@,
>> and others can shock the hell out of everyone
>> else by suddenly agreeing about a bunch of
>> stuff.
> Frankly, I like to think so too.

Hell, I'm fairly sure it's possible.  We're making better progress
here than we have in a long while.

I do think it would be pretty damned hilarious to come back to
www-style with everyone holding hands and skipping to the tune of some
magical consensus proposal in a week.

~TJ
Received on Friday, 3 July 2009 02:40:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:02 GMT