GNOME Web 3.14

It’s already been a few weeks since the release of GNOME Web 3.14, so it’s a bit late to blog about the changes it brings, but better late than never. Unlike 3.12, this release doesn’t contain big user interface changes, so the value of the upgrade may not be as immediately clear as it was for 3.12. But this release is still a big step forward: the focus this cycle has just been on polish and safety instead of UI changes. Let’s take a look at some of the improvements since 3.12.1.

Safety First

The most important changes help keep you safer when browsing the web.

Safer Handling of TLS Authentication Failures

When you try to connect securely to a web site (via HTTPS), the site presents identification in the form of a chain of digital certificates to prove that your connection has not been maliciously intercepted. If the last certificate in the chain is not signed by one of the certificates your browser has on file, the browser decides that the connection is not secure: this could be a harmless server configuration error, but it could also be an attacker intercepting your connection. (To be precise, your connection would be secure, but it would be a secure connection to an attacker.) Previously, Web would bet on the former, displaying an insecure lock icon next to the address in the header bar, but loading the page anyway. The problem with this approach is that if there really is an attacker, simply loading the page gives the attacker access to secure cookies, most notably the session cookies used to keep you logged in to a particular web site. Once the attacker controls your session, he can trick the web site into thinking he’s you, change your settings, perhaps make purchases with your account if you’re on a shopping site, for example. Moreover, the lock icon is hardly noticeable enough to warn the user of danger. And let’s face it, we all ignore those warnings anyway, right? Web 3.14 is much stricter: once it decides that an attacker may be in control of a secure connection, it blocks access to the page, like all major browsers already do:

Screenshot from 2014-10-17 19:52:53
Click for full size

(The white text on the button is probably a recent compatibility issue with GTK+ master: it’s fine in 3.14.)

Safety team members will note that this will obviously break sites with self-signed certificates, and is incompatible with a trust-on-first-use approach to certificate validation. As much as I agree that the certificate authority system is broken and provides only a moderate security guarantee, I’m also very skeptical of trust-on-first-use. We can certainly discuss this further, but it seemed best to start off with an approach similar to what major browsers already do.

The Load Anyway button is non-ideal, since many users will just click it, but this provides good protection for anyone who doesn’t. So, why don’t we get rid of that Load Anyway button? Well, different browsers have different strategies for validating TLS certificates (a good topic for a future blog post), which is why Web sometimes claims a connection is insecure even though Firefox loads the page fine. If you think this may be the case, and you don’t care about the security of your connection (including any passwords you use on the site), then go ahead and click the button. Needless to say, don’t do this if you’re using somebody else’s Wi-Fi access point, or on an email or banking or shopping site… when you use this button, the address in the address bar does not matter: there’s no telling who you’re really connected to.

But all of the above only applies to your main connection to a web site. When you load a web page, your browser actually creates very many connections to grab subresources (like images, CSS, or trackers) needed to display the page. Prior to 3.14, Web would completely ignore TLS errors for subresources. This means that the secure lock icon was basically worthless, since an attacker could control the page by modifying any script loaded by the page without being detected. (Fortunately, this attack is somewhat unlikely, since major browsers would all block this.) Web 3.14 will verify all TLS certificates used to encrypt subresources, and will block those resources if verification fails. This can cause web pages to break unexpectedly, but it’s how all major browsers I’ve tested behave, and it’s certainly the right thing to do. (We may want to experiment with displaying a warning, though, so that it’s clear what’s gone wrong.)

And if you’re a distributor, please read this mail to learn how not to break TLS verification in your distribution. I’m looking at you, Debian and derivatives.

Fewer TLS Authentication Failures

With glib-networking 2.42, corresponding to GNOME 3.14, Web will now accept certificate chains when the certificates are sent out of order. Sites that do this are basically broken, but all major browsers nevertheless support unordered chains. Sending certificates out of order is a harmless configuration mistake, not a security flaw, so the only harm in accepting unordered certificates is that this makes sites even less likely than before to notice their configuration mistake, harming TLS clients that don’t permute the certificates.

This change should greatly reduce the number of TLS verification failures you experience when using Web. Unfortunately, there are still too many differences in how certificate verification is performed for me to be comfortable with removing the Load Anyway button, but that is definitely the long-term goal.

HTTP Authentication

WebKitGTK+ 2.6.1 plugs a serious HTTP authentication vulnerability. Previously, when a secure web page would require a password before the user could load the page, Web would not validate the page’s TLS certificate until after prompting the user for a password and sending it to the server.

Mixed Content Detection

If a secure (HTTPS) web page displays insecure content (usually an image or video) or executes an insecure script, Web now displays a warning icon instead of a lock icon. This means that the lock icon now indicates that your connection is completely private, with the exception that a passive adversary can always know the web site that you are visiting (but not which page you are visiting on the site). If the warning icon is displayed, then an adversary can compromise some (and possibly all) of the page, and has also learned something that might reveal which page of the site you are visiting, or the contents of the page.

If you’re curious where the insecure content is coming from and don’t mind leaving behind Web’s normally simple user interface, you can check using the web inspector:

Screenshot from 2014-10-17 21:07:52
The screenshot is leaked to an attacker, revealing that you’re on the home page. Click for full size.

The focus on safety will continue to drive the development of Web 3.16. Most major browsers, with the notable exception of Safari, take mixed content detection one step further by actively blocking some more dangerous forms of insecure content, such as scripts, on secure pages, and we certainly intend to do so as well. We’re also looking into support for strict transport security (HSTS), to ensure that your connection to HSTS-enabled sites is safe even if you tried to connect via HTTP instead of HTTPS. This is what you normally do when you type an address into the address bar. Many sites will redirect you from an HTTP URL to an HTTPS URL, but an attacker isn’t going to do this kindness for you. Since all HTTP pages are insecure, you get no security warning. This problem is thwarted by strict transport security. We’re currently hoping to have both mixed content blocking and strict transport security complete in time for 3.16.

UI Changes

Of course, security hasn’t been the only thing we’ve been working on.

  • The most noticeable user experience change is not actually a change in Web at all, but in GNOME Document Viewer 3.14. The new Document Viewer browser plugin allows you to read PDFs in Web without having to download the file and open it in Document Viewer. (This is similar to the proprietary Adobe Reader browser plugin.) This is made possible by new support in WebKitGTK+ 2.6 for GTK+ 3 browser plugins.
  • The refresh button has been moved from the address bar and is now next to the new tab button, where it’s always accessible. Previously, you would need to click to show the address bar before the refresh button would appear.
  • The lock icon now opens a little popover to display the security status of the web page, instead of directly presenting the confusing certificate dialog. You can also now click the lock when the title of the page is displayed, without needing to switch to the address bar.


3.14 also contains some notable bugfixes that will improve your browsing experience.

  • We fixed a race condition that caused the ad blocker to accidentally delete its list of filters, so ad block will no longer randomly stop working when enabled (it’s off by default). (We still need one additional fix in order to clean this up automatically if it’s already broken, but in the meantime you can reset your filters by deleting ~/.config/epiphany/adblock if you’re affected.)
  • We (probably!) fixed a bug that caused pages to disappear from history after the browser was closed.
  • We fixed a bug in Web’s aggressive removal of tracking parameters from URLs when the do not track preference is enabled (it’s off by default), which caused compatibility issues with some web sites.
  • We fixed a bug that caused Web to sometimes not offer to remember passwords.

These issues have all been backported to our 3.12 branch, but were never released. We’ll need to consider making more frequent stable releases, to ensure that bugfixes reach users more quickly in the future.


  • There are new context menu entries when right-clicking on an HTML video. Notably, this adds the ability to easily download a copy of the video for watching it offline.
  • Better web app support. Recent changes in 3.14.1 make it much harder for a web app to escape application mode, and ensure that links to other sites open in the default browser when in application mode.
  • Plus a host of smaller improvements: The subtitle of the header bar now changes at the same time as the title, and the URL in the address bar will now always match the current page when you switch to address bar mode. Opening multiple links in quick succession from an external application is now completely reliable (with WebKitGTK+ 2.6.1); previously, some pages would load twice or not at all. The search provider now exits one minute after you search for something in the GNOME Shell overview, rather than staying alive forever. The new history dialog that was added in 3.12 now allows you to sort history by title and URL, not just date. The image buttons in the new cookies, history, and passwords dialogs now have explanitory tooltips. Saving an image, video, or web page over top of an existing file now works properly (with Web 3.14.1). And of course there are also a few memory usage and crash fixes.

As always, the best place to send feedback is <>, or Bugzilla if you’ve found a bug. Comments on this post work too. Happy browsing!

11 Replies to “GNOME Web 3.14”

    1. I think we’d need a bit of work in GtkCalendar to allow selecting a month or a week.

      We could do color input easily enough, though.

  1. I really like the web app idea, but it works rather funny when something trying to launch within the web app wants to open a web page. For example, I tried making one with google drive, and accessing any document brings up another, non-app-mode browser window.

    1. Carlos worked on some fixes for this that went into 3.14.1; do you have this version already? If so, we’ll need to look into it more.

  2. I would like to have a new stable 3.12-release of Epiphany, because I am affected by some of the bugs.

    Sometimes I have blank pages while loading a website. Most of the time the whole browser is after such incedents totally unusable (not responsive). I wonder if this has something to do with TLS auth failures.

    With all this problems in 3.12 I sadly had to give up using Epiphany for now. I look forward to use epiphany-3.14 again when it stable in Gentoo (o:

  3. Your link to the “Debian breaking TLS” has poor reasoning. Short RSA keys do not have sufficient strength. Thus, they ought to be disabled. Asking for them to remain enabled because “they give a scary warning to users” is to say “it’s better that a user be compromised but not scared than to expect major sites to do security right.”
    Also, I frequently use a site that has a self-signed certificate. Please don’t assume that just because the site didn’t pay a CA $50 for expensive bits, it is an attack site. Consider allowing certificate pinning, and perhaps DANE.

    1. Hi Derek, Debian’s ca-certificates issue is that Mozilla decided to reinstate the 1024-bit RSA certificates it had earlier removed. 1024-bit RSA is no longer considered strong enough for a certificate, let alone a root CA, but they’re not so insecure that it’s worth removing the root if it breaks a significant number of web sites, and the existing 1024-bit CAs are going to expire in 2016 anyway. I’m content to trust Mozilla if they think that having a few of these certs around for another two years is OK. Now, the issue in Debian is that due to a bug, the certificates were not reinstated in Debian as they should have been, so users who upgraded a Debian testing system around February or March this year will find several sites are broken in Epiphany due to the missing root CAs, whereas it will work fine for other Debian users. That’s definitely a bug.) Note that we’re not talking about minor breakage here: the broken site we debugged this on was Facebook.

      The case with Fedora is similar: if you want the Internet to work in a GnuTLS-based browser like Epiphany, you simply cannot remove all the certificates that were removed in the latest NSS update. Mozilla backpedaled on a couple (in particular, the same one that caused the Debian issue in February got removed and reinstated again last month), but for the most part Mozilla has succeeded in removing these certs for good, relying on NSS-specific certificate verification behavior to find chains of trust between unrelated certs. That doesn’t do any good for Epiphany; the broken sites I remember from this incident were Kickstarter and Amazon. Fedora is going to continue to carry these certs in its ca-certificates package for the foreseeable future, possibly until they expire (again, 2016).

      The choices are unfortunately between a browser that can load web pages properly and a browser that can’t. Web developers don’t test their sites with GnuTLS or OpenSSL clients, they test with NSS clients, so we can’t expect certificate verification issues to be fixed unless Firefox or Chrome is impacted as well. There’s been some work in glib-networking to move the GNOME stack from GnuTLS to NSS for this reason, but it’s unfinished and experimental.

      Now, for the case of a self-signed cert: I do assume that web sites intended for use by the general public will either have a good chain of trust to a common root CA, or else will not redirect users to load the page via HTTPS. If a public web site is redirecting you to an HTTPS page with a self-signed cert, that site is broken: users of other browsers are already getting horrible security warnings, and it’s absolutely OK for us to block them, just like other browsers do. But it’s true that in some cases, such as high-security sites where users receive the certificate out-of-band, there are legitimate reasons for using a self-signed cert. You should be able to import these certs with Passwords and Keys; however, there are some discoverability/usability issues with this, and the last time I tested it was either too difficult for me, or was broken. Suffice to say that I agree we need more work on that. (There are also sites that do use a self-signed cert even though they have no legitimate reason to do so, but these are few and far between and already broken in other browsers.) DANE support be great to have as well, though that’s a more distant target.

  4. I consider current browsers broken in respect to self-signed certificates and one should not copy this bug. Why should a self-signed certificate be less safe than automatically trusting all hundreds of CAs with their thousands of employees? Please let the user accept a certificate when they know it is OK.

  5. I like the look and feel of Epiphany (Web), but as a day to day browser it just doesn’t work. Most common interactive websites and online services just don’t work with it.
    As an example, there’s a hobby store called Michaels –, It’s not possible to shop on their website because 1) it’s PAINFULLY SLOW compared to Firefox and Chromium on the same computer, and 2) It simply dails to load the product pictures.
    It’s a big disappointment to me as a Gnome user because I really like it’s integration into the look and feel of Gnome.

    1. is working perfectly for me on Fedora 20. Could you please file a bug on, picking any version and prefixing the title of the bug with [GTK], so we can try to debug this issue with you? In your comment, please mention the distro, WebKitGTK+ version, and Epiphany version. Thanks!

Comments are closed.