Fwd: Re: Couple of notes on Access Control

Since the questions are now public...


------- Forwarded message -------
From: "Anne van Kesteren" <annevk@opera.com>
To: "Marc Silbey" <marcsil@windows.microsoft.com>, member-appformats@w3.org
Cc:
Subject: Re: Couple of notes on Access Control
Date: Sat, 24 Feb 2007 10:04:05 +0100


On Sat, 24 Feb 2007 02:44:19 +0100, Marc Silbey
<marcsil@windows.microsoft.com> wrote:
> I want to give you a quick update on our review of the Access Control
> recommendation.

FWIW, I think it would  be better if you raised these points on
public-appformats@w3.org. I'd like to keep the technical discussion as
open as possible.


> We've reviewed some of the recommendation and it looks good. I've
> included a few comments below. That said we want to take a little more
> time next week to wrap up before sending out detailed comments.
>
> Here are a few comments and questions on Section 2
> 1. Why are we limiting this to HEAD and GET requests? Maybe it should
> also include POST and other verbs that are as safe as HEAD and GET. It
> makes sense that this can't be a generic mechanism for all verbs
> including future ones since we don't know the security model for future
> verbs

POST isn't really safe... The moment you did the request the damage is
already done, basically. On the other hand, <form>.submit() already does
cross-site POST if I remember correctly...

Ian Hickson wrote a proposal on how POST could work though for something
like XMLHttpRequest:

    http://www.w3.org/mid/Pine.LNX.4.62.0606062320020.10674@dhalsim.dreamhost.com

The specificaion leaves room open for this.


> 2. RE: "When a resource is said to be in error access to that resource
> MUST be denied". It may help the reader if we define "in error" or just
> replace this with "is prohibited" and then say that User agents should
> take care that the denial of access does not indicate existence or
> non-existence of resource. This helps prevent fingerprint attacks.

What "in error" means is defined throughout the specification. I agree
that we should probably clarify that whenever access is denied this should
not give any information back to the script / page initiating the request.


> 3. RE: "except ruleset"
> This is a minor nitpick, but I'll add it hear because we've discussed
> terminology a lot internally here. Maybe we should use "deny ruleset"
> instead of "except ruleset". Also it may help the reader if we
> explicitly state that deny rules always trump allow rules

The way it works is that access is denied by default. (This document only
applies in certain scenario's and only when specifications, probably
XMLHttpRequest 2 for instance, say that it applies and define how that
works (see the proposal above).) Then if access is explicitly allowed and
there's no rule matching in "except" (within the allow, except pair)
access is granted.

I agree that the current terminology isn't very good. I'd appreciate input
on that. Not just on the eventual attributes people will use but also on
the terms defined in the specification.


> I'll send more comments and questions next week as we review more

Cheers,



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

Received on Saturday, 24 February 2007 20:15:24 UTC