- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 21 May 2007 12:47:10 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Anne van Kesteren <annevk@opera.com>, "WAF WG (public)" <public-appformats@w3.org>
On 2007-04-26 03:54:38 -0700, Jonas Sicking wrote: > I think I was unclear. I don't expect access control to ever > block access further than what browsers today already does. The > simplest reason is that current, already released, browsers > obviously ignore such headers/PIs and always will. So access > control is not adequate to restrict data access further than > browsers do today. We're in wild agreement there. > However once I deploy access control PIs/headers they allow other > sites to read data from my server. But if I then realize that I > have put errorous access control information in my files, for > example not having a restrictive enough deny/exclude lists, or > putting the PIs in too many files, it would be very useful to > immediately being able block evil.com or any other site from > reading any of the files on the server. > Another scenario is a server administrator for a server behind a > firewall at a corporation wants to make sure that no data is > accidentally leaked even though the employees are responsible for > putting files on the server. The administrator could then add a > access control header that denied all external servers from > reading any data. I can see the use case, but I wonder if it really warrants a change to the access control language. On the one hand, the currently proposed syntax would make an easy programmatic change possible -- all you'd do is add evil.com to the exclusions. On the other hand, adding an order dependency and unscoped exclusions would make the language more complex. I wouldn't be surprised to see bug reports coming in against implementations that claim brokenness because an unscoped "exclude" doesn't have whatever effect an author might have desired... Regards, -- Thomas Roessler, W3C <tlr@w3.org>
Received on Monday, 21 May 2007 10:47:17 UTC