- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 2 Jul 2009 21:39:04 -0500
- 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 UTC