Webkit maintenance strategy

jdstrand, 2013-04-03> Google announced they are forking webkit which complicates things and has implications for this plan: http://techcrunch.com/2013/04/03/google-forks-webkit-and-launches-blink-its-own-rendering-engine-that-will-soon-power-chrome-and-chromeos/

== Background ==
Upstream's model is essentially continuous development with occasional snapshots that are called releases. Upstream's model is to continually update their trunk, and have the different forks resynchronize as needed. Because of the rapid pace of WebKit development and all the different forked snapshots, the separate forks do not typically collaborate outside of pushing changes to upstream trunk. It is up to downstreams on how to use webkit in their projects with forks of WebKit being the preferred solution.
- Apple (forked for OS X)
- Google Chrome (embedded)
- webkit-gtk
- KDE (uses QtWebKit)
- Qt4/Qt5/Qt6...

In Ubuntu, two webkit libraries are currently supported: webkit-gtk and qtwebkit. These are totally separate and forked from different places
- Upstreams for libraries effectively do not provide updates
- webkit-gtk 2.0 is dropping gtk2 bindings
- Qt5 is removing support for Qt4
- Backporting is not feasible (volume, code changes, effectively no upstream coordination (CVEs aren't linked to patch commits))
- Other distributions have abandoned efforts to maintain webkit and there is no distro-coordination
- Upstream (ie, webkit-gtk and qtwebkit) do not maintain stable APIs so we can't push new upstream versions to older releases.

Current strategy is to take new upstream webkit-gtk releases, backout patches that break API and publish the new release. This works 'ok' for releases where the major release stays the same (eg, upgrading to 1.8.2 from 1.8.1 is not bad, 1.8.2 to 1.10 is doable, but 1.10 to 2.0 is impossible) but is not scalable, time-consuming and regression prone.

Now Ubuntu plans to use QML/Qt5 for its SDK and core applications, but between WebKit upstream's fork/resynchronize and webkit-gtk's and Qt's reluctance to backport patches and maintain API stability, Ubuntu must be able to provide timely security updates as well as maintain API stability.

Since the vUDS, Google has forked from webkit and created Blink. Apple immediately started removing Google code from webkit and Google is starting to heavily modify Blink. Google recommends that people not use Blink as a rendering library since the codebase will change too much. Google does provide the Chromium Content API which is much higher in the stack and could be used instead (it provides the chromium sandbox, seccomp2, https certificate verification, V8, etc).

Risks: Apple may stop committing to the public webkit tree and/or modify it without regard for downstreams. Google may stop providing the Chromium Content API, however, this appears to be an important part of their internal strategy.

== Proposal ==
Requirements:
 * Stable API for application developers
 * Easier and reliable security maintenance

Proposal:
 * Package Chromium Content library and develop Ubuntu SDK bindings for the Chromium Content library.
 * Ubuntu SDK applications, Ubuntu core apps and anything Canonical-supported (eg, webapps wrapper, online accounts, etc) must use these new bindings
 * Keep webkit gtk and qtwebkit in the archive, but declare them as unsupported
 * We patch important applications to support and use our bindings as needed
 * Several teams give a resource (not necessarily full-time) for supporting this effort. Eg Mobile apps handles Qt5, UE/Desktop gtk3, etc. UE/Security can assist.

Benefits
 * Meets requirements
 * Removes middle-man forks that have different requirements
 * Security updates become pulling the new Chromium Content library straight from upstream and reapplying our toolkit bindings on top rather than constantly backporting an ever changing library and API
 * We can sit on an api for years (we can add new stuff, but never break). We start with Qt5, then later gtk3 (if required). When Qt6 comes out, we pull the stabilized (ie, released) Qt6 webkit toolkit bindings from upstream and apply it on top of the upstream renderer, leaving our Qt5 bindings for people who want it. Same could be done for gtk4. Per bzoltan, the QML webkit APIs are quite small so pulling in a new Chromium Content library shouldn't be disruptive for 3rd-part apps, but we would need to coordinate updates for other internal consumers (webapps wrapper, etc)

Costs
 * One time cost of creating the library and bindings
 * One time cost of converting Canonical-written application to use these bindings
 * Ongoing cost of maintaining the toolkit bindings (eg, gtk3, qt5, gtk4, qt6)
 * Ongoing cost of maintaining distro patches for targeted applications (if there are any)

Questions:
 * "Maintaining our own webkit bindings? Why can't we just depend on upstreams to do the heavy lifting for us?"
  - We have depended on upstreams for bindings all along, but this model is broken. These upstreams we have depended on are middle men and have different goals than Ubuntu. Importantly, we will still work with upstreams for the real heavy lifting: security support in the browser engine. With 20+ security vulnerabilities a month in webkit, backporting these to 2 different divergent forks is not sustainable or a good use of time.

 * "Can't we just convince the Gnome and KDE to work together? Convince upstream WebKit to maintain sane bindings?"
  - No. We've tried and the resources aren't there. The upstream model is to constantly update the renderer and for others to fork and maintain their fork. Gnome chooses to fork, stabilize then maintain the Gtk bindings for 6 months, after which the toolkit bindings API is subject to change and deprecation. Qt chooses to fork webkit for their own QtWebKit, stabilize then move on to their next release, after which the toolkit bindings API is subject to change and deprecation. The proposed solution adheres to the upstream model and we fork at an appropriate time, stabilize our bindings, provide security support for those bindings (perhaps by utilizing Apple's tree). If time our fork right and base it on an appropriate tree (eg, Apple's), we only transition the renderer and stabilize our bindings on at 18-24 month intervals.

 * "Why not just maintain have a dedicated person to maintain webkit-gtk and qtwebkit?"
  - This is an option and is attractive because all of Ubuntu benefits, not just applications linked against Ubuntu's webkit. However, this does nothing to address toolkit deprecation like we are seeing with gtk2 and qt4 and is duplicated effort on the most expensive portion of maintaining webkit: fixing the 20+ CVEs per month. Synchronizing our renderer and maintaining our bindings means we can pull security patches from upstream (or Apple) and only ensure the bindings work. The security team has a dedicated person for the security patches, we just need help making sure the toolkit bindings work well.

Old pre-blink proposal:
 * We maintain our own WebKit branch (perhaps based on Apple's branch) with our own bindings based on upstream toolkit's bindings (ie, we adopt the fork/resynchronize model that upstream promotes rather than relying on others to do this for us). Think if this as 'libwebkit-ubuntu" (can be named anything). We then control our gtk and qt bindings such that the APIs are locked down which is attractive for developers cause they don't have to update their apps. The security team, the desktop team, the webapps team the mobile apps team can all will work together to make sure the bindings work and these team's become experts in toolkit bindings rather than in the highly-specialized ever-changing browser code.
 * Keep webkit gtk and qtwebkit in the archive, but declare them as unsupported
 * Ubuntu SDK applications, Ubuntu core apps and anything Canonical-supported must use our libwebkit-ubuntu
 * We patch important applications to support and use our webkit as needed
 * Several teams give a resource (not necessarily full-time) for supporting this effort. Eg Mobile apps handles Qt5, UE/Desktop gtk3, etc. UE/Security can assist.
 * We will need to occassionally transition the renderer

== Potential Work items ==
talk to Qt upstream if this is an intractable problem
talk to other Qt webkit users
update model for touch browser - QtWebkit is part of core image so it would go along with touch browser updates as part of core update (TBD)
look at how diff for bindings gets applied
how does rebase happen
api between webkit engine and qt itself (ie, is what the webkit library exposes stable enough so this is feasible) - webkit2 is changing a lot. webkit2 talks to webkit core api. the bindings deal with webkit core
investigate the Apple model more - how often does the render actually change, do they change their api so often that it makes it difficult

ScottK (kitterman) question:

What about other (non-Canonical) packages that use QtWebKit?

Work items for ubuntu-13.06:
[chrisccoulson] scope work for generating bindings for Chromium Content API: DONE

Work items for ubuntu-13.07:
[chrisccoulson] meet with stakeholders (security, sdk, desktop, phone foundations, touch web browser, online accounts) to plan next steps for scoped work: DONE
[chrisccoulson] create preliminary oxide build, so others can start contributing: DONE

Work items for later:
[bzoltan] discuss upstream QtWebKit's plans for dealing with Blink fork: POSTPONED