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