W3C home > Mailing lists > Public > public-appformats@w3.org > April 2007

Re: [AC] Access Control Algorithm

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 26 Apr 2007 03:54:38 -0700
Message-ID: <463084EE.1020603@sicking.cc>
To: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>, "WAF WG (public)" <public-appformats@w3.org>

Thomas Roessler wrote:
> On 2007-04-24 12:12:35 -0700, Jonas Sicking wrote:
>> So this puts two requirements on the algorithm. First of all we
>> can't simply merge whatever lists are in the headers with the
>> lists produced by the PIs in the page. Second, we need an
>> explicit way to deny access, not just exclude from the accept
>> list.
> I think we'd need some *very* good arguments why that is desirable.
> The current algorithm is, in fact, deliberately designed *not* to
> deny access in addition to what the browser's default sandbox does.

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.

However, current browsers, at least for most part, protect against cross 
site reading of data. That means that if I place data on a server inside 
a firewall, or behind a login mechanism, I can assume that evil.com 
can't read that data. Even if a user sitting inside that firewall, or 
that is logged in to my site, accesses evil.com. Evil.com can use 
<iframe>s or <img>s to display data from my site, but it can never 
access the actual data on my server.

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.

Received on Thursday, 26 April 2007 10:54:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:07 UTC