Re: HTTP status code equivalents for file:// operations - compat with xhr

On Tue, 18 Aug 2009 06:22:49 -0400, timeless <timeless@gmail.com> wrote:

> I'd rather we formally indicate that using file urls in
> XMLHttpRequests is not expected to work with an explanation that there
> are security concerns which prevent XMLHttpRequest safely exposing
> arbitrary file urls.

Saying in the spec that it's not expected to work sounds fine.

However, 3 out of the 4 main browsers support it. Behavior and security  
could be aligned and improved.

For example:

1. Don't allow access to file: files from a non-file: origin.

2. "file://localhost/" and "file:///" are equivalent. (Browsers convert to  
the one they support.)

3. file://bark/path and file://meow/path are different origins.

4. Accessing a non-file: origin resource from a file: origin can be  
allowed (like it is in Safari), at least as a non-default option.

5. Make file:///c:/ and file:///d:/ different origins if necessary, so  
access isn't allowed across drive boundaries. More specifically, only  
allow file:///c:/dir/test.html to access files in file:///c:/dir/ and  
sub-directories of file:///c:/dir/. I think Firefox does something like  
this.

I'm not making light of security, but I believe it can be done.  Any  
additional rules that are agreed upon should improve file:// security in  
browsers, not make it worse.

> People who need access to local files should use a locally bound web
> server or if the content is something they control, JSON or an iframe.

I disagree with the 'should'. They can, and they'd *currently* be better  
off. But, I don't think it has to be that way.

> something like:
> In order for implementations to protect their users, XMLHttpRequest
> implementations MAY choose not to support file urls or MAY choose
> whatever error values they like.

That sounds good.

Say that file: security wasn't an issue and compat with xhr was desired.  
Do you consider the status code idea a good way to make file: work better  
with xhr, or does simulating status codes sound too complicated?

Thanks

-- 
Michael

Received on Tuesday, 18 August 2009 17:31:38 UTC