Comment 11 for bug 1393515

On 09/28/2015 11:56 AM, Seth Arnold wrote:
> I think the web browser is different from the file browser. If you hand
> your phone to a stranger, unlocked, with the intention that they can use
> the phone to dial someone or view the wikipedia entry for a topic under
> debate or check the weather or whatever, you'd really like it to be
> difficult for the person to make your life miserable. Dangerous
> operations should require re-prompting with pin or password.
>
> The file browser would allow someone to add .ssh/authorized_keys or
> other similar tricks. The web-browser is, as far as I know, a mostly-
> read interface that would have great deal of difficulty modifying
> content. Granted that there may be plaintext data on the phone that a
> user wouldn't want a stranger to have easy read access to, but that data
> should probably be stored encrypted anyway.
>
Sorry I need a little more context. Is the browser using the content hub
to browse these files? If not it is a security problem, browsers can not
be trusted, there are too many attack surfaces/vulnerabilities and
allowing it direct access to the fs, except where explicitly allowed
by policy, violates our security model. In this case blocking file://
is not sufficient, that relies on the browser behaving correctly,
which means assuming there are no vulnerabilities in the browser.

If however the browsing is done via the content hub and the user is granting
permission to the browser to access files, then this is out of scope. That
is if the owner hands their phone over to a 3rd party it is the owners
responsibility to make sure their data is secured in ways that a regular
user can not access it (ie, encrypted or stored in a separate user
account).