Comment 16 for bug 1393515

On 09/28/2015 02:23 PM, Jamie Strandboge wrote:
> Currently the webbrowser is not confined (there is another bug for that)
> but webapps are (so this bug doesn't affect, say, facebook in the store,
> but it does affect webbrowser-app). There is a bug to confine
> webbrowser-app and I agree that with that confinement should come
> content-hub integration.
>
> This use case Seth pointed out falls under
> https://wiki.ubuntu.com/SecurityAndPrivacySettings/ProtectingUserData
> and we are still in 'Phase 1': "For Phase 1, users desiring privacy and
> elevated security against casual theft should enable a PIN/password,
> protect that PIN/password against theft and not lend the phone to people
> they do not trust". In other words, the current implementation does not
> protect against lending to a bad actor-- there is only so much we can do
> without a guest account on the system designed for lending.
>
Yes bad actor is out of scope

> But, we haven't done all we can do without a guest account (ie, phase 1)
> yet and we shouldn't make it trivial to access potentially sensitive
> data. Seth is right to point out that the web browser is different than
right alternate user/guest user accounts are part of the solution to
the bad actor problem but outside of the scope of the web browser being
a problem.

> a file browser in that it is read access. It is also true that lending a

No, it is only by ui convention that the web browser is mostly read
only. Users can still exploit it to load external content and save it
to the file system, and an exploit can exploit the browser to have
full access to the file system.

ie. from a security pov mostly read access because of usage pattern
still must be treated as full read/write because the write access is
possible.

> phone to someone with your open session allows them to open all your
> apps as you (eg, adjust your email settings, request a password reset
> from facebook, etc). I think the website misses some of these finer
of course again, don't give your phone to a bad actor

> points, but ultimately I agree with John-- we can do more, today, while
> looking forward. How about having the (currently unconfined) webbrowser-
> app intercept file:// and use content-hub? While I think there are some
> UX issues to deal with (I doubt file:// access was considered in the
> current implementation and merely a byproduct of the chromium content
> api). This would then make it trivial to confine, would work in the
> converged world and prevent trivial read access to data today.
>
so as long as this happens along with confinement, that would be acceptable.
I don't care if the underlying access to the content hub is a hack, it
is the browsers direct access to the filesystem that needs to be curtailed