[webapp container] Consider defaulting WebPreferences.allowFileAccessFromFileUrls to true

PES has a commercial partner that would like to ship their HTML5 as a webapp in our store.

To load the assets off the filesystem, we need this to be set somehow.

Request priority be bumped a bit higher...

It's only low because this is just a change of the default value - applications can set this already in order to loosen the policy if they wish to

How can an app set this on their own then?

Alex: that depends on what kind of app we’re talking about:

 a) A webapp that uses the HTML5 container: unfortunately this container hasn’t been migrated to oxide yet (it’s still using QtWebKit under the hood). This is a known issue that’s actively being worked on by Alex Abreu and targetted for RTM. When that happens, we need to ensure that the WebView embedded in the container has "preferences.allowFileAccessFromFileUrls: true".

 b) A normal Ubuntu app that embeds a WebView from the Ubuntu.Web module: in that case setting "preferences.allowFileAccessFromFileUrls: true" on the webview instance should do the trick.

I think I'm using (a). I didn't realize I was using QtWebKit... I thought I was using oxide!

Here's the packaging I created for the app:

app.desktop:

[Desktop Entry]
Name=XXXX
Comment=XXXX
Type=Application
Icon=128.png
Exec=webapp-container --fullscreen file:///opt/click.ubuntu.com/com.canonical.achiang/current/test-sd.html
Terminal=false
X-Ubuntu-Touch=true

###

app.json:

{
    "template": "ubuntu-webapp",
    "policy_groups": [
        "networking",
        "audio",
        "video",
        "webview",
        "content_exchange"
    ],
    "policy_version": 1.2
}

###

manifest.json:

{
    "description": "XXXX",
    "framework": "ubuntu-sdk-14.10-html-dev2",
    "hooks": {
        "xxxx": {
            "apparmor": "app.json",
            "desktop": "app.desktop"
        }
    },
    "maintainer": "Alex Chiang",
    "name": "com.canonical.achiang",
    "title": "XXXX",
    "version": "0.1"
}

Ah! In that case you’re actually using (c):

 c) A webapp that runs in the webapp-container executable. It’s usually used to point at remote URLs, but I guess the local URL case is valid too. webapp-container does use oxide, so all we need to do is patch it to set "preferences.allowFileAccessFromFileUrls: true" on its webview.

Adding a webbrowser-app task (the code for webapp-container lives under the webbrowser-app project), this is a fairly trivial change, but I’d like to get Alex Abreu’s opinion on it (thus assigning to him).

So, I've had a think about this. I don't think setting WebPreferences.allowFileAccessFromFileUrls is a safe default in Oxide (or even for the webbrowser), but could be used for the webapp container as long as we're not using it to open random files from anywhere on the filesystem.

Say, for example, a user navigates to a site that triggers a download of a malicious HTML file by using the Content-Disposition header. The user then opens this malicious file in their browser.

- With the current default file restrictions, the download won't be able to read anything else on the filesystem because each file path is treated as a unique domain by the browser.
- With WebPreferences.allowFileAccessFromFileUrls set to true, all file URL's are treated as the same domain which means that the malicious HTML file has access to anything on the filesystem that the browser can access. It can then read these files and send their contents to somebody else without any interaction

Ok, I think what we really need here is a concept of local application bundles in Oxide that doesn't involve using file URI's. Essentially, this would mean introducing a custom URI scheme (say, application://) where we give each application its own domain, and provide a way of mapping each domain to an application install on the filesystem. With this, code within an application would be able to access any file within its own bundle (because they have the same origin), but won't have access to other application bundles or other files on the filesystem.

WDYT?

Note -- as an app developer, I am not necessarily tied to (c), a webapp that runs in the webapp-container executable.

I simply googled "ubuntu html5 webapp" and followed the instructions near the first hit:

http://developer.ubuntu.com/publish/webapp/

and then:

http://developer.ubuntu.com/publish/webapp/packaging-web-apps/

Should I be using technique (a) instead? I just want to follow the best practice for the phone platform.

My use case is a commercial game, packaged as a local application with about 35MB in assets. I'd like to run it full screen with no browser chrome.

So far, it runs perfectly fine under webapp-container confinement, and using the --fullscreen arg to webapp-container successfully hides the Unity8 indicators...

I think Chris's comment #8 is about what we want to provide to developers like me, who want to use HTML5 as the best way to get cross-platform implementations.

This approach works especially well for games and other use cases that take over the entire screen and do not need platform widgets.

They'll expect to provide all their own assets and want to access them from the local filesystem.

I am not sure from reading comment #8 whether this is proposed to live in oxide itself or in webbrowser-app binary/qml but in any case, the concept of an "application bundle" seems sound to me.

> So, I've had a think about this. I don't think setting
> WebPreferences.allowFileAccessFromFileUrls is a safe default in Oxide
> (or even for the webbrowser), but could be used for the webapp
> container as long as we're not using it to open random files from
> anywhere on the filesystem.

Apps calling the webapp container are confined by apparmor, so I expect they won’t be allowed to open random files on the filesystem.
The browser app currently runs unconfined, so setting preferences.allowFileAccessFromFileUrls to true sounds dangerous indeed.

The concept of application bundles seems sound to me too.

> Should I be using technique (a) instead? I just want to follow the
> best practice for the phone platform.

(a) (the html5 ubuntu container) should be preferred where you want to make use of the default Ubuntu HTML5 theme and widgets, or if you want to use phonegap APIs. If you don’t need either of those, you’re probably better off with (b) or (c).

(b) definitely gives you more flexibility, as you get to write your own lightweight container in QML, which could be something as simple as that:

    import QtQuick 2.0
    import QtQuick.Window 2.1
    import Ubuntu.Web 0.2

    Window {
        visibility: Window.FullScreen

        WebView {
            anchors.fill: parent
            preferences.allowFileAccessFromFileUrls: true
            url: Qt.resolvedUrl("test-sd.html")
        }
    }

(c) would work too, provided we patch the webapp container to enable preferences.allowFileAccessFromFileUrls by default.

"The browser app currently runs unconfined, so setting preferences.allowFileAccessFromFileUrls to true sounds dangerous indeed." If there a reason it isn't confined on Touch or Desktop? With content-hub and sharing integration, I've been wondering why we can't ship a system profile for it.

> Is there a reason it isn't confined on Touch or Desktop?

There used to be a good reason for not confining it, but I fail to remember exactly what the issues were.
If you can come up with a system profile for it, I’ll gladly test it.

I've filed a bug on the webbrowser-app apparmor profile here: bug #1356516