Online Accounts, QtWebKit and Mir

[Scott Kitterman]

On Tuesday, March 19, 2013 02:51:10 PM Alberto Mardegan wrote:
> 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/079e3b4f3ee3ebe225539b5a896fec1e38
> 804e11 [1]: https://github.com/mardy/qt5webkit1
> [2]:
> https://blueprints.launchpad.net/ubuntu/+spec/client-1303-webkit-maintenance

According to that blueprint, Canonical seems to intend to create (yet again) a 
unique fork, so if you're on a fork that only Canonical is using, you ought to 
be able to do whatever you want.

Scott K