Online Accounts, QtWebKit and Mir

Tue Mar 19 12:51:10 UTC 2013

Hi all!
  I'm seeking for advice to solve an issue which will affect Ubuntu
Online Accounts -- especially on the phone/tablet, but possibly on the
desktop as well.
I hope you have time and patience to read this long e-mail. :-)
Feedback on any point is very appreciated.

Current situation
=================

Ubuntu Online Accounts can perform web-based authentications (such as
OAuth) on behalf of applications, by opening the website's
authentication pages into a QWebView. This is then embedded into the
GNOME control center by using the XEMBED protocol.
The service which provides this is signon-ui; it is using Qt4 (and
consequently the web engine used is WebKit1).
The signon-ui service has a very minimal UI, just the webkit view (or
username/password/captcha dialogs for non web-based authentication
methods) and its process exits after some time of inactivity.

Enter Qt5 and Mir
=================

The Ubuntu Online Accounts code can run with minor modifications under
Qt5. Qt5 still provides the WebKit1 engine, but the only way to access
that is via the QWidget-based bindings.
I've been told that QWidget-base applications don't work under Mir --
I'm not to worried about that: I guess it's a temporary defect with the
Mir QPA plugin which will get eventually fixed (maybe it's fixed
already, I don't know), but I mention it here just for completeness,
ready to stand corrected. :-)

Qt 5.0.x does not support XEMBED. However, for Qt 5.1 there will be
support from it, provided by the QPA backends (currently this is only
implemented in the XCB backend). To use it, one doesn't need any
platform-specific APIs [0].

So, as far as the desktop (using X11) is concerned, Ubuntu Online
Accounts will continue to work just fine in the future.

Enter QtQuick 2.0 and WebKit2
=============================

Apps in the phone/tablet are mostly QtQuick 2.0 based, and so will be
the (still under design) System Settings panel.
Despite the fact that signon-ui's UI is minimal and just encompasses a
WebView, there might be some reasons to move the implementation away
from QWidgets and use QtQuick 2.0.
However, currently QtQuick 2.0 offers only the WebKit2 API, which is
probably optimal for a standalone browser, but which is still missing
some features required by Online Accounts: the main one is the
possibility of having a per-view cookie jar. This is essential to
support multiple accounts per provider, and also greatly increases
security because it completely isolates the cookies you get while
logging into an online account with those from other online accounts of
from the user's browser (if it's QtWebKit based as well).

I've been discussing the issue with QtWebKit developers, but as of now
I'm still unclear about their opinion:
http://comments.gmane.org/gmane.os.opendarwin.webkit.qt/3484

As far as I can see it, these are the possibilities:

1) Implement the per-view cookie jar in WebKit2. This is the best end
result, but the hardest to achieve -- at least for a non WekBit expert
like me: it involves digging deep into WebKit code and, given all the
big stakeholders involved, passing through the code reviews could take ages.

2) Same as above, but while the reviews are in progress, apply the patch
to QtWebKit's Ubuntu packages. The longer the review process takes, the
more painful this solution will be.

3) Implement QtQuick 2.0 bindings for WebKit*1*, and keep them as a
separate module. I did this already, and it's more or less working [1].
This can link against an unmodified libQt5WebKit.so, but in order to
build the module we need to use some private QtWebKit headers -- and
since these headers are generated during the build, it practically means
that we need to have the QtWebKit source tree available in order to
build this.

4) Like #3, but move the module as an Ubuntu patch for QtWebKit. This is
far less dangerous than #2, because we are not modifying the QtWebKit
build, just adding a very small extra .so (which we might drop in the
future).

5) Like #4, but submit the code upstream. As you can read from the links
above, the QtWebKit developers are not very fond of receiving more
WebKit1-based code. Still, it might be possible to move both the QtQuick
2.0 module and the QtWebKitWidgets modules out of the tree by working on
a common interface, so maybe this approach might be well received.

Some words about security
=========================

As discussed during the last virtual UDS, the Ubuntu Engineering
security team will provide security updates for WebKit [2]. Both
QtWebkit's QWebView and the QML WebView are built from the same source
tree, so my understanding is that both would be supported by the
security team (even if involuntarily). That's because WebKit2
essentially uses the same code as WebKit1, just spread over different
processes. In fact the libQt5WebKit.so library contains most symbols
used in WebKit1 as well; the libQtWebKitWidgets.so library, as its file
shows, it's just a tiny wrapper around the Webkit1 API.

signon-ui is a very security-sensitive process, since it provides the
WebView for logging into the user's accounts. It is IMO necessary that
client applications don't directly play with the WebView to load remote
data, so the split-process approach that Online Accounts takes by having
the signon-ui process completely independent from the client application
is a good one. The signon-ui process could also be flagged with some
special security context so that the display compositor could decorate
its window in such a way that the user know that this window is really
what it claims to be.
signon-ui is essentially just a UI: it doesn't perform the
authentication itself: all the data it collects from the WebView is sent
over D-Bus to the signond process, which handles the secure storage.
Therefore, signon-ui doesn't even need to get disk-access (except for
reading a couple of config files), and can be easily confined.
(I'm writing all this because I've also considered the idea of turning
signon-ui into a library which would provide a WebView widget for
applications to use, but I eventually came to think that it's a very bad
idea)

Ciao,
  Alberto

[0]: A simple example:
https://qt.gitorious.org/qt/qtbase/commit/079e3b4f3ee3ebe225539b5a896fec1e38804e11
[1]: https://github.com/mardy/qt5webkit1
[2]:
https://blueprints.launchpad.net/ubuntu/+spec/client-1303-webkit-maintenance