Can I kill option 1 right away? Capturing file:// in the browser won't even work as a band-aid in the short term. All it would take to get around that would be for me to open a page that contains some links to file: URLs and navigate to them. Yes, we have an API to intercept navigations in the main frame, but then I could get around that by making sure they navigate a subframe. Even if we had an API to intercept subframe navigations (and we definitely shouldn't), a webpage can still embed media or image elements pointing to file: URLs (of course, same origin restrictions prevent a remote attacker from being able to access the contents them, but a page can still display them to the user).
-- 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
