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

On 2017-04-17 13:53, duanyao wrote:
> 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/`.

I like that idea. But there is no need to treat single and multipage 
differently is there?


This can handle multipage fine as well.
Anything in the folder test.html_files is considered sandboxed under 

This would allow a user (for a soundboard) to drop audio files into
and so on.

And if writing ability is added to javasript then write permission could 
be given to those folders (so audio files could be created and stored 
without "downloading" them each time)

I just checked what naming Chrome does and it uses the page title. I 
can't recall what the other browsers do. And adds _files to it.

So granting read/write/listing permissions for the html file to that 
folder and it's subfolders would certainly make single page offline apps 

I have not tested how editing/adding to this folder affect things, 
deleting the html file also deletes the folder (at least on Windows 10, 
and I seem to recall on Windows 7 as well).
I'm not sure if a offline app needs the folder linked to the html file 
or not.
A web developer might create the folder manually in which case there 
will be no link. And if zipped and moved to a different 
system/downloaded by users then any such html and folder linking will be 
lost as well.

Maybe instead of d:\documents\test.html_files\
d:\documents\test.html_data\ could be used?
This would also distinguish it from the current user saved webpages.

Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0).
Roger Hågensen,
Freelancer, Norway.

Received on Monday, 17 April 2017 12:44:03 UTC