W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2017

Re: [whatwg] Accessing local files with JavaScript portably and securely

From: duanyao <duanyao@ustc.edu>
Date: Mon, 17 Apr 2017 19:53:27 +0800
To: David Kendal <me@dpk.io>, Roger Hågensen <rh_whatwg@skuldwyrm.no>
Message-ID: <08118e09-3343-cdb6-5411-69db7137b3ef@ustc.edu>
Cc: whatwg@lists.whatwg.org
在 2017年04月16日 01:54, David Kendal 写道:
> On 15 Apr 2017, at 14:07, Roger Hågensen <rh_whatwg@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.
Received on Monday, 17 April 2017 11:54:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 17 April 2017 11:54:27 UTC