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

On Tue, 18 Aug 2009 15:25:35 -0400, Adam Barth <w3c@adambarth.com> wrote:

> On Tue, Aug 18, 2009 at 10:30 AM, Michael A. Puls
> II<shadow2531@gmail.com> wrote:
>> However, 3 out of the 4 main browsers support it. Behavior and security
>> could be aligned and improved.
>
> We should tread carefully here.  The security model for file URLs
> isn't fully developed yet.

Yes, of course.

>> 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.
>
> It's unclear whether supporting these kinds of URLs is worth the
> security issues.  Keep in mind that getting this to work properly
> involves the cooperation of plug-in vendors.

By 'supporting', you mean in XHR, right? They're already supported in  
browsers for everything else.

I believe it's better to expose file: than platform paths that are  
different with each platform.

>> 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.
>
> This is a poor security choice.  The major browsers have been slowly
> moving away from the model where file URLs can access web URLs.  I
> suspect Safari may remove this ability in the future.

Yes, it's probably better left as a non-default, advanced user 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.
>
> Firefox has the most innovative security model for file URLs.  What
> they do is much more subtle than what you describe above.  Hopefully
> their model will spread to other implementations.  However, this
> doesn't seem like the right forum to push that agenda at this time.

Where do you suggest then?

>> 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.
>
> Your suggestions are a mix of security improvements and
> disimprovements.

What part is the disimprovement? The Safari case?

Note: I posted this suggestion to see if anyone thought it was a good  
idea. If not, I'll try to come up with something better. Or, are you  
saying that no matter what I come up with, if it deals with file:, it's a  
no-go?

Thanks

-- 
Michael

Received on Tuesday, 18 August 2009 19:51:23 UTC