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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
