- From: Thomas Roessler <tlr@w3.org>
- Date: Tue, 10 Jul 2007 10:46:07 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: "WAF WG (public)" <public-appformats@w3.org>
On 2007-07-09 14:14:17 -0700, Jonas Sicking wrote: > Thomas Roessler wrote: >> On 2007-07-06 17:18:11 -0700, Jonas Sicking wrote: >> >> >>> The other use case if your putting a resource on a server that >>> grants access, but you don't want your particular resource to be >>> accessible cross domain. >> >> That use case is actually a recipe for desaster -- mainly because >> there is no way for the server operator to know whether a client is >> going to honor a policy or not. After all, the client could be old >> and predate (and therefore ignore) the access-control language. >> >> That kind of scenario is, in fact, another reason why the >> access-control language should not be able to express restrictions >> that go beyond the existing sandbox model. People will try to use >> the language with "deny" for the use case that you describe, and (as >> you said) "bad things will happen." > > If the client doesn't support AC then it'll deny access due to the existing > same-origin policies. I don't see how this is a problem. In that case I misread your use case, apologies. I was assuming that you were talking of a resource to which access would be granted due to same-origin policies, but the policy author (seeing that nifty "deny" statement) tries to restrict further. Which would inevitably fail. (Incidentally, that scenario -- that I *thought* you were talking of -- is one of the reasons against "deny" that I forgot to mention in my earlier summary.) -- Thomas Roessler, W3C <tlr@w3.org>
Received on Tuesday, 10 July 2007 08:46:17 UTC