在 2017年04月16日 01:54, David Kendal 写道:
On 15 Apr 2017, at 14:07, Roger Hågensen <rh_wha...@skuldwyrm.no> wrote:
Patrick makes a good point.
For example asking a user if it' sok for the HTML document to access
stuff in "C:\Users\Username\AppData\Local\Temp\" what do you think most
uses will do?
Just click OK, after all "they" have nothing important in that folder,
their stuff is in "Documents" instead.
This is why I added the restriction that pages can only request access
to directories that are parents of the directory they're in.
Maybe this is not enough.
The directories which users would save web pages to usually also contain
large amount of personal
data. E.g. "C:/Users/<user name>/Documents|Downloads" on Windows and
"/home/<user name>/Documents|Downloads" on linux. Temp directory is also
sensitive.
Asking permission for a sensitive directory is not ideal: users either
lose functionality of the saved page,
or risk losing privacy.
I admit I
don't actually know much about how Windows lays out files these days --
if the 'Downloads' folder is within some other folder that also contains
a load of private stuff. If so, or if that's so on some other popular
OS, maybe I'm wrong.
Browsers could also add restrictions that you can't request access to
the root directory or top-level subdirectory of an OS volume, or what-
ever else is needed for appropriate security on a particular OS.
It is impratical to blacklist all sensitive directories, because many
users use customized data
directories, e.g. "D:/work" or "D:/MyData".
Some participants on the Chrome bug thread suggested that Chrome could
look for some hidden file that would give files in the directory under
it XHR/Fetch access to that directory. That seems similar to what you
suggest, but I dislike the idea of a hidden file doing this unbeknownst
to users -- and even if it were visible, its function may not be obvious.
The major problem of this solution is that users may be tricked to
download such configuration file
to a sensitive directory, and open a hole permanently.
Here is my solution: restrict local file access to certain directory
naming partteners.
The use cases of local html files can be divided into two types: single
page application and
multi-page application.
For single page application, browsers restrict `foo.html`'s permission
to `foo_files/` in the same
parent directory. Note that it is already a common practice for browsers
to save a page's resource
to a `xxx_files/` directory; browsers just need to grant the permission
of `xxx_files/`.
For multi-page application, browsers requires that its "application root
directory" ends with `_webrun`
(or other sensible name). All files within an `xxx_webrun/` are treated
as same-origin, but they
can't access files outside of the `xxx_webrun/`.
There is no need to ask users for permission to `xxx_files/` or
`xxx_webrun/`directories. For html
files without such directories, access to local files may not be allowed.
It is much less likely that users would unintenionally or be tricked to
put files into an existing
`xxx_files/` or `xxx_webrun/`directory, so the security risk is
minimized. Browsers can even enforce it:
warn users when try to save a file into an existing `xxx_files/` or
`xxx_webrun/`directory.
Regards,
Duan, Yao.
