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

David Kendal 於 4/15/2017 12:54 PM 寫道:
> 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. 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.

"Downloads" is a sibling directory of "Documents" and child directory of 
the user directory on Windows 10. Since this is a catch-all downloads 
folder, it may contain sensitive files, so I'd imagine allowing an HTML 
file to read everything in this directory would be viewed as an 
unacceptable security risk.

> 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.

I'd also imagine it unlikely that anyone would want to implement a 
directory-dependent (i.e., operating system-dependent) JavaScript API.

It seems that what you'd need is not a new JavaScript API, but a totally 
new application/manifest format like *.htmlapp that contains the HTML 
file. This would guarantee that the HTML file is scoped to a safe 
quasi-directory.

However, this presents a problem since you then need viewers/editors 
created for this niche format to be able to easily modify the offline 
application. Further, this format would be a competitor format to 
operating system-dependent application formats, so there'd be market 
incentive *against* a native implementation. Why would Microsoft, for 
example, want to add support for this offline application format when 
they'd like you to create a Windows Store app instead?

Received on Saturday, 15 April 2017 23:46:25 UTC