Request for Comments on Enabling Read Access for Web Resources

Hello Art,

Please accept my apologies for the late response. Some time
ago [1] the
TAG asked me to send along the following comment in response
to your
request[2] for feedback which I utterly failed to do at the
time.

--

The TAG have asked me to respond to your request for
feedback [2]. 
In addition to comments from Rhys Lewis [3], the TAG has the
following
comment:

1) The TAG would like the introduction to the document to
contain a
fuller 
   account of the rationale behind the existing UA sandbox
policy and
the attacks
   that it is intended to guard against. For example, we
believe that
one of 
   the key use-cases that the sandbox policy is intended to
address is
leakage 
   of confidential information from behind a firewall
arising from
either 
   accidental or malicious scripted behaviour executing
within the UA.

   We would then like the document to indicate whether there
are
situations where
   implementation of the Read Access Control Policy
mechanism would make
a UA
   and the network to which it is attached any more
vulnerable to
attack.

   We think that the increased risk is probably small, but
we believe
that the 
   document should present more analysis than it does at
present.


Stuart Williams
for W3C TAG

[1] http://www.w3.org/2001/tag/2007/07/09-tagmem-min
utes.html#item04

[2] http://lists.w3.org/Archives/Public/www-tag/2007Jun/0114

[3] http://lists.w3.org/Archives/Public/www-tag/2007Jun/0145

--
Hewlett-Packard Limited registered Office: Cain Road,
Bracknell, Berks
RG12 1HN
Registered No: 690597 England

On Wed, 29 Aug 2007 17:12:44 +0200, Williams, Stuart (HP
Labs, Bristol)  
<skwhp.com> wrote:
> 1) The TAG would like the introduction to the document
to contain a
> fuller account of the rationale behind the existing UA
sandbox policy and
> the attacks that it is intended to guard against. For
example, we  
> believe that
> one of the key use-cases that the sandbox policy is
intended to address  
> is
> leakage of confidential information from behind a
firewall arising from
> either accidental or malicious scripted behaviour
executing within the  
> UA.

That is correct. I mentioned this now in the introduction: 

http://dev.w3.org/2006/waf/access-control/Ov
erview.html#introduction


> We would then like the document to indicate whether
there are
> situations where implementation of the Read Access
Control Policy
> mechanism would make a UA and the network to which it
is attached any  
> more vulnerable to
> attack.
>
> We think that the increased risk is probably small, but
we believe
> that the document should present more analysis than it
does at present.

I tried making this more clear in the security section:  
http://dev.w3.org/2006/waf/access-control/Overvi
ew.html#security


My apologies for the late reply. I've been busy with some
other tasks.


-- 
Anne van Kesteren
<http://annevankesteren
.nl/>
<http://www.opera.com/>

Anne van Kesteren wrote:
>> We would then like the document to indicate whether
there are
>> situations where implementation of the Read Access
Control Policy
>> mechanism would make a UA and the network to which
it is attached any 
>> more vulnerable to
>> attack.
>>
>> We think that the increased risk is probably small,
but we believe
>> that the document should present more analysis than
it does at present.
> 
> I tried making this more clear in the security section:

> http://dev.w3.org/2006/waf/access-control/Overvi
ew.html#security

We might want to mention that implementations should not
allow other 
methods than GET, and not allow the user to specify
username/password or 
http-headers in conjunction with this, without taking extra
precaution 
to make sure that that is safe. I.e. XHR2 will allow other
methods than 
GET, but only if the server opts-in to it.

/ Jonas

On Thu, 20 Sep 2007 20:21:25 +0200, Jonas Sicking
<jonassicking.cc> wrote:
>> http://dev.w3.org/2006/waf/access-control/Overvi
ew.html#security
>
> We might want to mention that implementations should
not allow other  
> methods than GET, and not allow the user to specify
username/password or  
> http-headers in conjunction with this, without taking
extra precaution  
> to make sure that that is safe. I.e. XHR2 will allow
other methods than  
> GET, but only if the server opts-in to it.

Added.


-- 
Anne van Kesteren
<http://annevankesteren
.nl/>
<http://www.opera.com/>