Comment 15 for bug 1393515

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.

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 a file browser in that it is read access. It is also true that lending a 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 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.