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

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.

> 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.

> 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.

> 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.

> 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.  As I said above, we should tread carefully here.

Adam

Received on Tuesday, 18 August 2009 19:26:38 UTC