@chrisccoulson and @ken-vandine: I think that what we can do is leave file:// alone and let apparmor policy make sure it can only access what is needed behind the scenes (already works for webapps). Then for File/Open style-functionality (eg, in convergence) we do the content-hub file-picker as you suggested.
This means that file:// specified in the location bar is pretty limited-- I wonder if it is worth disabling (but probably not, it will have some utility in the app-specific areas) or oxide/webbrowser-app could check the return code and return something more helpful than a blank page. IMHO, returning a blank page for file:// accesses outside of the app-specific areas is of course fine security-wise and is a matter of UX. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to webbrowser-app in Ubuntu. https://bugs.launchpad.net/bugs/1393515 Title: browser allows browsing the phone filesystem Status in Canonical System Image: Confirmed Status in webbrowser-app package in Ubuntu: Confirmed Status in webbrowser-app package in Ubuntu RTM: Confirmed Bug description: Using a URL like: file:/// gets you to the root of the phone filesystem ... i assume this is not actually desired since we even block the filemanager app to go higher up then $HOME without requiring a password. The webbrowser-app should either: * behave like the file-manager (see bug #1347010 for details) * file:/// should be disabled altogether on the phone * webbrowser-app should run confined which would force the use of content-hub by limiting file:/// access to those paths allowed by policy To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1393515/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
