4 ms·

Thanks for pointing that out. I missed these 2 items on first glance. Limiting access to certain directories: https://github.com/WICG/writable-files/blob/maste

by asaph 8y ago

Thanks for pointing that out. I missed these 2 items on first glance. Limiting access to certain directories: https://github.com/WICG/writable-files/blob/master/EXPLAINER.md#limiting-access-to-certain-directories https://github.com/WICG/writable-files/blob/master/EXPLAINER... Limiting write access to certain file types: https://github.com/WICG/writable-files/blob/master/EXPLAINER.md#limiting-write-access-to-certain-file-types https://github.com/WICG/writable-files/blob/master/EXPLAINER... FWIW: On the surface, this appears to contradict the following quote from tfa: > ...ensures that the user is always in full control over what files and directories a website has access to. A sandbox is not full control.

ghayes 8y ago
If the user can control the sandbox, say by a runtime setting or preference, then the user still is in control, but default safe.
jmull 8y ago
> Not allowing websites to write to certain file types such as executables will limit the possible attack surface. The problem with that is there is no hard distinction between a data file and an executable. Essentially every kind of file, when opened, causes code to be executed, usually significantly influenced by the content of the file. This API is moving the security perimeter back, making it the responsibility of every local app that may open a file touched by this API — essentially every file it might open — to ensure unexpected/malicious content can’t do anything bad. That’s not going to happen. Instead, users are going to have to be “sure” not to open files via this API using sites they don’t trust. That’s pretty weak compared to what we’re generally used to today (which doesn’t seem strong enough already).