New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 4197 link

Starred by 30 users

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Feb 2010
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

  • Only users with Commit permission may comment.

Sign in to add a comment

Further restrict access of file URL

Project Member Reported by, Nov 7 2008

Issue description

It sucks that viewing an HTML document at a file:// URL compromises the 
confidentiality of your entire file system.  We should follow Firefox's 
lead and further restrict the privileges of file:// URLs.

Comment 2 by, Nov 7 2008

[also see bugs 795514 and 1463961 for previous discussions]
We should probably wait for upstream so we can avoid forking 
SecurityOrigin to do this.
Labels: Mstone-X
There is now an upstream bug for this:

Comment 7 by, Apr 23 2009

Issue 10909 has been merged into this issue.
Issue 13671 has been merged into this issue.
Labels: Restrict-View-SecurityTeam
Labels: -private
Continuing our discussion from the other bug....

The upstream WebKit bug is marked fixed. What do you think remains to be done? 
Adopting the Firefox tweak to only allow access within the same directory hierarchy 
seems simple enough. This should at least restrict theft to the downloads directory.

What's the deal with XHR vs. directory listings? If XHR does not "leak" directory 
listing data then that's also a useful defense, i.e. you'd need to guess the name of 
a download to steal it.
The Firefox policy is super complex.  It's more involved than just restricting access to the current directory.  The 
first step is understanding what exactly they're doing.
Justin, this might be a great bug for you :)

Anyone got any ideas re: my behavioural question of XHR vs. paths that resolve to 
directories? Hmm, I suppose you could just iframe a file:/// URL and then steal the 
generated directory DOM with JS :-/

Comment 14 by, Oct 26 2009

Yeah; plus, there's a lot to steal at paths that are fixed or trivial to brute-force. 

Some assets live at hard-to-guess paths, but these are easy to get to via
fixed-location documents. For example, on my box, there's about two dozen files that
name my home directory living in c:\windows. Once you're there, you can go to
<path>\Application Data\Mozilla\Firefox\profiles.ini, read it to get the
unpredictable profile URL, and snatch the password store or browsing history.
@scarybeasts, I don't have permissions on the upstream Webkit bug, but I'm willing to take this if you can forward 
on the relevant details. 

For anyone curious, the description of Mozilla's policy is here:
The bug that tracked their implementation is here:

The downside to Mozilla's approach is that it breaks local page hierarchies. I vaguely remember some web developer 
backlash over the change. Any thoughts on how to address that? Because, whatever solution we choose is almost 
certainly going to have the same result.

Comment 16 by, Oct 26 2009

I think Adam at some point commented that the description on is very
inaccurate (but I might be making this up - check with Adam :-).

There was an earlier discussion about potential approaches, but essentially, the
parent-level check sounds like a reasonably good approach; *except* that it needs a
special case for downloads to /, /foo, /tmp, ~, ~/foo, and
$whatever_your_shared_download_dir is, to account for all potential usage scenarios.

Other options are:

1) Honoring MotW / ADS Zone.Identifier tags we already emit on Windows, and devising
a similar mechanism for Linux / MacOSX, to differentiate between files downloaded
from the Internet and local HTML, and disable JS for the former. This breaks apart
when interacting with Firefox, etc.

2) Disabling all JS within the default download directory. Does not account for users
with "always ask where to download" checked, etc.

3) Nuking all file:/// JS, with a command-line override such as
--enable-local-js=/dir. The reasoning here would be that if 10 applications happen to
rely on an undocumented, poorly thought out, and insecure behavior - they should suck
it up.

When Dean tried this earlier disabling file:/// cookies for the same reason (with
--enable-file-cookies option given), it caused a handful of complaints from
developers. Given that MSIE already disables all file:/// JS by default, maybe it's
not that extreme.

@jschuh: there's no particular hurry on this bug. There are other more interesting 
bugs to look at for M4 if we end up with any cycles.
That Moz doc looks reasonably accurate, actually.  We might want to try something like 
that behind a command-line flag / WebCore::Setting.  You can look at 
allowUniversalAccessFromFileURLs to see an example of how to do something like that.  
There are a bunch of easy plumbing patches to get started.  I'd recommend working on 
this in small steps at first.
I'm keen to take a crack at this, thanks to learning about this area fixing the XHR 
vs. directories bug.
I'm sure Adam won't mind if I steal this bug from him :)

I don't want to get complicated like Mozilla, but it should be simple to restrict 
file:// access to the current directory and below only.

Comment 20 by, Nov 11 2009

1) What about content saved in user home dir, common download dir, c:\, /, or other
locations of this type? This is definitely pretty common, how do you discourage this
behavior or warn about the risks? Or, would you special-case these locations?

2) The reason Mozilla implementation is complicated is very likely that there is a
body of file:///-installed JS-based projects that rely on the ability to read files,
set cookies, etc (we already had some complaints after disabling file:/// cookies). I
don't think we should complicate or weaken the design because of this, but it makes
sense to provide simple override.

We could for example check for .allow_access in current directory, with specific
permissions; assuming all browsers reject dot-file downloads, this could not be
trivially circumvented by web content. Though we would need to verify...
My personal plan, now that Adam has done his evil thing of enticing me into a problem, 
is to gradually restrict file:/// access to match that of other browsers.

After that, we can probably do an experiment for Chrome 5 Beta or so, where we disable 
all file -> file access unless you specify a command line flag.

Comment 22 by, Nov 11 2009

Global command-line flag is probably a bit evil, because the user, wanting to run an
obscure file:/// app at one time, would probably modify his global shortcuts, and
effectively enable this mode for all downloads forever.

At the very least, we should have --enable-file-access=/within/this/dir/only.
Another idea we had was a "Developer mode" like incognito that would allow access
between file URLs.  In normal user mode, we could block this kind of access.

Comment 24 by, Dec 17 2009

Labels: -Area-BrowserBackend Area-Internals
Replacing labels:
   Area-BrowserBackend by Area-Internals

 Issue 35455  has been merged into this issue.
The following revision refers to this bug: 

r39287 | | 2010-02-17 14:58:43 -0800 (Wed, 17 Feb 2010) | 9 lines
Changed paths:

Chromium pieces to use the WebKit support for isolation file:// documents in
their own unique domains.
By default, we use this isolation for security. We provide a command line switch
override for developers: --allow-file-access-from-files

BUG= 4197 
TEST=WebKit test pending

Review URL:

The following revision refers to this bug: 

r39304 | | 2010-02-17 16:07:28 -0800 (Wed, 17 Feb 2010) | 12 lines
Changed paths:

Revert 39287 - Chromium pieces to use the WebKit support for isolation file:// documents in
their own unique domains.
By default, we use this isolation for security. We provide a command line switch
override for developers: allowfileaccessfromfiles

BUG= 4197 
TEST=WebKit test pending

Review URL:
Review URL:

The following revision refers to this bug: 

r39334 | | 2010-02-17 20:18:25 -0800 (Wed, 17 Feb 2010) | 9 lines
Changed paths:

Chromium plumbing for new file:// security flag, including test_shell support.
This change does not alter behaviour but will enable a WebKit test to be

BUG= 4197 
TEST=WebKit test pending

Review URL:

The following revision refers to this bug: 

r39343 | | 2010-02-18 00:11:11 -0800 (Thu, 18 Feb 2010) | 9 lines
Changed paths:

Flip the "unique file:// URI origin" flag to on. Add the
--allow-file-access-from-files developer switch. Turn on this flag for the UI
tests, which depend on the old behaviour.

BUG= 4197 
TEST=WebKit test submitted upstream

Review URL:

Labels: -Restrict-View-SecurityTeam
Status: Fixed
Fixed on trunk! Tests pass! Miracle!
Will be interesting to see if there's any complaints when the next dev channel release 
goes out. I'll make sure to take care of the release notes, and an e-mail to chromium-

Also, removing view restriction since this is all well documented in Adam's post:

This CL broke all the O3D samples and the WebGL conformance tests when run from local folders.

All of them require the ability for XHR to read at the current folder of the HTML document or below.  With this CL 
that no longer works on Chrome but still works on every other browser including top of tree Webkit.

Can this be revisted?
does it still not work if you run chrome with --allow-file-access-from-files ?
It does work in that case. Is that the desired result?  I know for me I just want it to work when I launch 
Chrome in the normal way, ie, click the icon.  

I download some samples, I drag them from the finder into Chrome, Safari, Firefox, they should just work. I 
shouldn't have find out about some obscure flag.

For the last 6 weeks, since this was checked in, I had just assumed Chromium was broken and have been 
waiting for a fix while I did all my work in Minefield and Webkit. I finally decided to see when it broke by 
downloading 9 versions of Chromium until I found which at which version things stopped working and then 
looked at the logs to find this CL. I hope we don't expect every developer to have to figure this out when they 
grab some samples off the net and try to run them from their local hard drive.
@gman: sorry for the breakage. Unfortunately, the reason for the different behaviour 
vs. the other browsers is that Chromium is now much more secure than other browsers 
regarding file:// URI handling.
A good background on this area is found in Adam's blog post:

The Firefox subdirectory approach initially seems like a good idea until you think 
about the "Downloads" directory :-/

Any developers who want the old behaviour permanently can add the command line switch 
--allow-file-access-from-files to their browser launch. Since the vast majority of 
our millions of users are not developers, it makes sense to protect them by default.

I'll make sure we note this in our v5 release notes.
Not only developers need to be able to run web applications that are hosted on a local file system. A command 
line switch is not a solution because average users don't know how to use it.

The scenario in aforementioned blog article starts with a user opening an HTML file attached to an email. 
HTML is active content and opening an HTML file attachement is just as dangerous as opening an executable 
attached to an email. The behavior introduced by this CL is akin to an OS running the attached executable 
without the ability to do anything. What's the point of opening an HTML file and executing the JS inside it just 
to find out that it breaks because it can't load anything else. We might as well disable the JS inside it 

What happened to the idea to restrict file access to the file's siblings and their descendants? Was it abandoned 
because it didn't mitigate the risk of malicious file saved to a users home directory exposing that entire 

Comment 36 by, May 18 2010

I, too, am working for Generic Large Corporation on a web app run from the local 
filesystem.  A few of us on the team are quite upset at the security restrictions 
placed on Firefox and Chrome, since we have spent considerable effort making our app 
run in IE, Firefox, and Chrome, though our client only requires IE6.  Although we 
should be able to adapt our app to work with Firefox's restrictions eventually, 
Chrome's are impossible to adapt to with our heavy reliance on XMLHTTPRequest to load 
XML resources and a few other things.  For the moment, the only browser we can market 
as being compatible with is Internet Explorer.  This situation, as I'm sure you can 
agree, sucks.
The command line option solves the problem for developers and savvy users, but then they will be unprotected 
from now on. This all-or-nothing policy is not the best that Chrome can do.

Maybe we can have something more user-friendly and page-based?

Similar to IE, an infobar may appear at the top (like the password-saving and the new translate-to bar), 
allowing permanent local access for that file. Something like:

Warning: foo.html is trying to read data from foo.txt. Do you want to allow it?
[Allow once]   [Always allow]   [Don't allow]

User clicks the button and never have to worry again.

@megazzt: sorry for the pain this is causing. It's unfortunate that the file:/// 
security model was so broken; fixing it was always likely to entail some pain. One 
solution if you need full file path control would be to supply a mini-webserver 
script. Something like Python might be an excellent choice. Things then run very 
1) The trust model is the user electing to run your Python script. Complicated file-
based trust decisions are kept out of the browser. Good.
2) Standard, well-understood Same-Origin-Policy is used for security controls.

@aureliojargas: that's a possible solution, thanks for suggesting it. The main 
downside I see is that users are conditioned to just click-through whatever simple 
dialogs get in their way. This is why the IE approach isn't strong.
I am also getting a lot of complains with this change.  I built and maintain JavaScriptMVC ( ) a jQuery framework.  The download and getting started guide include an app that uses XHR to get client-side templates and mock AJAX files.

This change breaks the demo. My product looks like it doesn't work in one of the fastest growing browsers, especially by developers.  This potentially has serious implications for me and the 3 other people who depend on JavaScriptMVC.

If the info-bar approach doesn't work, what about putting up the "Evil Red Screen" that chrome puts up for potentially unsafe websites.  If this is good enough for other pages, why not for the filesystem?

Including a webserver is not an option.  It's important to make JavaScriptMVC seem easy, and any extra hassle makes the framework seem less attractive.

I've started to tell people about the command line, but many people can't figure it out.  What about a menu option for the given page?  This will be easier for people to figure out.

If there is anything I could to do help, please let me know.  

I can't believe you shipped this change! Way to break compatibility with the web, guys.
-1. What happened to the idea of bringing discontinuous changes in "a slow, inform the users" rather than the "sudden lets kill all existing apps that use this functionality" ? 

I agree with @JustinBMeyer comment above and hope you'll reconsider.

Comment 42 by, Jun 25 2010

This issue has been closed for four months. Comments here aren't being actively monitored and won't contribute to improvements in Chromium. 

We're discussing selective loosening the local file policy in  issue 47416 . If you are in favor of that change please star the issue. If you have have helpful suggestions or (ideally) can contribute code then add a comment to the bug. However, please refrain from unproductive complaining and "me too" comments.

Comment 43 Deleted

Labels: Type-Security
Project Member

Comment 46 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 47 by, Mar 10 2013

Labels: -Area-Internals -Type-Security Cr-Internals Type-Bug-Security
Labels: allpublic

Sign in to add a comment