file:/ URLs not supported

Bug #1516249 reported by AlainKnaff
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
webbrowser-app (Ubuntu)
New
Undecided
Unassigned

Bug Description

file:/ URLs are not suported (... instead it passes it on to google when entered into URL bar, or raises a "network error" when followed from a page)

Being able to browser local html pages would be handy to work around bug #1516220 (lack of form completion or password manager), because that way could could store pre-filled forms somewhere on your home directory.

Well it is still possible to pull of this workaround, but it requires installing nginx (... and configuring it correctly to prevent people on the same Wifi from snarfing your password-containing templates...)

phablet@ubuntu-phablet:~/public_html$ lsb_release -rd
Description: Ubuntu 15.04
Release: 15.04
phablet@ubuntu-phablet:~/public_html$ apt-cache policy webbrowser-app
webbrowser-app:
  Installed: 0.23+15.04.20151103-0ubuntu1
  Candidate: 0.23+15.04.20151103-0ubuntu1
  Version table:
 *** 0.23+15.04.20151103-0ubuntu1 0
       1001 http://ppa.launchpad.net/ci-train-ppa-service/stable-snapshot/ubuntu/ vivid/main armhf Packages
        100 /var/lib/dpkg/status
     0.23+15.04.20150416-0ubuntu1 0
        500 http://ports.ubuntu.com/ubuntu-ports/ vivid/main armhf Packages

What I expected to happen:
  Visiting file:/ should show me a directory view of the root directory of the device

What happened instead:
  The phone passed the string file:/ on to google... D'oh... :-(

Revision history for this message
Olivier Tilloy (osomon) wrote :

If you wanted to browse the local filesystem, the correct URL would be "file:///", not "file:/".
Anyway, ubuntu touch’s security model prevents the browser from browsing the file system by design.

Changed in webbrowser-app (Ubuntu):
status: New → Invalid
Revision history for this message
AlainKnaff (kubuntu-misc) wrote :

> If you wanted to browse the local filesystem, the correct URL would be "file:///", not "file:/".

In any other browser I know, both work. If necessary, the browser adds the 2 missing slashes.

> Anyway, ubuntu touch’s security model prevents the browser from browsing the file system by design.

Huh? Could you explain how this improves security? As far as I can see, it encourages users to set up a local web server, potentially broadcasting confidential files to the local area, rather than keeping them on the phone.

Btw, other phone browsers, such as Android, do allow this.

If this is not a big effort to implement, please do, or at least until bug #1516220 is fixed.

Changed in webbrowser-app (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Olivier Tilloy (osomon) wrote :

> In any other browser I know, both work. If necessary,
> the browser adds the 2 missing slashes.

If browsing the local filesystem was allowed, this could easily be implemented, of course.

> Huh? Could you explain how this improves security? As far as I can
> see, it encourages users to set up a local web server, potentially
> broadcasting confidential files to the local area, rather than keeping
> them on the phone.

Ubuntu touch’s security model confines applications so that they can’t gain access to other applications’ data and files. The browser is no exception, thus it is not allowed to browse the local filesystem.
See https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement for a detailed specification.

This is meant to protect the average phone user against malicious applications.
If a user knows how to set up a local web server, they supposedly know what they are doing, and it’s their responsibility to ensure that they’re not giving away access to all their files to the outer world.

> Btw, other phone browsers, such as Android, do allow this.

Last time I checked, it didn’t. That was a while ago though, things might have changed. Android has a rather different security model though.

> If this is not a big effort to implement, please do, or at least until
> bug #1516220 is fixed.

As I wrote earlier, this is not a bug, it’s a (security) feature. So the confinement rules won’t be relaxed.
If you have a strong case against this decision, I encourage you to raise the topic on the ubuntu-phone mailing list, where the security team can participate in the discussion.

Please avoid confirming your own bug reports. Thanks for your time and bug reports, keep them coming!

Changed in webbrowser-app (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
AlainKnaff (kubuntu-misc) wrote :

> If browsing the local filesystem was allowed, this could easily be implemented, of course.

Other apps, such as the "Document Viewer" seem to be perfectly able to see the local filesystem... Same for the terminal app, and any programs started by it (... and this is a good thing too, please keep it that way!)

> Ubuntu touch’s security model confines applications so that they can’t gain access to other applications’ data and files. The browser is no exception,

Why not *make* it an exception? After all, in a way, it is supplied by Ubuntu themselves, and thus should be able to be trusted, no? And the Document Viewer seems to be an existing exception already.

> If a user knows how to set up a local web server, they supposedly know what they are doing, and it’s their responsibility to ensure that they’re not giving away access to all their files to the outer world.

Ok, so the user will note his passwords on a piece of paper, and a bystander reads it off from it too. Or he has the same password everywhere... (... and his favorite porn site gets hacked, and that was the same password as his bank...) So, even non-technical users have plenty of ways of screwing things up if safer alternatives are unavailable. The point here is, putting passwords in a file:/// would be one way to work around bug #1516220, and this is not available, potentially pushing users to less safe solutions.

>> Btw, other phone browsers, such as Android, do allow this.
>Last time I checked, it didn’t.

Please check again. Nowadays Android browsers (both Firefox and builtin browser) can browse file:/// URL's just fine. Obviously there are some directories where normal Unix permissions provide access, but all the others (including top level root directory) _are_ accessible. Firefox displays directory listings, however Android's builtin browser shows an empty page for directories. It *does* access them though, as it displays an error message for non-existing directories. And it does show .txt and .html files (and probably other file types too, but I'm to lazy to check them all. The point has been proven.)

> That was a while ago though, things might have changed. Android has a rather different security model though.

Well, I just pointed this out, as you seemed to be very sure that it didn't....

> Please avoid confirming your own bug reports. Thanks for your time and bug reports, keep them coming!

Sorry for this. I guess I was just pissed as seeing valid bugs marked invalid. From now on, I'll transition them back to "New" instead.

Changed in webbrowser-app (Ubuntu):
status: Invalid → New
Revision history for this message
Olivier Tilloy (osomon) wrote :

> Other apps, such as the "Document Viewer" seem to be perfectly able to
> see the local filesystem...

Document Viewer is only allowed to see files under $HOME/Documents.

> Same for the terminal app, and any programs started by it

Yes, the terminal app is a special case, and as you’ve probably noticed, it asks your su password at startup, which should make it really clear that it has special privileges and is not to be left in everyone’s hands.

> Why not *make* it an exception?

Because that would allow anyone who gets physical access to your phone to read any file on the FS, including sensitive information, thus largely invalidating the security model.

> putting passwords in a file:/// would be one way to work around bug #1516220

Another much safer way would be an app that stores those passwords with strong encryption and a master password. That would make for a nice addition to the ubuntu app store.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.