The question is based on this issue in Chromium. It is marked as
Do you see any reason to block a local html file from accessing another local html file located in the same folder?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
I know this is an old question, but I didn't see this important fact mentioned anywhere:
Chrome allows you to add a folder on your file system as a local Web application. Once you do that, files in that folder no longer need to be accessed through the
file: protocol -- they become accessible through the
chrome-extension:// protocol, e.g.,
chrome-extension://[app_id]/somefile.html. When accessing your files this way, the restrictions on local file access do not apply.
True, you need to write a small, three-line
manifest.json file  that specifies the name of your application, but if you want to use multiple local files as a local Web application, it makes some sense, security-wise, to require that you use Chrome's extension architecture to indicate clearly what folders on your hard drive should be accessed like Web applications. That way, Chrome can assume that everything else on your hard drive is not a Web application, and lock down permissions on non-app HTML files that get loaded in the browser. The addition of the
manifest.json file adds only a few bytes to your folder, and it doesn't get in the way if you want to use your files in some other browser that does allow unfettered file access.
I don't know the real answer, but here's a good guess:
It's common to use File -> Save As... to save HTML to a file. Often users will save HTML files from different web sites to the same directory (perhaps named "Downloads"). Allowing one of these files to access the other (and possibly upload it somewhere) would be a privacy leak.
Since there are more users than developers and users are less security-aware on average, protecting users probably seems more important.
Even without this feature, it's still possible to create web applications that work offline. See: http://diveintohtml5.org/offline.html