On Tue, 18 Aug 2009 16:27:29 -0400, Adam Barth <w...@adambarth.com> wrote:
On Tue, Aug 18, 2009 at 12:50 PM, Michael A. Puls
II<shadow2...@gmail.com> wrote:
On Tue, 18 Aug 2009 15:25:35 -0400, Adam Barth <w...@adambarth.com>
wrote:
On Tue, Aug 18, 2009 at 10:30 AM, Michael A. Puls
II<shadow2...@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
