The coming WebKitGTK+ 2.4 apocalypse [LWN.net]

By Jonathan Corbet
August 8, 2017

It is well understood that old and unmaintained software tends to be a breeding ground for security problems. These problems are never welcome, but they are particularly worrying when the software in question is a net-facing tool like a web browser. Standalone browsers are (hopefully) reasonably well maintained, but those are not the only web browsers out there; they can also be embedded into applications. The effort to do away with one unmaintained embedded browser is finally approaching its conclusion, but the change appears to have caught some projects unaware.

In early 2016, Michael Catanzaro sounded the alarm about security issues with the widely used WebKitGTK+ browser engine. At the time, security issues were turning up in WebKitGTK+ with great regularity, but nobody was calling them out as such; as a result, they were not getting CVE numbers and distributors were not bothering to ship updates. That created a situation where Linux desktop systems were routinely running software that was known to have security issues that, in many cases, could be exploited via a hostile web page or HTML email attachment.

Eighteen months later, Linux users can count themselves as the beneficiaries of a great deal of focused work on the part of Catanzaro and his colleagues. WebKit vulnerabilities and, in particular, vulnerabilities that show up in WebKitGTK+, are now regularly fixed by most (but not all) mainstream Linux distributions. Even the abandoned QtWebKit engine has picked up a new maintainer and is now "only" a year and a half behind the current WebKit release which, Catanzaro notes, "is an awful lot better than being four years behind". Progress is being made.

Progress in one part of the software ecosystem has a way of highlighting the relative lack of progress elsewhere, though. As Catanzaro explains in detail in his 2016 post, there are multiple versions of the WebKitGTK+ API, one of which ("WebKit1") was last supported in WebKitGTK+ 2.4, which was released in early 2014 and has not seen any security fixes for a long time. To stay current, applications need to move forward to the current WebKitGTK+ API, a process which can involve significant amounts of pain depending on how involved the application is in the rendering process. For applications that just need the engine to render some HTML, the API change is evidently not that hard to deal with. Or, at least, that is the case if moving to a current WebKitGTK+ release doesn't present other sorts of API issues. That is where the rub turns out to be.

GNOME is based on the GTK+ toolkit; as one would expect from the name, WebKitGTK+ also uses GTK+. But WebKitGTK+ versions after 2.4 only use GTK+ version 3.x, having left support for GTK+ 2 behind. GTK+ 3.0 was released in early 2011, meaning that application developers have had over six years to make the change. But, should there happen to be any laggard applications out there that have not moved forward to current GTK+, they will also be unable to move to anything resembling a current WebKitGTK+ browser engine. This could be a problem, as distributions are starting to simply remove their WebKitGTK+ 2.4 packages, breaking any applications that depend on it in the process.

Which applications might those be? On a Fedora 26 system, a query turns up these packages:

The Banshee music player. The 2.6.2 release shipped by Fedora came out in 2014; the project's web page mentions a 2.9 development release that also came out in 2014.
The claws-mail email client and, in particular, the "fancy" plugin used to render HTML mail. Claws seems to have a reasonably active development community, but it would appear to be more focused on producing minor releases with obnoxious changes to default behavioral settings than moving to GTK+ 3. A request for GTK+ 3 support filed in 2011 drew the response: "Good luck to whoever tries to work on that task". More recently, developers have started to work on the problem more seriously, but it's not clear when the work will be done.
gmusicbrowser, another music player. It last released in 2015; the repository shows no commits for over a year.
The GnuCash financial application. GnuCash, too, seems to have an active (if small) development community. The 2015 bug report also shows a slow start to the problem, but GnuCash is nearing a 2.8 release that should include the required updates. The project is looking at moving away from WebKitGTK+ altogether, since it's overkill for the task of drawing a few charts.
The kazehakase web browser. The latest release shown on the web site is from 2009.
The Lekhonee WordPress publishing tool, which does not appear to have a current web page anywhere.
mono-tools. The last commit was a license change in 2016.
SparkleShare, a file-synchronization application, last released in 2015.
Techne, a simulation package last released in 2011.
Tech Talk PSE, billed as "superior technical demonstration software". One commit in 2015, otherwise nothing since 2012.

A quick check on an openSUSE Tumbleweed system turns up others, including the Midori browser (last release in 2015).

One suspects that many of the above packages could simply vanish with few users even noticing. But some of them, including claws-mail and GnuCash, have significant user communities. They have, at this point, been fairly publicly caught out and revealed as failing to keep up with changes in the environment in which they run. The results go beyond shipping an application dependent on an outmoded toolkit; an email client should not be feeding arbitrary attachments to a browser engine with known security problems, for example.

Users of some of the faster-moving distributions are already seeing the effects of this move. Arch has already dropped WebKitGTK+ 2.4, and Fedora will do the same in its next release. Expect some scrambling as the developers of affected applications (those which still have developers, obviously) scramble to do forward-porting work that probably should have been completed several years ago and completely unmaintained applications just disappear. Development communities can be just like the rest of us: happy to procrastinate until the deadline looms. Arguably, distributors should make a point of imposing such deadlines more often.

to post comments

Active Desktop says hello

Posted Aug 9, 2017 2:12 UTC (Wed) by flussence (guest, #85566) [Link] (41 responses)

We've been watching new programmers learn and forget this over and over for the past twenty years, and the lesson never seems to stick: HTML belongs inside the web browser, anywhere else it's short-term developer gratification with long-term consequences.

Browser engines these days are more complicated than nuclear reactors. The damage from one mistake can last for comparable lengths of time: entire internet civilizations have come and gone, yet we're still dealing with fallout from IE6. I wonder if Chromium and its various forks with periodic table/nuclear-themed names are aware of their own irony.

Maybe it's time to start treating them with that level of caution and planning for future maintenance and decommissioning of web rendering engines, instead of encouraging everyone to take one like it's free candy? I guess that horse has already bolted from the barn though. Stay tuned for the webkit-gtk3 version of this article, coming sooner or later...

Active Desktop says hello

Posted Aug 9, 2017 4:13 UTC (Wed) by drag (guest, #31333) [Link] (3 responses)

Even in a web browser it's not too hot.

This is one of those things that unless you are using a Linux distro that stays very up to date on everything chances are you have some pretty severe web browser vulnerabilities. This is one of the small advantages to using Google-Chrome as they maintain their own upstream repositories you can pull from and that way users have a easier time staying up to date.

Active Desktop says hello

Posted Aug 9, 2017 10:52 UTC (Wed) by roc (subscriber, #30627) [Link] (2 responses)

If you download Firefox or Chrome from the vendor and use that, it will update itself.

But if your distro doesn't provide timely browser updates maybe you should change distros.

Active Desktop says hello

Posted Aug 9, 2017 14:10 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

I think you are going to have a hard time convincing Debian Stable users to switch to Arch.

Active Desktop says hello

Posted Aug 9, 2017 15:11 UTC (Wed) by TRS-80 (guest, #1804) [Link]

Debian security follows Firefox ESR; the day after stretch was released firefox-esr was upgraded from 45 to 52 in jessie and stretch.

Active Desktop says hello

Posted Aug 9, 2017 7:48 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (25 responses)

If we want people to stop embedding HTML renderers, we need to come up with something to do the jobs people embed HTML renderers for that is both safer and easier to use.

Active Desktop says hello

Posted Aug 9, 2017 7:58 UTC (Wed) by NAR (subscriber, #1313) [Link]

I remember one case 15 years ago when our GUI developers implemented an internal HTML viewer for reading documentation. I asked them why not simply spawn Netscape Navigator. Their answer was that it's an easy introductory task for a new developer (using a widget from a library). People embed HTML renders for reasons like this.

markup and scripting how could you

Posted Aug 9, 2017 9:14 UTC (Wed) by johnjones (guest, #5462) [Link] (7 responses)

there are few reasons to use native widgets any more... since you have to provide a mobile/tablet application often its just best to stick to "web"

so how about allowing a decent system for turning off all the clutter of a browser (history menu item and the like) and providing a rendering engine of the users choice in a plain window ?

regards

John Jones

markup and scripting how could you

Posted Aug 9, 2017 9:57 UTC (Wed) by karkhaz (subscriber, #99844) [Link] (4 responses)

This exists. It's called Electron [0]. An electon app runs in its own stripped-down instance of chromium, and is written in the usual web languages. They're slow and use enormous amounts of memory. An example of such a program is the GitHub desktop app [1].

I'm waiting for somebody to write an Electron port of Emacs, so that I can render the HTML of a web page in a text editor written in Lisp interpreted by JavaScript on HTML widgets compiled to C compiled to LLVM IR compiled to machine code.

[0] https://electron.atom.io/
[1] https://desktop.github.com/

markup and scripting how could you

Posted Aug 9, 2017 11:35 UTC (Wed) by arachnist (subscriber, #94626) [Link]

It's almost there. Click the "Try Online" button on http://spacemacs.org/

markup and scripting how could you

Posted Aug 9, 2017 12:19 UTC (Wed) by johnjones (guest, #5462) [Link]

electron means managing the library and lets say someone wants to use the firefox ?

I meant allowing control to disable all controls and present only a viewing portal
something like text/html; charset=UTF-8; menu=none

markup and scripting how could you

Posted Aug 11, 2017 17:11 UTC (Fri) by yokem_55 (subscriber, #10498) [Link] (1 responses)

Electron is part of the problem here. How many of those apps have outdated chromium builds bundled in? I've been hoping that electron can move to a run-time +app deployment style that can keep the deployment updated independently of the app but I get the feeling app devs like the current arrangement.

markup and scripting how could you

Posted Aug 11, 2017 17:37 UTC (Fri) by karkhaz (subscriber, #99844) [Link]

> Electron is part of the problem here.

I wasn't advocating Electron, I think it's terrible.

> a run-time +app deployment style that can keep the deployment updated independently of the app

by deployment, do you mean chromium, and by app, do you mean what runs inside chromium? Because that sounds a lot like the world wide web...

markup and scripting how could you

Posted Aug 18, 2017 3:10 UTC (Fri) by Mook (subscriber, #71173) [Link] (1 responses)

There was a firefox --app. It was never really popular, because it was essentially just xulrunner without the ability to control when the platform updates and no guarantees of API stability.

Maybe it'd work out better now given the additional web APIs (which means they can't break them willy-nilly anymore, maybe)?

markup and scripting how could you

Posted Aug 19, 2017 16:20 UTC (Sat) by flussence (guest, #85566) [Link]

It *does* work better: the entire Vivaldi browser is really just a webextension. In fact if you run `vivaldi-bin --app=''`, it drops you into a completely vanilla Chromium browser (about 20 times faster, I might add).

Active Desktop says hello

Posted Aug 9, 2017 12:45 UTC (Wed) by skx (subscriber, #14652) [Link] (15 responses)

I suspect in the case of email we're too far gone down the wrong route.

I wrote a console based email-client, with Lua scripting, and one thing that I added was the ability to view emails written in markdown. Once I got it implemented though I realized there was no way that anybody other than a small number of friends would ever send me such things.

A shame really, as markdown would have been great for simple formatting of email.

Content-Type: text/markdown

Posted Aug 9, 2017 18:25 UTC (Wed) by dkg (subscriber, #55359) [Link] (10 responses)

i like this idea, skx. You might get a slightly larger "small number of friends" if you promoted the idea of a text/markdown alternative to other MUAs. I tend to work on the notmuch project, and i suspect the other developers there would be interested.

I imagine a number of other MUA developers could get behind this as well. How do you resolve the issue of different markdown flavors?

Content-Type: text/markdown

Posted Aug 9, 2017 18:33 UTC (Wed) by skx (subscriber, #14652) [Link] (4 responses)

Honestly? I just picked the first Lua-based markdown parser/renderer that I could find and used that.

While I know that there are significant differences in different flavours of markdown most of those are irrelevant in simple emails.

(i.e. The cases that are difficult such as nested lists, tables, etc, aren't the kind of things that users manually type too often. Mostly they use bold, italic, and if they're really keen they might write a link or two in markdown format - but the latter is often a stretch.)

I'm not even sure where to start with any proposal/standard process short of spamming a few mailing lists, but certainly "text/markdown" is what I used. I also added a flag for "forcibly treat _this_ email as markdown".

I should polish it a little and document it in my mail-client sometime soon:

https://lumail.org/

Content-Type: text/markdown

Posted Aug 9, 2017 19:54 UTC (Wed) by jani (subscriber, #74547) [Link] (3 responses)

I think you could start producing standards compliant markdown MIME messages by wrapping the messages in a multipart/alternative container, and including both text/plain and text/x-markdown (or text/markdown if you go by [1], or text/x-rst for reStructuredText for that matter) parts. Since the point of lightweight markup is that it's close to plain text, you could just use the same contents for both parts. If you include the text/plain alternative I believe most MUAs will cope just fine.

Trying to send the entire message using some obscure MIME type will not fly, at least not until you've reached critical mass. But hey, you gotta start somewhere!

For the Notmuch Emacs frontend [2], if there's an elisp renderer for text/whatever MIME type, adding a handler for it should be trivial. Also, FWIW, it already has a way to display any part using user specified MIME type, provided there's a handler for it.

[1] https://tools.ietf.org/html/rfc7763
[2] https://notmuchmail.org/notmuch-emacs/

Content-Type: text/markdown

Posted Aug 11, 2017 21:35 UTC (Fri) by derobert (subscriber, #89569) [Link] (2 responses)

FYI: x-prefixes are now generally considered to have been a mistake, or at least an idea that didn't work out. See BCP 178. Appendix B gives rationale, but in short there are better ways to generate private names, and anything that is intended to be interoperable winds up having to keep the X- name forever to avoid a flag day. So you wind up with the X- name de-facto (or actually) standardized anyway, defeating the purpose.

Content-Type: text/markdown

Posted Aug 11, 2017 22:00 UTC (Fri) by jani (subscriber, #74547) [Link]

Thanks. Makes sense.

Content-Type: text/markdown

Posted Aug 13, 2017 4:31 UTC (Sun) by roc (subscriber, #30627) [Link]

This matches what we learned about vendor prefixes in Web APIs.

Content-Type: text/markdown

Posted Aug 10, 2017 16:48 UTC (Thu) by dbaker (guest, #89236) [Link] (4 responses)

I'm one of the alot devs (https://github.com/pazz/alot, which is a frontend for notmuch) we've talked about using markdown to generate HTML messages, but I really like the idea of using markdown as an interchange format instead. It's much richer than plain text, but without the insanity that HTML brings.

I think that using CommonMark would be a good way to go, it's already spec'ed and it's what github uses, which makes it pretty ubiquitous.

If alot and notmuch-emacs both supported the same flavor of markdown and could communicate with each other that way it would be a good start.

Content-Type: text/markdown

Posted Aug 10, 2017 16:54 UTC (Thu) by skx (subscriber, #14652) [Link] (3 responses)

Sounds like a plan is coming together! I'm not sure how much coordination is required, but it might be worth moving the discussion elsewhere.

I guess I'm thinking of two-things:

* Incoming messages of text/markdown will be rendered as markdown, whether via an export to HTML and a dumping via Lynx, Links, w3m, or similar. (Depends on console vs. GUI a lot. Obviously the user should select their preference, as they might already do now to prefer text/plain to text/html, or vice-versa.)

* Outgoing messages can be sent as multi-part/mixed with both text/plain and text/markdown

There might be fiddly details to be made, but those two core things seem like they should be non-controversial. I'd agree CommonMark is probably the way to go right now, standards are good :)

Content-Type: text/markdown

Posted Aug 11, 2017 0:23 UTC (Fri) by dbaker (guest, #89236) [Link] (1 responses)

Maybe multipart/alternative instead of multipart/mixed? That would allow the sender to generate a plaintext or html alternative to the markdown for clients that don't know about text/markdown.

Content-Type: text/markdown

Posted Aug 11, 2017 4:29 UTC (Fri) by dkg (subscriber, #55359) [Link]

i agree it should be multipart/alternative, not multipart/mixed

If no one has a preference for another place to take the discussion, i recommend the notmuch mailing list since that should already be a decent place for discussing alot and notmuch-emacs.

Content-Type: text/markdown

Posted Aug 11, 2017 10:28 UTC (Fri) by felix.s (guest, #104710) [Link]

Wasn't Markdown intended to be directly human-readable? And doesn't the definition of text/* encourage implementations to fall back to direct displaying? Why bother with the multipart/* nonsense?

Active Desktop says hello

Posted Aug 9, 2017 21:46 UTC (Wed) by zlynx (guest, #2285) [Link] (1 responses)

The history of markdown is that it comes from what people were already doing to format their plain text email and newsgroup messages.

Markdown grew as a way to convert the existing practices into a prettier HTML format.

Saying that "markdown would have been great for simple formatting of email." is kind of backwards that way. :-)

sending and receiving text/markdown

Posted Aug 11, 2017 4:37 UTC (Fri) by dkg (subscriber, #55359) [Link]

The nice thing about just sending the markdown directly is that you might be able to guarantee a more limited/safe set of functionality, instead of opening the door to all the bugbears that lurk in full-blown HTML. Of course, to get that safety, you'd have to be disciplined about not allowing too much extra stuff into the markdown variant at render time (i.e. no "let me just stick some raw html in here" verbatim blocks)

Active Desktop says hello

Posted Aug 9, 2017 23:54 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

There's a thread on mutt-user for converting markdown into the text/plain part and adding a text/html as a multi-part alternative. That's probably better these days.

Active Desktop says hello

Posted Aug 10, 2017 20:24 UTC (Thu) by jubal (subscriber, #67202) [Link]

MailMate (on OSX) does that too.

Active Desktop says hello

Posted Aug 9, 2017 9:50 UTC (Wed) by rwmj (subscriber, #5474) [Link] (6 responses)

Tech Talk PSE defines HTML as its rendering format (and despite claims in this article, it is not dead, it's mature working software). This is a very successful and flexible way to generate slides which is future-proof.

Also the problems here are entirely caused by WebKit not providing a stable API. If they had thought at all about their downstream consumers, none of this would be happening.

Active Desktop says hello

Posted Aug 9, 2017 10:40 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> Also the problems here are entirely caused by WebKit not providing a stable API. If they had thought at all about their downstream consumers, none of this would be happening.

To their credit, they're usually pretty good. However, the problem comes down to the process splits in WebCore forcing some things to now be async and GTK/glib sucking at hiding the difference between sync and async calls. When your "run some JavaScript" code is now across a pipe, you have to go back to the event loop to send and wait for the result. How in the world would you have kept the old API which just returned the result directly in a glib-based world?

Active Desktop says hello

Posted Aug 9, 2017 10:49 UTC (Wed) by eru (subscriber, #2753) [Link] (2 responses)

Also the problems here are entirely caused by WebKit not providing a stable API.

I got the impression the major pain is actually GTK2+ -> GTK3+. Stable APIs in the free software world are about as rare as hen's teeth, the kernels are probably the only true examples, perhaps also the classic Xlib (fast being deprecated).

Compare to Windows, where Win32 really sucks, but at least it has sucked the same way for decades, so you have a good change of running a 32-bit program from 1997 on Windows 10, or at least the porting task is simple, if you have the source.

Active Desktop says hello

Posted Aug 9, 2017 11:56 UTC (Wed) by mirabilos (subscriber, #84359) [Link]

I can really understand not wishing to move to GTK+3, though…

Active Desktop says hello

Posted Aug 9, 2017 13:47 UTC (Wed) by chrisV (guest, #43417) [Link]

The pain is not really GTK+2->GTK+3. The pain is as much the bump from the webkit-1 API to the webkit-2 API.

webkitgtk-2.4 provided the webkit-1 API for both GTK+2 and GTK+3. In addition it provided the webkit-2.0 API (ABI version 3.0) for GTK+3 only. webkitgtk-2.5 onwards dropped support for the webkit-1 API completely, and also bumped the webkit-2.0 API to ABI version 4.0, where it currently remains until the next round of breakage.

The net result is that any programs using the old webkit-1 API have to be rewritten to use the webkit-2 API in order to be safe, which includes GTK+3 programs such as empathy (still in current GNOME). In addition any GTK+2 programs using the webkit-1 API have to be ported to GTK+3 as well, such as claws-mail and gnucash.

It is a mess.

Active Desktop says hello

Posted Aug 9, 2017 16:18 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link]

We provide API/ABI stability for as long as practical. There are basically two reasons why we might break API/ABI:

1) A new major version of GTK+ is out. We have to have a new API/ABI, because GTK+ does. We can't support an unlimited number of APIs forever, sorry, so after a certain number of years, we'll drop support for the old version. For GTK+ 2 -> GTK+ 3 we allowed three years (2011 to 2014). For GTK+ 3 -> GTK+ 4 we'll probably do something similar, so you can expect another forced transition to GTK+ 4 maybe in 2021 or thereabouts, probably after GTK+ 5 is stable. No doubt there will be another apocalypse around that time.

2) A very major architectural change. The transition to a modern mutiprocess WebKit was the only such event in the history of the WebKit project. I would not expect another. That was a one-time break, made at the same time we dropped GTK+ 2 support.

So really we've only ever had that one major API break ever. It was just a very big one, which is why dealing with the transition is hard.

WebKitGTK+ is not a constantly-moving target. We are not Chromium. You'll no doubt have to update your application again in the future whenever we drop support for GTK+ 3, but that won't be anytime soon. You also might need to update your application once we manage to properly sandbox the secondary processes, as eventually we would not want to support unsandboxed operation anymore, but that's distant future and maybe we can schedule that to happen at the same time. We have also had more minor API breaks, but I don't think we've had a single complaint about those. We used to have frequent changes in some web process API that was explicitly marked as unstable, but to my knowledge that only ever once affected one application, and only once. We no longer have any API that's marked as unstable, so that should not be a problem going forward.

Now, web content rendering is constantly changing, but you should be under no illusions that web content rendering is part of the library's stable API. Certainly we cannot promise that the JavaScript DOM API will never change. If your operating system's login screen depends on a web engine never changing (hi Antergos), then you should probably do some QA before releasing a new WebKit update. But if the C API breaks, you should file a bug.

Active Desktop says hello

Posted Aug 10, 2017 14:01 UTC (Thu) by kiko (subscriber, #69905) [Link]

And, somewhat astonishingly, a few days after this post they have committed a GTK+3 port and released a new 1.2.0 version:

http://git.annexia.org/?p=techtalk-pse.git;a=log;h=35d7e2...

That's pretty solid turnaround for a repo which hadn't been touched in nearly 2 years.

Active Desktop says hello

Posted Aug 9, 2017 21:23 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

I don't think that HTML rendering is something only the web browser should be allowed to do. There are other places where you want to show formatted text, and HTML+CSS is a standard way to achieve that; like it or not, HTML mail is widely used and needs to be rendered in the MUA.

However, you are probably right that there should be a single library for HTML rendering -- which obviously is the one the web browser uses too. Then it has some hope of being maintained and secure. Apple's approach may have some merit: as I understand it, if your iOS app wants to render HTML it has to use the standard WebKit. (Then either the ABI stays compatible, or Apple decides to break compatibility with older apps and they just stop working. Either way you don't run unmaintained and vulnerable code.)

Security considered irrelevant

Posted Aug 10, 2017 4:00 UTC (Thu) by ncm (guest, #165) [Link]

Indeed, when your app just generates its own HTML to render, do security holes in your HTML renderer matter? Your app will not generate any HTML that tickles the security holes. If your app is converting external data to HTML, if that can make your app generate bad HTML, that's your app's problem.

If your app gets HTML from somewhere and just passes it along, then heaven help you.

Active Desktop says hello

Posted Aug 11, 2017 0:29 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

>However, you are probably right that there should be a single library for HTML rendering -- which obviously is the one the web browser uses too.
I think I need to clarify my point: one size *doesn't* fit all here, a lot of people using the xxxx-large size aren't equipped to wield it safely. E-mail and instant messaging is a prime example of where you'd want to keep the HTML renderer as dumb as possible, since trying to blacklist bad behaviours with a loaded gun the size of WebKit or Gecko is a Sisyphean endeavour. Heck, even Mozilla seems to always have their hands full keeping up with the ad industry's creative new ways of violating human rights, and that's after they've already done all the legwork to make “evergreen browsers” a thing even for the likes of Debian Stable. There's no way to have an “evergreen xulrunner”, which is probably one reason why they killed it. But we still have WebKit to worry about.

I'd feel a lot safer if everyone could distill the existing second-tier HTML libs (QtGUI's, gtkhtml, Dillo, etc.) into one decent library that knows when to say no. Don't pull in half an operating system for a what-if, just provide a button to open something in a real browser if necessary. (And in incognito mode by default please — I don't think there's a legitimate reason to open most links from external apps in a normal profile, especially local files.)

Active Desktop says hello

Posted Aug 13, 2017 7:57 UTC (Sun) by epa (subscriber, #39769) [Link]

You can distinguish between an HTML renderer and a full Web browser engine with JavaScript and http client.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 9, 2017 9:52 UTC (Wed) by leot (guest, #115920) [Link]

Hello Jonathan,
just a small nit pick. At least Midori 0.5.11 can also be built with WebKitGTK+ 2 API
(hence latest stable and supported release of webkit-gtk).

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 9, 2017 11:56 UTC (Wed) by danpb (subscriber, #4831) [Link]

techtalk-pse has now been ported to Gtk3 and thus modern WebKit :-)

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 9, 2017 14:19 UTC (Wed) by lisandropm (subscriber, #69317) [Link]

We the Debian's Qt/KDE team have been trying to get rid of Qt4's webkit since long It's really complicated when you have tons of reverse dependencies around. We couldn't make it for Stretch, but we will definitely need to do it for Buster.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 9, 2017 16:22 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (18 responses)

Some limited good news:

* Banshee only needs WebKitGTK+ for some plugin, which has been disabled in Fedora 27, so Banshee is not endangered. It's probably for the better that it's losing its WebKit integration, as nobody ever paid any attention to https://bugzilla.gnome.org/show_bug.cgi?id=747030.
* claws-mail also only needed WebKitGTK+ for some plugin, which has also been disabled in Fedora 27. It will be fine too.
* The Fedora GnuCash package is now bundling WebKitGTK+ 2.4 as part of its build process, so it will not be going anywhere either.

claws-mail

Posted Aug 9, 2017 16:33 UTC (Wed) by corbet (editor, #1) [Link] (9 responses)

The "some plugin" needed by claws-mail is the one that allows reading HTML mail, so its loss is not insignificant. I would love to live a life where I didn't get HTML mail, but that's not this world, alas.

claws-mail

Posted Aug 10, 2017 21:36 UTC (Thu) by Karellen (subscriber, #67644) [Link] (8 responses)

I get two types of HTML mail. One is HTML mail written by actual people, in an email client (including web-based clients), which contains a plain-text alternative.

The other is spam and marketing fluff, which is HTML-only.

I personally find the ability to distinguish between these two types of mail, by the fact that I can't actually read the email with no content, a win.

claws-mail

Posted Aug 10, 2017 21:50 UTC (Thu) by corbet (editor, #1) [Link] (7 responses)

In my experience, that approach works fine as long as you don't get email (that you need to read) from airlines, banks, or customers...

claws-mail

Posted Aug 14, 2017 21:30 UTC (Mon) by robbe (guest, #16131) [Link] (6 responses)

Wait, your actual bank sends you e-mail, and expects you to read it? Would my bank ever do that, I’d tell them: So long, and thanks for all the phish!

Customers would presumably fall into Karellen’s class of actual people using real mail clients.

Can’t speak to how often you fly, but personally I could live with passing one mail per month to an external viewer (i.e. web browser).

I do posit, that people in _some_ jobs need to be aware of the contents of marketing fluff, even as it invariably comes with a non-existent or broken text/plain alternative.

claws-mail

Posted Aug 14, 2017 22:41 UTC (Mon) by anselm (subscriber, #2796) [Link] (2 responses)

Wait, your actual bank sends you e-mail, and expects you to read it? Would my bank ever do that, I’d tell them: So long, and thanks for all the phish!

Actually, my bank sends me near-realtime e-mail notifications of movement in my accounts, duly signed and encrypted with GnuPG (I have a special GnuPG key pair that I use only for banking, for safety). It's really quite convenient.

banks doing PGP

Posted Aug 15, 2017 18:12 UTC (Tue) by robbe (guest, #16131) [Link] (1 responses)

That’s really cool. Would you mind naming this bank?

banks doing PGP

Posted Aug 16, 2017 8:44 UTC (Wed) by anselm (subscriber, #2796) [Link]

1822direkt, out of Frankfurt, Germany. (Disclaimer: I have no business interest in them beyond that of a (mostly) happy customer.)

claws-mail

Posted Aug 15, 2017 6:58 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (2 responses)

My bank and my credit card issuer, which is a wholly-owned subsidiary of my bank, do indeed send me e-mail that they think I will want to read. Every actual piece of phishing spam I have ever received has been obviously "phishy" compared to a genuine communication from an ostensibly reputable financial institution. (The - probably deliberate, given the psychology of phishing - abysmal standard of proofreading is the most trivial giveaway.)

phishing mails

Posted Aug 15, 2017 18:18 UTC (Tue) by robbe (guest, #16131) [Link] (1 responses)

Yes, phishing mails I get are mostly of very bad quality. But relying on that seems really shoddy security.

Why do you figure that these mails are deliberately bad? To target only the most gullible of victims?

phishing mails

Posted Aug 16, 2017 8:55 UTC (Wed) by anselm (subscriber, #2796) [Link]

This is fairly well-established in the case of Nigeria-419 scammers (“I can get you $$$$$ but you must send me $$ first”), who need to deal with any potential victims who reply to the scam on a case-by-case basis – in order to save themselves work, the scammers try to concentrate on people who are greedy enough to fall for the scam but not smart enough to figure out they're being scammed.

As far as “enter your Amazon/banking/… account details on this unrelated web site immediately or you will be locked out”-style phishing goes, this can be mostly automated, and therefore the phishing mails are becoming much better-looking than they used to.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 9, 2017 17:02 UTC (Wed) by spot (guest, #15640) [Link]

banshee has had webkitgtk disabled since 2.6.2-20. Fedora 26 got an update to 2.6.2-22 a month ago (it also fixes a ton of other annoying issues in banshee).

The 2.9 code branch of banshee never made it out of beta, and aside from some automated translation commits, is utterly abandoned.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 9, 2017 19:38 UTC (Wed) by chrisV (guest, #43417) [Link] (6 responses)

Does that mean that empathy is going to be dropped from gnome-3.26 and gnome is going to go back to pidgin? empathy still uses webkit-1/webkitgtk-2.4 and there is no sign of any rewriting going on.

Thankfully pidgin never adopted webkit; but unfortunately the video support in pidgin is not as good as it is in empathy.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 9, 2017 20:53 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (4 responses)

We dropped Empathy from GNOME a long time ago for various reasons. There is zero chance that we would add Pidgin.

But the Empathy WebKit2 port is already complete. The master branch is not currently releasable due to some half-baked UI changes that I merged, but we could do a release right away if we back out the UI changes. Just requires an hour or two of effort.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 9, 2017 23:43 UTC (Wed) by chrisV (guest, #43417) [Link] (3 responses)

> We dropped Empathy from GNOME a long time ago for various reasons.

It is in http://ftp.gnome.org/pub/gnome/apps/3.24/3.24.2/sources, and also in http://ftp.gnome.org/pub/gnome/apps/3.25/3.25.4/sources. I guess that is an artifact of the way the gnome ftp site is automated. Quid est gnomus.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 10, 2017 2:35 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link] (2 responses)

OK we're not going to actually delete all the previous releases, or stop anyone from releasing new versions. Eventually someone (maybe me... *shudder*) will release another new version on ftp.gnome.org.

We just don't consider Empathy to be a core app anymore. It's great for chatting with software developers, but not great for chatting with your friends, because your friends have never heard of any of the protocols it supports. So it's not useful to have installed by default, and it's no longer released as part of GNOME. You won't find it if you peruse the boring NEWS files in the GNOME release announcements.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 10, 2017 15:44 UTC (Thu) by chrisV (guest, #43417) [Link] (1 responses)

I see. However it is not an issue of deleting previous releases: no one would do that. The point is that it is put in the gnome ftp source directory for particular gnome releases, including for gnome-3.24.2 (the current stable version) and gnome-3.25.4 (the development release for gnome-3.26). On your analysis, it shouldn't be there. Have a look at the links I gave and you will see what I meant.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 10, 2017 17:20 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

You found a bug!

I think I've fixed it going forward. It should not be there for 3.25.90.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 9, 2017 22:02 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

>> Does that mean that empathy is going to be dropped from gnome-3.26 and gnome is going to go back to pidgin?

This implies GNOME was using Pidgin in the first place. That is not the case. Pidgin was always an independent project and not part of GNOME. It just uses the GTK toolkit.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 13, 2017 22:44 UTC (Sun) by magnus (subscriber, #34778) [Link] (1 responses)

Embedded web page rendering is one case where it might have been beneficial to have a more 'fat' component system in place in the OS where the web renderer could run in a separate process and you communicated using something more high-level and stable, rather than using the DLL model with C subroutines that bind tightly to the rest of the application.

The coming WebKitGTK+ 2.4 apocalypse

Posted Aug 14, 2017 1:10 UTC (Mon) by Fowl (subscriber, #65667) [Link]

Welcome to webkit2 ;)

Really though everything but the most basic embedding needs to access javascript objects, provide host functions, etc. so it rapidly becomes more complex.