On Tue, 18 Aug 2009 06:22:49 -0400, timeless <[email protected]> wrote:
I'd rather we formally indicate that using file urls in
XMLHttpRequests is not expected to work with an explanation that there
are security concerns which prevent XMLHttpRequest safely exposing
arbitrary file urls.
Saying in the spec that it's not expected to work sounds fine.
However, 3 out of the 4 main browsers support it. Behavior and security
could be aligned and improved.
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.
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.
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.
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.
People who need access to local files should use a locally bound web
server or if the content is something they control, JSON or an iframe.
I disagree with the 'should'. They can, and they'd *currently* be better
off. But, I don't think it has to be that way.
something like:
In order for implementations to protect their users, XMLHttpRequest
implementations MAY choose not to support file urls or MAY choose
whatever error values they like.
That sounds good.
Say that file: security wasn't an issue and compat with xhr was desired.
Do you consider the status code idea a good way to make file: work better
with xhr, or does simulating status codes sound too complicated?
Thanks
--
Michael
