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

On Tue, 18 Aug 2009 16:27:29 -0400, Adam Barth <w3c@adambarth.com> wrote:

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

O.K.

>>>> 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,"

Requesting an http: resource from a file: page.

> but it's unclear
> whether dividing file URLs by UNC host name makes sense.

It's what 3.10 of RFC 1738 recommends. RFC 2396 ditched specifying stuff  
about specific schemes, which means file: needs to be specified in a  
different doc. RFC 1738 is all there is right now afaik.

> For example,
> that wouldn't appear to work well in a deployment that uses AFS.

I'm not sure how things work for AFS. What do paths look like?

> Also, allowing access to web URLs from file URL is probably a
> disimprovement as well.

O.K.

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

O.K.

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

True. Also, the main issue I've seen is that plug-ins often don't treat  
"file:///c:/" and "file://localhost/c:/" as the same.

> 2) Cross-frame access from a file URL to a web URL.

They're different origins. For example, document.domain for  
file://localhost/c:/ is "localhost" (in Opera).

> 3) Cross-frame access from one file URL to another.

Depends if the origins of the file URIs are the same or not.  
file://localhost/ | file:/// (files on your computer), file://bark/ and  
file://meow/ (files on intranet shares etc.).

> 4) Sub-resource loading from file URLs.

Sub-resource?

The short answer is to follow the same security restrictions as you would  
with HTTP.

You can't access file: from http.
You can't do cross-origin http (without the access-control stuff)
You can't communicate between windows/frames of different http domains.

There is postMessage though. Wonder if that works from file.

> 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

Yes, agreed. Thanks

-- 
Michael

Received on Tuesday, 18 August 2009 21:41:20 UTC