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

On Tue, Aug 18, 2009 at 12:50 PM, Michael A. Puls
II<shadow2531@gmail.com> wrote:
> 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:
>>> 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'm not sure browser behavior here is as interoperable as you seem to
believe.  For example, I don't think many browsers divide these kinds
of file URLs into separate origins.

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

This sounds like a good topic for HTML 6.

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

I'm not sure what you mean by the "Safari case," but it's unclear
whether dividing file URLs by UNC host name makes sense.  For example,
that wouldn't appear to work well in a deployment that uses AFS.
Also, allowing access to web URLs from file URL is probably a
disimprovement as well.

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

I'm saying this is a complex topic that will likely take many years of
experimentation to get right.  Writing this into the XHR spec now is
probably not the most expedient way to move this topic forward.

Here's a list of topics we should tackle before the file URL security for XHR:

1) Parsing of file URLs.  Currently browsers parse these URLs with
very different algorithms.
2) Cross-frame access from a file URL to a web URL.
3) Cross-frame access from one file URL to another.
4) Sub-resource loading from file URLs.

We need to consider the big picture here instead of focusing narrowly
on XHR, which is why I recommend tackling this issue as part of HTML
6.

Adam

Received on Tuesday, 18 August 2009 20:28:28 UTC