Mozilla Leads the Way to Safer Browser Development

In a welcome and long overdue change in direction, browser creators are starting to look at the features that developers include in their code with an eye to security.

Mozilla was the first out of the chute on Monday by announcing that the Application Cache feature of HTML5 will not be working if the information transfer between browser and site does not occur as HTTPS.

Application Cache or AppCache lets developers specify which parts of the site will be available to the users offline. The idea is to give extra functionality to users, improve browser speed and reduce the effective load.

However, there are concomitant security risks when used with HTTP alone. Because the cache is not revalidated in use, malicious content can be loaded in a Man-in-the-Middle type of attack and viewed indefinitely even when the user is offline.

(Source: Wikipedia)

On a non-secured WiFi network, for instance, Johnathan Kingston describes in the Mozilla blog how this attack would work:

"Even if the user only visits one HTTP page over the WiFi, the attacker can plant many insecure iframes using AppCache which allows the attacker to rig the cache with malicious content manipulating all of those sites indefinitely. Even a cautious user who decides only to login to their websites at home is at risk due to this stale cache."

This is a potentially huge attack vector, as can be seen.

Kingston goes on to describe what Mozilla is going to do about this. He writes that in Firefox 60+ Beta and Nightly, Application Cache access from HTTP pages will be denied. Not only that, but starting with May's Firefox 62 release, Application Cache over HTTP will be fully removed for all the release channels.

Mozilla is serious about the effort, as are other browser makers. In fact, Chrome, Edge and WebKit have also stated their intent to remove this feature when used over HTTP. This will end up changed in the HTTP standardas well.

This fits in with Mozilla's avowed intention to deprecate HTTP and requiring HTTPS for all new APIs. Not only that, they will be stalwart in their effort to remove features from sites that are served over insecure connections.

The upshot of this effort by all the browser makers is that websites that want to preserve their functionality need to transition to the use of TLS encryption soon. If they don't, these kinds of API depreciations will end up taking their functionality away from them.

Related posts:

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.